Apple's container 1.0: one VM per container, and why that's the point

What happened

Apple cut version 1.0.0 of `apple/container`, the Swift-written, Apple-silicon-optimized tool for running Linux containers on a Mac. The HN thread hit 1,225 points within hours, which is the kind of number that usually only shows up for a new language or a Stripe outage. The 1.0 tag is paired with new documentation for container machines — a concept that, until last week, most people assumed was just Apple's word for 'the hidden VM Docker Desktop also has.'

It isn't. Tim Sneath, who runs developer relations for languages and frameworks at Apple, clarified in the thread that container machines now support persistence and host filesystem mounting, turning the tool from an OCI runtime into a general-purpose lightweight Linux environment. The shipped binary is a single Swift CLI, signed, notarized, and aware enough of Apple silicon to use Virtualization.framework directly rather than going through QEMU like most of its competitors.

The architectural choice that matters is buried in the technical docs: each container gets its own VM, not a shared one. A commenter (`WatchDog`) flagged it explicitly: 'It's a VM per container.' That single design decision is what separates this from every other container story on macOS in the last decade.

Why it matters

Docker Desktop, Rancher Desktop, Colima, and OrbStack all run a single Linux VM and pack many containers into it. That's the Linux model, and it's the model the whole OCI ecosystem assumes. Apple is doing the opposite: one container, one kernel, one VM, with Virtualization.framework doing the heavy lifting Apple silicon was already designed to do. The footprint of each VM is small enough that this is actually viable — Apple's own benchmarks put cold-start in the hundreds of milliseconds, not seconds — but the philosophical departure is real.

The natural question, raised by `cogman10` in the thread, is: why not a WSL1-style syscall translation layer? macOS is a Unix. The Darwin kernel is right there. In theory, you could intercept Linux syscalls and translate them to Mach/BSD equivalents and skip the VM entirely. Microsoft tried exactly this and gave up — `fork()` semantics, the proc filesystem, and io_uring all ended up too expensive to emulate faithfully. Apple has clearly looked at the same trade and concluded that on Apple silicon, where the hypervisor is essentially free, a real Linux kernel per container is cheaper than a partial emulation of one. They are not wrong, but it is a bet.

The community comparison everyone wants is against OrbStack, which has spent the last two years being the answer to 'Docker Desktop but fast.' `blahgeek` asked the obvious question in the thread and nobody had numbers yet. Early hands-on reports suggest OrbStack still wins on raw I/O throughput and on the experience of running dozens of long-lived containers — its shared-kernel model amortizes overhead across the fleet. Apple's per-VM model gives up some of that throughput in exchange for stronger isolation between workloads and a cleaner story for security-sensitive use cases like running untrusted CI jobs locally. If you're running one Postgres and one Redis for local dev, you will not notice the difference. If you're running a 40-container microservices stack, you might.

There is also a quieter implication: `pjmlp` called this 'the Year of Linux Containers Desktop,' which sounds glib but is closer to right than the Linux-desktop original. Microsoft shipped WSL2. Apple just shipped container 1.0. The two largest non-Linux desktop platforms have now both decided that the answer to 'how do developers run Linux workloads' is 'we ship Linux for them, natively, with a first-party tool.' The status quo of 'install Docker Desktop, pay $9/seat/month, file a bug when the file watcher pegs a core' is genuinely under pressure for the first time in years.

What this means for your stack

If you're on Apple silicon and you've been paying for Docker Desktop out of inertia, this is the moment to test the migration. The CLI is intentionally close to `docker` — `container run`, `container build`, `container pull` — and most Dockerfiles work unchanged because the runtime is OCI-compliant. The 1.0 release closes the two gaps that kept 0.x from being usable: bind mounts to host paths and persistent volumes across container restarts. That was the entire reason most people bounced off the earlier betas.

Where Apple's tool will hurt today: anything that assumes shared-kernel semantics between containers — sidecars communicating over loopback, Docker Compose stacks with implicit network namespacing, anything that mounts `/var/run/docker.sock` and expects to see siblings. Compose compatibility is partial. If your workflow is heavy on multi-container orchestration, OrbStack remains the pragmatic pick for another release or two. If your workflow is 'run one container, mount my source tree, iterate,' Apple's tool is now genuinely competitive and the binary is free, signed, and shipped by the OS vendor.

For CI and security teams there's a second-order benefit worth flagging: the per-container VM boundary means a container escape is contained at the hypervisor level, not the kernel level. That's a meaningfully stronger story for running untrusted code locally — security review pipelines, sandboxed build agents, anything where a container is parsing attacker-controlled input.

Looking ahead

The interesting question is not whether Apple's container tool wins on benchmarks this quarter — it won't beat OrbStack on throughput, and that's fine. The interesting question is whether the per-VM architecture becomes the model the rest of the macOS ecosystem converges on, the way Virtualization.framework has quietly replaced Hypervisor.framework for everything serious. If WWDC 2026 ships Xcode integration, a Compose-equivalent, and a clean story for running container machines as long-lived dev environments, Docker Desktop's macOS business gets a lot harder to defend. The 1.0 tag is the moment that conversation stops being theoretical.