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

Apple's own containerization tool, introduced at WWDC 2025 and shipping as a stable 1.0 in June 2026, breaks from how every other container tool on macOS works: rather than running all your containers inside one shared Linux VM the way Docker Desktop and OrbStack do — covered in depth here — Apple's Containerization framework gives each container its own dedicated, lightweight VM, built directly on Virtualization.framework. Each of those VMs boots a minimal, purpose-built kernel with a small Swift init process, tuned specifically for starting fast rather than for general-purpose use — reported boot times are sub-second. It's open source, Apache-licensed, written in Swift, Apple Silicon-only, and fully OCI-compatible: images from Docker Hub run unmodified, and anything you build with it pushes to any standard registry.

That one-VM-per-container design is exactly why the usual "containers share a kernel, VMs don't" framing breaks down here — Apple's containers already have the isolation properties of separate VMs, at the hardware level, the same category this blog's security deep dive puts a full VM in rather than the shared-kernel container tier.

So if both are already VMs, what's actually different?

Optimization target, not isolation strength. Apple's per-container VM is deliberately minimal and short-lived by design: a purpose-built kernel stripped down for one job — run this OCI image, do the thing, exit — with startup speed as the explicit priority. A Velo Linux VM workspace is the opposite kind of optimization: a full, general-purpose guest OS — real Ubuntu, Debian, Fedora, whichever distro you actually chose — with a persistent disk, an interactive desktop or shell session, a real package manager, SSH and VS Code Remote access, a serial console for when networking itself is broken, and (where the workload needs it) a GPU-backed channel back to the host. Apple's container tool isn't missing those things by oversight; it isn't built to have them, because that's not the job it's solving.

When each one is actually the right tool

  • Reach for Apple's container when what you have is an OCI image you want to run quickly, with strong isolation, and nothing more — a single service, a build step, a CI job that's already packaged as a container. It's a genuinely good fit for exactly that, and its per-container VM model means you get real isolation without needing to reach for a heavier tool to get it.
  • Reach for a full Linux VM workspace when you need an actual environment, not just a place to run one packaged process — installing and configuring software interactively, a persistent working directory across sessions, GUI tooling, GPU-backed local inference, or a general-purpose disposable dev/test/CI environment that isn't already shaped as a single container image.

Worth being direct about where they don't compete at all: nothing about Apple's per-container VM model gives you an interactive shell session with your own tooling installed, a desktop environment, or persistent state across restarts the way a workspace does — that's not a current limitation to watch for improving, it's a different tool solving a different problem by design.

They're not mutually exclusive

A realistic setup uses both, for different halves of the same workflow: Apple's container for running a packaged service or a CI step that's already an OCI image, and a Velo Linux VM workspace as the actual development environment — where you write the code, test it interactively, and build the container image in the first place before handing it off. One doesn't replace the other; they sit at different points in the same pipeline.

Related reading: Apple Containers vs. Docker Desktop vs. OrbStack for how Apple's tool compares to the two shared-VM container tools, VM vs. container vs. sandbox on macOS for the general isolation-model primer, and the security deep dive for where each isolation level actually sits on real, measured risk. Or download Velo Workspaces and try it yourself.