Apple quietly shipped one of the more interesting developer features of the year, and it arrived wearing camouflage. Buried under the Apple Intelligence announcements at WWDC was Container Machines — Apple’s answer to the Windows Subsystem for Linux, finally giving the Mac a first-party, lightweight, persistent Linux environment that feels native to Apple Silicon. Better Stack’s walkthrough is a tidy eight-minute tour, and it’s worth unpacking what this actually means for anyone running real workloads on Macs.
The short version: Container Machines sit on top of Apple’s container project, the Swift-written Docker alternative Apple released the year prior. You hand it any OCI-compatible image — the same things you’d pull from Docker Hub — add a system-init program so it can behave like a VM, build it with Apple’s container tool, and container machine create spins up a full Linux box “in literally seconds.” It defaults to half your Mac’s RAM and a chunk of your cores, both configurable.
What makes it more than a toy is the integration. Your macOS user and home directory are automatically shared into the Linux environment as read-write, so there’s no file shuffling: edit on the Mac with your native tools, switch to Linux to compile or test, and it’s all the same filesystem. The machine also gets its own volume for Linux-specific dotfiles. The demo nails the real use case — building a Bun binary that only runs on Linux, then testing it instantly without leaving the project directory. And because these machines run a genuine systemd, you can stand up a proper service stack inside one — Postgres running as an actual service next to your app — and have it behave like the Linux server you’ll eventually deploy to. You can even run several at once: Alpine, Ubuntu, and Debian side by side, one distro per target, which is genuinely nice for cross-platform work.
The architecture is where Apple diverges from Docker Desktop, and it’s the part that matters for infrastructure people. Docker Desktop runs many containers inside one shared Linux VM. Apple gives every container its own lightweight VM through the virtualization framework. That buys you stronger isolation (each container has full-VM boundaries), better privacy (you mount only the data each VM needs, rather than exposing everything to one shared VM), and — counterintuitively — competitive memory use. The benchmarks Better Stack cites (RepoFlow’s, comparing Apple Containers, OrbStack, and Docker Desktop) bear this out: Apple leads on memory throughput and is neck-and-neck on single- and multi-threaded CPU. Where it still trails is cold-start time for tiny containers — sub-second, but OrbStack and Docker Desktop do it in under a quarter of that. OrbStack also keeps a clear edge on filesystem and small-file performance.
There are catches worth flagging before anyone rebuilds their workflow around it. The big one is memory: a machine grabs half your RAM by default and does not give it back until you restart it. Run a memory-hungry build inside a container and that ceiling stays pinned. Hot reloading and breakpoints also don’t work cleanly if your editor is running on the macOS side — the fix is to have your editor connect into the machine over SSH, which Apple documents but which adds friction.
So is this useful, or just Apple reinventing a wheel that OrbStack already rounded off nicely? For most developers who already pay for OrbStack or tolerate Docker Desktop, Container Machines is a solid, free, first-party option rather than a revolution — the performance is “level if not better than Docker Desktop,” which is a respectable bar, not a stunning one.
But for a Mac-heavy infrastructure — and ours is exactly that, a small fleet of Apple Silicon machines doing real work — the calculus is different. Container Machines means you can run genuine Linux services natively on a Mac without the overhead and licensing baggage of Docker Desktop, with VM-grade isolation per service and that systemd fidelity that makes “test it like production” actually true. The per-container-VM model is the right security posture for a homelab that hosts a mix of trusted and experimental workloads. The memory behavior is the asterisk: on a control-plane Mac that’s already memory-constrained, a Container Machine that quietly holds half the RAM hostage until reboot is a real operational hazard, not a footnote.
The honest verdict: Container Machines won’t pull anyone off OrbStack on raw speed, and the RAM-hoarding default needs respect. But Apple has made the Mac a legitimate place to run isolated, persistent, production-shaped Linux environments — and for anyone whose servers happen to be Macs, that’s a quietly significant unlock. The most interesting feature at WWDC was the one nobody put on a slide.