Apple's `container` ships: Docker Desktop's moat just got narrower

What happened

Apple has quietly published the `container-machine` documentation for its open-source `container` project on GitHub, and the Hacker News front page noticed — 440 points and counting. The headline: every Linux container you run on macOS gets its own lightweight virtual machine, booted from Apple's `Virtualization.framework`, with no Docker daemon, no shared `linuxkit` VM, and no Docker Desktop license.

The architecture is the interesting part. A `container-machine` is a long-running VM that hosts a single container (or a small group of related containers). Each VM boots a minimal Linux kernel plus `vminitd` — Apple's custom init process written specifically for this runtime — and exposes the container's filesystem and network back to the host through Virtio. Images are OCI-compatible and pulled from any standard registry. The CLI surface (`container run`, `container build`, `container images`) is deliberately close to Docker's, so muscle memory ports over in an afternoon.

The project requires Apple Silicon (M1 or later) and macOS 15 Sequoia. It is Apache 2.0 licensed. Builds use BuildKit. Networking is handled per-VM with a virtual NIC bridged through a host-side networking daemon. The whole thing was first teased at WWDC 2024 and has been iterating in public on `github.com/apple/container` ever since.

Why it matters

For a decade, running Linux containers on a Mac meant running a shared Linux VM — `xhyve`, then HyperKit, then the QEMU-based VM that Docker Desktop, Colima, OrbStack, and Rancher Desktop all variants of. Containers inside that VM shared a kernel and a network namespace, which is fine until it isn't: noisy-neighbor CPU stalls, leaky bind-mounts, and the perpetual confusion about whether `localhost` means the host or the VM.

Apple's bet is the opposite: one VM per container, booted in well under a second, isolated at the hypervisor boundary. That's the same architectural choice AWS made with Firecracker for Lambda, and the same one Fly.io made for their micro-VMs. The reason it works now and didn't five years ago is `Virtualization.framework` — Apple's first-party hypervisor API that ships in the OS, has direct access to the secure enclave, and can boot a Linux kernel with effectively zero overhead on M-series silicon. Cold start latency in the docs is described as sub-second for typical images. Memory ballooning lets idle VMs give pages back to the host. Rosetta-on-VM means you can still run x86_64 images, though slower.

The community reaction on the HN thread is unusually warm for a corporate release. The top comments aren't "this is Docker but worse" — they're "finally, the bind-mount performance might not be terrible." That's the real wound Docker Desktop has been bleeding from on macOS: file-sharing via gRPC-FUSE or VirtioFS has always been the bottleneck for anyone doing real development inside containers. Apple's per-container VM model sidesteps the shared filesystem problem entirely — each VM mounts only what it needs, directly, with no cross-VM cache invalidation to coordinate.

There's also the licensing dimension nobody on the technical side wants to talk about. Docker Desktop has been a paid product for companies over 250 employees or $10M revenue since 2021. Procurement at every mid-size shop has spent the last four years either paying, switching to OrbStack, or pretending not to know. Apple just dropped an Apache-2.0 alternative built into the OS hypervisor. The Docker pricing page will look different by next year.

What this means for your stack

If you're on Apple Silicon and your local dev loop is "edit code, `docker compose up`, hit endpoints," you should at minimum kick the tires. The CLI is close enough to Docker's that a `docker` → `container` alias gets you 80% of the way. Compose support is not yet at parity — that's the gap to watch. If you depend on multi-container `docker-compose.yml` files with custom networks, expect to wait another release or two before this is a drop-in replacement. Single-container workflows, scratch builds, and CI-style "spin up Postgres for a test" patterns work today.

For teams maintaining a fleet of macOS dev machines, this changes the procurement math immediately. You no longer need Docker Desktop seats for engineers whose only requirement is "run a Linux container locally." Colima and OrbStack remain better choices if you need Docker Compose, Kubernetes, or x86 emulation that doesn't pay Rosetta tax. But the cost floor for a working container setup on a Mac just dropped to zero, with first-party support from the OS vendor.

The security story is the under-discussed angle. Hypervisor isolation per container means a compromised container can't escape into a shared kernel that other containers share. For anyone running untrusted code locally — security researchers, anyone evaluating npm packages, anyone running AI-generated Bash — the blast radius shrinks dramatically. This is the same value proposition Kata Containers has been selling on the server side for years; Apple just made it the default for desktop developers.

Looking ahead

The interesting question isn't whether `container` kills Docker Desktop on macOS — that outcome is already priced in, it's a matter of months. The interesting question is whether Apple ports `vminitd` and the per-container VM model to Linux servers, where it would compete directly with Firecracker and gVisor. That would be a much bigger story, and there's no public signal it's coming. For now, Apple has done what it usually does: take a category everyone assumed was settled, ship a first-party version, and let the third-party tax disappear quietly.