# How Apple’s Container Runtime Differs from Docker on macOS: A Technical Deep Dive > Discover how Apple's container runtime differs from Docker on Mac. Explore native macOS virtualization for isolated containers versus Docker's shared VM approach. - Repository: [Apple/container](https://github.com/apple/container) - Tags: deep-dive - Published: 2026-07-01 --- **Apple’s `container` tool launches a separate lightweight virtual machine for every container using native macOS virtualization frameworks, whereas Docker runs all Linux containers inside a single shared HyperKit VM, providing stronger isolation and tighter host-data control at comparable performance.** Apple’s open-source `container` project reimagines container execution for macOS, departing from Docker’s architecture to leverage Apple silicon’s native virtualization capabilities. While both tools consume standard OCI images from the `apple/container` repository, the runtime fundamentally differs in its execution model, isolation guarantees, and deep integration with macOS system frameworks. ## Execution Model and Architecture ### Docker’s Shared VM Approach Docker Desktop for Mac relies on a single shared Linux virtual machine running atop HyperKit. All containers execute within this monolithic VM, sharing the same Linux kernel, system libraries, and compute resources. This multitasking model reduces per-container overhead but creates a shared security boundary where all workloads coexist in the same kernel space. ### Apple’s Per-Container VM Strategy In `Sources/ContainerRuntime/`, Apple implements a radically different virtualization model using the [Containerization Swift package](https://github.com/apple/containerization). According to [`docs/technical-overview.md`](https://github.com/apple/container/blob/main/docs/technical-overview.md) (lines 24-31), the runtime launches a **separate lightweight VM for each container** rather than multitasking containers inside a shared environment. This approach utilizes the Apple Virtualization framework to create micro-VMs optimized for individual workloads, with each VM booting only the specific resources its container requires. ## Security and Isolation Mechanisms ### Namespace Isolation vs Full VM Isolation Docker provides isolation through Linux namespaces and cgroups within its shared VM. Compromise of the shared kernel potentially affects all containers running within that VM. Conversely, as documented in [`docs/technical-overview.md`](https://github.com/apple/container/blob/main/docs/technical-overview.md) (lines 27-30), Apple's runtime provides **full VM isolation** for each container, ensuring that security boundaries align with hardware virtualization boundaries rather than software namespaces. ### Data Privacy and Host Path Mounting Docker typically mounts host filesystems into the shared VM, making directories available to all containers by default. The `container` runtime, as described in [`docs/technical-overview.md`](https://github.com/apple/container/blob/main/docs/technical-overview.md) (lines 28-30), mounts **only specific host paths required by individual containers** into their dedicated VMs, reducing unnecessary data exposure and adhering to the principle of least privilege. ## Performance Characteristics ### Memory Usage and Boot Times While Docker’s shared VM reduces per-container overhead, it can suffer from higher memory usage and slower boot times as the monolithic VM grows and manages resources for all containers simultaneously. According to [`docs/technical-overview.md`](https://github.com/apple/container/blob/main/docs/technical-overview.md) (lines 30-31), Apple's lightweight per-VM architecture achieves **lower memory usage than Docker’s shared VM** with **start-up times comparable to Docker**, as each VM initializes only the resources its specific container requires. ## Native macOS Integration ### Virtualization Framework and System Services Docker relies on HyperKit and custom networking stacks, operating somewhat independently from macOS native services. Apple’s runtime integrates deeply with macOS frameworks as documented in [`docs/technical-overview.md`](https://github.com/apple/container/blob/main/docs/technical-overview.md) (lines 34-41): - **Virtualization** framework for VM management and lifecycle - **vmnet** for networking between host and container VMs - **XPC** for secure inter-process communication - **launchd** for service management and daemon control - **Keychain** for secure registry credential storage - Unified logging system for diagnostics This integration extends to `signing/container-runtime-linux.entitlements`, which defines the specific entitlements required for the Linux VM helper process, ensuring compliance with macOS security models. ## Compatibility and OCI Standards Despite architectural differences, `container` maintains full compatibility with existing container workflows. As stated in [`docs/technical-overview.md`](https://github.com/apple/container/blob/main/docs/technical-overview.md) (lines 32-33), the tool **consumes and produces standard OCI images**, ensuring images built with Docker run unmodified on `container` and vice versa. The primary limitation is platform support: while Docker runs on Intel and older Apple silicon Macs, `container` targets **macOS 26** on Apple silicon, with limited functionality on older releases (lines 61-72). ## Command-Line Comparison The CLI design intentionally mirrors Docker for minimal friction. Key commands from [`docs/command-reference.md`](https://github.com/apple/container/blob/main/docs/command-reference.md) (lines 126-149) demonstrate the parallel workflows: Building an image: ```bash # Docker docker build -t my-app:latest . # Apple container container build --tag my-app:latest . ``` Running a container with port mapping: ```bash # Docker docker run -p 8080:80 my-app # Apple container container run --publish 8080:80 my-app ``` Pushing to a registry: ```bash # Docker docker push ghcr.io/example/my-app:latest # Apple container container push ghcr.io/example/my-app:latest ``` Inspecting images: ```bash # Docker docker inspect ghcr.io/example/my-app:latest # Apple container container image inspect ghcr.io/example/my-app:latest ``` ## Summary - **Apple’s `container` runtime** launches a dedicated lightweight VM per container using the Virtualization framework, while Docker uses a single shared Linux VM. - **Security isolation** is enforced at the VM level in Apple's implementation, compared to Linux namespaces in Docker’s shared kernel. - **Data privacy** is enhanced by mounting only required host paths into specific container VMs rather than exposing directories to a shared environment. - **Performance** characteristics include lower memory usage and comparable startup times due to resource-specific VM provisioning. - **Platform integration** leverages native macOS services including vmnet, XPC, launchd, and Keychain, unlike Docker’s HyperKit-based approach. - **OCI compatibility** ensures images and workflows remain portable between both runtimes. ## Frequently Asked Questions ### Can I run Apple’s container runtime on Intel Macs? No. According to [`docs/technical-overview.md`](https://github.com/apple/container/blob/main/docs/technical-overview.md) (lines 61-72), the `container` tool targets macOS 26 and Apple silicon hardware specifically. While limited functionality may exist on older releases, full feature support—including advanced networking capabilities—requires Apple silicon chips, and Intel Macs are not supported. ### Will my existing Docker images work with Apple’s container tool? Yes. The runtime consumes and produces standard OCI images as documented in [`docs/technical-overview.md`](https://github.com/apple/container/blob/main/docs/technical-overview.md) (lines 32-33). Images built with Docker run unmodified on `container`, and images created with `container` are compatible with Docker registries and other OCI-compliant tools. ### How does the per-VM model affect resource overhead compared to Docker? While launching separate VMs might seem resource-intensive, [`docs/technical-overview.md`](https://github.com/apple/container/blob/main/docs/technical-overview.md) (lines 30-31) indicates that Apple’s lightweight VMs actually result in **lower memory usage** than Docker’s monolithic shared VM, with startup times remaining comparable to Docker’s container initialization because each VM is optimized for its specific workload. ### Where can I find the implementation details of the VM lifecycle management? The core runtime logic resides in `Sources/ContainerRuntime/`, which implements the per-container VM creation, management, and teardown using the Containerization Swift package. Architectural details are further documented in [`docs/technical-overview.md`](https://github.com/apple/container/blob/main/docs/technical-overview.md), while configuration and entitlement details are specified in `signing/container-runtime-linux.entitlements`.