Apple's container, briefly: one micro-VM per container

Apple's container tool, introduced at WWDC 2025 and stable at 1.0 in June 2026, breaks from every other container tool on macOS. Instead of running all containers in one shared Linux VM, as Docker Desktop and OrbStack do (compared here), Apple's Containerization framework gives each container its own lightweight VM on the Virtualization framework. Each boots a minimal, purpose-built kernel with a small Swift init process, tuned to start fast, with reported boot times under a second. It's open source (Apache-licensed), written in Swift, Apple silicon only, and OCI-compatible: Docker Hub images run unmodified, and what you build pushes to any standard registry.

That one-VM-per-container design is why "containers share a kernel, VMs don't" breaks down here. Apple's containers already have the hardware isolation of separate VMs, the tier the security deep dive gives a full VM rather than a shared-kernel container.

If both are VMs, what's different?

What they're optimized for, not how strongly they isolate. Apple's per-container VM is deliberately minimal and short-lived: a stripped-down kernel for one job, run this image and exit, with start-up speed as the priority. A Linux VM workspace is optimized the other way: a full, general-purpose OS (real Ubuntu, Debian, Fedora or Rocky Linux) with a persistent disk, an interactive shell or desktop, a package manager, SSH and VS Code Remote access, a built-in terminal, a console for when networking breaks, and, where needed, a GPU-backed channel to the Mac. Apple's tool doesn't lack those by oversight; they're not its job.

When to use each

  • Apple's container when you have an OCI image to run quickly with strong isolation and nothing more: a single service, a build step, a CI job already packaged as a container. Its per-container VMs give you real isolation without a heavier tool.
  • A Linux VM workspace when you need an environment, not just a place to run one packaged process: installing and configuring software interactively, a working directory that persists between sessions, GUI tools, GPU-backed local inference, or a disposable dev, test or CI environment that isn't shaped like a single image.

Where they don't compete at all: Apple's model doesn't give you an interactive session with your own tools installed, a desktop, or state that persists across restarts the way a workspace does. That's not a gap waiting to close; it's a different tool for a different problem.

Use both

A realistic setup uses each for its half of the same workflow: a Linux VM workspace as the development environment, where you write the code, test it interactively and build the image, and Apple's container to run the packaged service or CI step afterwards. One doesn't replace the other; they sit at different points in the same pipeline.

Related reading: Apple Containers vs. Docker Desktop vs. OrbStack, VM vs. container vs. sandbox on macOS, and the security deep dive for where each isolation level sits. Or download Velo Workspaces and try it yourself.