# How Apple Container Differs from Docker on macOS: Architecture Deep Dive > Explore how Apple Container differs from Docker on macOS. Discover their distinct architectures, focusing on isolation, security, and native integration. - Repository: [Apple/container](https://github.com/apple/container) - Tags: architecture - Published: 2026-06-11 --- **Apple Container uses a lightweight per-container VM model built on the macOS Virtualization framework, while Docker Desktop relies on a single shared Linux VM, creating fundamental differences in isolation, security, and native integration.** The `apple/container` repository provides a native container runtime designed specifically for macOS, offering an alternative to Docker Desktop's Linux-based approach. While both ecosystems run Linux containers on Apple hardware, they employ radically different **container vs Docker on macOS architecture** strategies that impact performance, security boundaries, and system integration. Understanding these architectural distinctions helps developers choose the right tool for their containerized workflows. ## VM Architecture and Isolation Models The fundamental divergence between these runtimes lies in how they virtualize the Linux environment required for container execution. ### Docker's Single Shared VM Strategy Docker Desktop for macOS creates **one persistent Linux VM** (typically QEMU-based via HyperKit) that hosts all containers simultaneously. This shared VM runs a Docker daemon (`dockerd`) that manages container lifecycle, networking, and storage within a single kernel instance. According to [`docs/technical-overview.md`](https://github.com/apple/container/blob/main/docs/technical-overview.md), this architecture means all containers share the same kernel, memory space, and CPU resources, with isolation limited to Linux namespaces and cgroups. ### Apple Container's Per-Container VM Design In contrast, Apple Container spawns a **dedicated lightweight VM for each container** using the native macOS Virtualization framework. As documented in the repository's technical overview, each VM is approximately **30 MiB** and boots with its own kernel, memory allocation, and CPU resources. This design provides VM-level isolation rather than process-level isolation, meaning a compromised container cannot directly affect other containers or the host system. The system configuration defaults are defined in [`Sources/ContainerPersistence/ContainerSystemConfig.swift`](https://github.com/apple/container/blob/main/Sources/ContainerPersistence/ContainerSystemConfig.swift), which maps TOML configuration values to Swift structs. By default, each container VM receives **4 CPUs** and **1 GiB of memory** unless overridden via command-line flags. ## Security and Privacy Implications The architectural differences create distinct security postures regarding attack surface and data visibility. ### Attack Surface Reduction Docker's shared VM model means all containers run within the same security boundary; a vulnerability in the container runtime or kernel could potentially compromise every running container. Apple Container mitigates this by isolating each container in its own VM, ensuring that a breach remains confined to that specific virtual machine instance. ### Data Mounting and Host Visibility When mounting host directories, Docker Desktop must expose paths through the shared VM's filesystem layer, potentially making more host data visible than intended. Apple Container takes a more restrictive approach: it mounts **only the explicitly requested data** into each individual VM, keeping other host filesystem areas invisible to the container process. This per-VM mounting strategy reduces the risk of unintended data exposure. ## Native macOS Integration Apple Container leverages first-party frameworks rather than custom hypervisors, creating tighter integration with macOS internals. ### Virtualization Framework vs HyperKit While Docker Desktop uses HyperKit (a custom hypervisor) and bundles its own Linux kernel, Apple Container directly utilizes the **macOS Virtualization framework**. This native approach provides better hardware acceleration and power efficiency. The runtime requires **macOS 26** for full functionality, though macOS 15 is supported with limitations, as noted in the technical documentation. ### vmnet and XPC Communication Networking in Apple Container uses **vmnet** for virtual network interfaces rather than Docker's internal NAT bridge. Each container VM attaches to its own vmnet network, with macOS 15 limited to a single subnet and newer versions supporting multiple isolated networks. Communication between the CLI and runtime occurs via **XPC** (Inter-Process Communication) rather than a persistent daemon. The [`Sources/ContainerXPC/XPCServer.swift`](https://github.com/apple/container/blob/main/Sources/ContainerXPC/XPCServer.swift) implements this secure IPC layer, replacing Docker's client-daemon socket model. The [`Sources/CLI/ContainerCLI.swift`](https://github.com/apple/container/blob/main/Sources/CLI/ContainerCLI.swift) forwards commands to the `container-apiserver` launch agent, which spawns XPC helpers including `container-runtime-linux`, `container-core-images`, and `container-network-vmnet`. ## Configuration and Runtime Components The operational models differ significantly in how they manage configuration and background services. ### TOML-Based Configuration vs daemon.json Docker Desktop relies on a JSON-based [`daemon.json`](https://github.com/apple/container/blob/main/daemon.json) for global configuration, typically managed through a GUI or manual file editing. Apple Container uses a TOML-based [`config.toml`](https://github.com/apple/container/blob/main/config.toml) parsed by [`Sources/ContainerPersistence/ConfigurationLoader.swift`](https://github.com/apple/container/blob/main/Sources/ContainerPersistence/ConfigurationLoader.swift) and mapped to Swift structs in [`Sources/ContainerPersistence/ContainerSystemConfig.swift`](https://github.com/apple/container/blob/main/Sources/ContainerPersistence/ContainerSystemConfig.swift). This configuration controls per-container defaults, network subnets, and kernel image selection. ### XPC Services vs Docker Daemon Rather than a monolithic daemon like `dockerd`, Apple Container distributes functionality across specialized XPC services orchestrated by [`Sources/APIServer/APIServer.swift`](https://github.com/apple/container/blob/main/Sources/APIServer/APIServer.swift). The `container-apiserver` acts as a launch agent that manages VM lifecycle, while Docker maintains a single persistent daemon inside its shared VM. ## Networking and Image Building Both ecosystems support OCI-compliant images but implement builds differently. ### vmnet vs Docker NAT Docker creates a NAT network (`docker0`) inside its shared VM, forcing all containers to share the same virtual NIC and network namespace. Apple Container assigns each VM its own vmnet interface, providing better network isolation between containers. ### Builder VMs vs BuildKit While Docker uses BuildKit running inside the shared VM for image construction, Apple Container executes `container build` inside a **transient builder VM**—a dedicated lightweight VM that exists only for the duration of the build process. This ensures build environments are clean and isolated from runtime containers. ```bash # Docker uses BuildKit within the shared VM docker build -t myimage:latest . # Apple Container uses a dedicated builder VM container build --tag myimage:latest --file Dockerfile . ``` ## Summary - **Apple Container creates a lightweight VM per container** (~30 MiB) using the macOS Virtualization framework, while Docker Desktop uses a single shared Linux VM for all containers. - **Isolation differs fundamentally**: Docker uses Linux namespaces and cgroups within a shared kernel; Apple Container provides VM-level isolation with separate kernels and resources per container. - **Security boundaries** are stricter in Apple Container due to per-VM data mounting and reduced attack surface, whereas Docker's shared VM exposes all containers to a single kernel compromise. - **Native integration** leverages vmnet for networking, XPC for inter-process communication, and Launchd for service management, contrasting with Docker's HyperKit hypervisor and daemon-based architecture. - **Configuration** uses TOML ([`config.toml`](https://github.com/apple/container/blob/main/config.toml)) mapped via [`ContainerSystemConfig.swift`](https://github.com/apple/container/blob/main/ContainerSystemConfig.swift) rather than JSON, with defaults of 4 CPUs and 1 GiB memory per container VM. - **Image builds** occur in transient builder VMs rather than a persistent BuildKit daemon, maintaining isolation between build and runtime environments. ## Frequently Asked Questions ### Does Apple Container replace Docker Desktop completely? Apple Container provides an alternative runtime for Linux containers on macOS but requires macOS 26 for full functionality (with limited support on macOS 15). While it runs standard OCI images and supports familiar commands like `container run`, it uses a fundamentally different architecture that prioritizes isolation over the resource-sharing model of Docker Desktop. Organizations running diverse container workloads may need to evaluate compatibility with specific networking or storage features. ### How does per-container VM performance compare to Docker's shared VM? Despite creating separate VMs, Apple Container maintains comparable performance through minimal VM images (~30 MiB) and the macOS Virtualization framework's hardware acceleration. While Docker avoids VM startup overhead by keeping a persistent daemon running, Apple Container's lightweight VMs boot quickly enough that the difference is negligible for most interactive use. Memory overhead is higher per container than Docker's process-based isolation, but the trade-off provides stronger security boundaries. ### Which macOS frameworks does Apple Container use instead of Docker's HyperKit? According to [`Sources/ContainerXPC/XPCServer.swift`](https://github.com/apple/container/blob/main/Sources/ContainerXPC/XPCServer.swift) and the technical overview, Apple Container replaces Docker's HyperKit hypervisor with the **Virtualization framework**, uses **vmnet** for virtual networking instead of Docker's internal bridge, and employs **XPC** for secure inter-process communication between the CLI and runtime components. It also integrates with **Launchd** for service management and the **Keychain** for registry credential storage, creating a more native macOS experience than Docker's cross-platform approach. ### Can I migrate existing Docker workflows to Apple Container? Most standard workflows transfer directly since Apple Container consumes and produces OCI-compliant images and supports familiar CLI patterns. However, specific Docker networking configurations, volume mounts, and daemon-level settings require translation to Apple Container's TOML-based [`config.toml`](https://github.com/apple/container/blob/main/config.toml) format managed by [`Sources/ContainerPersistence/ConfigurationLoader.swift`](https://github.com/apple/container/blob/main/Sources/ContainerPersistence/ConfigurationLoader.swift). Commands like `container run` and `container build` mirror their Docker equivalents, though resource flags control per-VM allocations rather than cgroup limits within a shared system.