Apple container explained: one lightweight Linux VM per container on the Mac
A technical guide to Apple container’s per-container microVM model, OCI images, Virtualization framework, vmnet, XPC services, installation path, supported hardware, resource limits, and alternatives.
Position and current signal
Apple container is a macOS command-line tool for building and running Linux containers inside lightweight virtual machines while retaining OCI image compatibility. The repository showed 48,081 stars at capture time, about 43 default-branch commits in 30 days, and version 1.1.0 as its latest release. Its distinguishing choice is one VM per container rather than many containers inside a shared Linux VM, changing the isolation, networking, and resource trade-offs.
Use cases and capabilities
The main audience is an Apple silicon developer who needs to pull, run, build, and push standard OCI images and test Linux services locally. The CLI covers lifecycle, image, registry, network, and system commands, and it can build from a Dockerfile. This is useful for workstation development and reproducible build experiments. It is not a cluster orchestrator and does not aim to provide the full desktop management suite found in older container products.
Architecture and execution model
The CLI talks to `container-apiserver`, a launchd-managed agent that starts image and network helpers through XPC. A core-images service manages the local content store; a vmnet helper owns the virtual network; and each container receives its own runtime-linux helper and lightweight Linux VM. The underlying Containerization Swift package supplies lower-level image, process, and runtime functions. Separate VMs strengthen isolation between workloads, while introducing VM-specific behavior for memory and networking.