The 0.4.0 release adds persistent container machines with $HOME mapped into the guest and real systemd support, betting a Linux environment is the right unit of work rather than a single process.
Apple's open-source container project has always positioned itself as the cleaner way to run Linux on a Mac: one lightweight VM per container, no shared Linux host, no daemon tax. The new container-machine subcommand in the 0.4.0 release — shipped on the project's one-year anniversary, according to Apple's own releases page — pushes that idea further, treating the Linux environment on macOS as something closer to a persistent workstation than a disposable process.
The distinction matters. Most container tools on macOS, including Docker Desktop, OrbStack, and Lima, are designed around the application container: one process per container, no init system, throwaway state. Container machine, by contrast, is built to behave like a Linux system. The container-machine documentation describes it as a "highly integrated Linux environment" that is "fast, lightweight and persistent" and "based on standard OCI images." That is the model of a developer machine, not a build step.
The headline feature shipped in the 0.4.0 release — which Apple's releases page describes as the one-year anniversary milestone — is the container-machine itself: a long-lived Linux environment with tight host integration. The target user is someone who has been SSHing into a Linux box to test a service under systemd, or juggling a Multipass VM to get a clean Ubuntu image.
What makes it different from the existing field is the host-integration bet. The container machine maps the macOS username into the guest and mounts the host's $HOME at /Users/<username> inside Linux. Apple walks through the consequence in the docs: a macOS editor edits a file, and the Linux environment compiles against that same file. No docker cp, no bind-mount debugging, no stale-copy puzzles. A Mac-side profiler, a screenshot tool, or a browser inspecting the running service all see the same filesystem the container sees.
That is a real architectural choice, not a config flag. The technical overview describes the runtime as built on Apple's open-source Containerization Swift package, which stitches together the macOS Virtualization framework (one VM per container), vmnet for networking, XPC for inter-process communication, launchd for service management, and Keychain for registry credentials. Each container machine is a separate VM, not a tenant inside a shared host Linux. There is no central Linux kernel mediating between the Mac and the guest workloads; the guest kernel does.
The tradeoffs follow from the architecture. Because the model is one VM per container, a developer can keep multiple container machines alive at the same time, each tied to a different target distribution. That is the day-to-day payoff for someone who needs to test against Ubuntu 22.04 and AlmaLinux 9 in the same afternoon. The cost is that the project depends on macOS 26 and Apple silicon. On macOS 15, the maintainers' own note is that container-to-container networking, multi-network setups, and stable IP allocation are degraded, and bugs that only reproduce on macOS 15 will not be fixed. Apple's stability contract is also clear that the project is pre-1.0; patch versions are stable, minor versions may break until 1.0.0. Anyone planning to standardize on this for a team should treat the API surface as provisional.
Systemd is the other real constraint. Real Linux services, systemctl start postgresql for example, work only inside images that ship an init system, and the container-machine docs include a Dockerfile template for an Ubuntu 24.04 image with systemd enabled. That is a sharp line between "I can run a process" and "I can register a service." For teams that have been papering over the gap with docker-compose, it is the kind of constraint that forces a decision rather than hides one.
The honest comparison is not "Apple killed Docker." Docker Desktop, OrbStack, and Lima each make different tradeoffs: OrbStack leans into fast cold starts and Rosetta on the Mac side; Lima is a one-VM-per-host Linux that container tools talk to; Docker Desktop is the incumbent, with the broadest compatibility and the heaviest footprint. What container-machine adds is a specific design point: the Mac is not a host that runs a Linux VM that runs containers. The Mac is the host, and the container is a first-class Linux system that happens to share the home directory. For a developer whose editor, profiler, and shell live on macOS and whose target services live on Linux, that is a tighter loop than any of the existing options ship out of the box.
Memory handling is the one place the architectural purity shows a seam. The technical overview notes that memory ballooning in the underlying Virtualization framework is partial, so freed guest memory is not always returned to the host. Long-running container machines may accumulate footprint that a restart reclaims. It is a caveat worth knowing before treating container machines as permanently lightweight.
The practical question for a team is whether the host-integration model — shared $HOME, real init, per-distro machines, no copy step between editing and compiling — is worth the macOS 26 requirement and the pre-1.0 API. For a solo developer on an M-series Mac, the answer is probably yes: install [the container CLI from the repository](https://github.com/apple/container), pull an Ubuntu 24.04 image with systemd, register a couple of services, and see whether the loop is tighter than the current setup. For a larger team, the answer should wait for an independent release that survives a sprint. The design is sound. The contract is still being written.