macOS Containers / Notes

Requirements and known limitations

This is a 0.0.1 release and the version number is not modesty. Read this before you install it on a machine you rely on.

The short version: it needs System Integrity Protection disabled, the base images are large, and it is alpha software. If any one of those is unacceptable, stop here. Nothing below makes them go away.

System Integrity Protection

Running macOS as a containerised guest requires SIP to be turned off on the host. This is the single largest cost of using the project and it deserves a straight explanation rather than a footnote.

SIP is what stops even root from modifying protected system locations, loading unsigned kernel extensions, or attaching a debugger to Apple's own processes. Turning it off is done from Recovery and it is a machine-wide setting, not a per-application one. Every process on that Mac gains capabilities it did not have before, not only this one.

The practical consequence is that this belongs on a build machine or a spare Mac, not on the laptop holding your signing keys and your production credentials. There is a certain irony in disabling a security feature in order to run an isolation tool, and it is better to say so plainly than to bury it.

Host and guest support

Installation is handled through Homebrew. Host support covers Sonoma, Ventura, Monterey and Catalina. Base images are published for Ventura, Monterey and Big Sur, and they are full macOS roots rather than the trimmed userlands Linux images use, so they are measured in gigabytes rather than megabytes. The Ventura image is a little over seven gigabytes. Plan disk accordingly, particularly if you intend to keep more than one release around.

Images build with Docker and push to standard registries, so the surrounding tooling and the distribution story are ordinary even though the guest is not.

What to expect from alpha

Expect rough edges in the places alpha software usually has them: networking and volume behaviour that does not match the Docker semantics you have internalised, teardown that occasionally leaves state behind, and error messages that assume you have read the source. Do not put it in a pipeline whose failure would be somebody else's problem. Do use it for exactly the thing it is good at, which is a throwaway macOS root you can rebuild in a minute rather than a VM you nurse for a year.

How it relates to Apple's tooling

Apple's own container tool solves a neighbouring problem and is the right choice for most people most of the time. It runs Linux containers, each inside its own lightweight virtual machine, it requires Apple silicon and a current macOS release, and it does not ask you to disable SIP. If your workload is Linux, use that, or use Docker Desktop, and do not take on the costs described above for no benefit.

This project is only interesting when the guest genuinely has to be macOS: building and testing Mac software, or reproducing behaviour that only exists on the platform. The notes on isolation boundaries set out where each approach draws its line, and the notes on headless browsers cover one concrete case where the Linux option runs out.