# How Apple Container Provides Isolation for Containers: VM-Based Architecture Explained > Discover how Apple Container uses VM-based architecture with the macOS Virtualization framework to provide robust isolation for containers, ensuring security and performance. - Repository: [Apple/container](https://github.com/apple/container) - Tags: internals - Published: 2026-06-23 --- **Apple Container isolates containers by running each one inside a dedicated lightweight Linux VM using the macOS Virtualization framework, providing security, privacy, and performance isolation comparable to full virtual machines while consuming minimal resources.** Apple Container approaches container isolation differently than traditional Linux container runtimes. Instead of sharing the host kernel, the open-source `apple/container` repository implements a virtualization-first architecture where every container receives its own sandboxed environment. This design leverages macOS-native virtualization technologies to deliver strong isolation guarantees without the overhead typically associated with full virtual machines. ## How Apple Container Isolation Works Apple Container provides isolation through three primary mechanisms: security boundaries, privacy controls, and resource quotas. Each container runs in a separate Linux VM orchestrated by the `container-runtime-linux` helper, ensuring that processes, filesystems, and network stacks remain separate from the host and other containers. ### VM-Based Security Isolation The foundation of Apple Container isolation is the lightweight Linux virtual machine created for each container. According to the technical documentation, every container instance launches with a minimal set of core utilities and libraries, drastically limiting the attack surface compared to shared-kernel containerization. The [`ContainerConfiguration.swift`](https://github.com/apple/container/blob/main/ContainerConfiguration.swift) file defines the default runtime handler as `"container-runtime-linux"`, which instructs the system to create a fresh VM rather than sharing kernel resources. In `Sources/Plugins/RuntimeLinux/RuntimeLinuxHelper+Start.swift`, the XPC service registers this runtime handler and maps the `"container-runtime-linux"` label to the helper responsible for VM creation. This architecture ensures that even if a container process is compromised, the attacker remains confined within the single-purpose VM and cannot access the host macOS system or other containers. ### Privacy Through Filesystem Isolation Apple Container enforces strict filesystem boundaries between the host and containers. Only explicitly mounted host files are visible inside the VM; containers do not inherit shared filesystems from other instances. This means that by default, a container cannot access host user data, other containers' volumes, or system directories unless specifically granted through mount points. The isolation is absolute at the VM boundary—each Linux kernel operates independently with its own virtualized block devices and mount namespaces, preventing information leakage between tenant workloads. ### Performance Isolation with Resource Quotas Each VM receives dedicated CPU, memory, and storage quotas, preventing the "noisy neighbor" problem common in shared-kernel containerization. The macOS Virtualization framework allocates these resources at the hypervisor level, ensuring that one container cannot starve others of system resources. Resource constraints are enforced through the VM's scheduler and memory ballooning mechanisms. When you specify limits via command-line flags, the runtime configures the underlying VM hardware parameters rather than relying on cgroup-based controls. ## Architecture of Apple Container Isolation The isolation architecture relies on tight integration between the Virtualization framework, XPC services, and macOS networking APIs. ### The Runtime Linux Helper The `RuntimeLinuxHelper+Start.swift` file implements the XPC service that bridges the container CLI with the macOS Virtualization framework. When you execute `container run`, the `container-apiserver` launch agent (a system service) starts the runtime helper, which then provisions the isolated Linux VM. This helper is responsible for: - Initializing the virtual machine configuration - Setting up the minimal Linux userspace - Establishing communication channels between the host and the isolated guest ### Network Isolation via vmnet Network isolation is implemented through the macOS `vmnet` framework, as seen in [`Sources/Plugins/NetworkVmnet/NetworkVmnetHelper.swift`](https://github.com/apple/container/blob/main/Sources/Plugins/NetworkVmnet/NetworkVmnetHelper.swift). By default, containers operate on host-only networks where they cannot communicate with each other. The framework distinguishes between isolated and non-isolated interfaces through strategies defined in [`Sources/Services/RuntimeLinux/Server/NonisolatedInterfaceStrategy.swift`](https://github.com/apple/container/blob/main/Sources/Services/RuntimeLinux/Server/NonisolatedInterfaceStrategy.swift). The `IsolatedInterfaceStrategy` attaches dedicated virtual network interfaces to each per-container VM, ensuring traffic remains contained within the virtualized boundary. On macOS 15, the vmnet framework strictly provides host-only isolation, meaning containers attached to the same network cannot communicate with one another. Shared networking between containers requires newer macOS versions and explicit network attachment configuration. ## Configuring Isolation in Practice Apple Container applies full isolation by default—no additional flags are required to enable VM-based separation. ### Running a Standard Isolated Container ```bash # Creates a fresh lightweight VM automatically container run -it ubuntu:latest /bin/bash ``` This command provisions a new Linux VM with isolated CPU, memory, filesystem, and network stack. ### Attaching to Private Networks When supported (macOS 26+), you can create named networks that provide additional segmentation: ```bash # Create a named vmnet network container network create mynet # Run container attached to isolated network container run --network mynet -d nginx:latest ``` Each container on `mynet` receives its own virtual NIC that remains unreachable from containers on other networks or the default host-only interface. ### Enforcing Resource Limits Demonstrate performance isolation by constraining VM resources: ```bash # Limit to 1 CPU and 512 MiB RAM container run -d --cpus 1 --memory 512M alpine:latest sleep 3600 ``` The Virtualization framework enforces these quotas at the hypervisor level, with the VM's internal scheduler handling CPU caps and ballooning mechanisms managing memory constraints. ## Summary - **Apple Container isolation** relies on dedicated Linux VMs per container using the macOS Virtualization framework, not shared kernel namespaces. - **Security isolation** is enforced by the `container-runtime-linux` helper in `RuntimeLinuxHelper+Start.swift`, which creates minimal single-purpose VMs. - **Privacy isolation** prevents filesystem leakage by only exposing explicitly mounted host directories to each VM. - **Network isolation** uses the `vmnet` framework via [`NetworkVmnetHelper.swift`](https://github.com/apple/container/blob/main/NetworkVmnetHelper.swift), defaulting to host-only mode where containers cannot communicate. - **Performance isolation** dedicates CPU, memory, and storage quotas to each VM, preventing resource starvation between containers. ## Frequently Asked Questions ### How does Apple Container isolation differ from Docker? Apple Container uses hardware virtualization to run each container in a separate Linux VM, while Docker uses OS-level virtualization with shared kernel namespaces. This means Apple Container provides stronger isolation boundaries comparable to virtual machines, whereas Docker relies on Linux kernel features like cgroups and namespaces for separation. ### Can containers communicate with each other in Apple Container? By default, no. On macOS 15, the vmnet framework only supports host-only networking, meaning containers are isolated from each other and cannot communicate over the network. Newer macOS versions may support shared networking configurations, but this requires explicit setup using `container network create` and the `--network` flag. ### What files control the isolation behavior in Apple Container? Key implementation files include [`Sources/ContainerResource/Container/ContainerConfiguration.swift`](https://github.com/apple/container/blob/main/Sources/ContainerResource/Container/ContainerConfiguration.swift) (defines the runtime handler), `Sources/Plugins/RuntimeLinux/RuntimeLinuxHelper+Start.swift` (manages VM creation), and [`Sources/Plugins/NetworkVmnet/NetworkVmnetHelper.swift`](https://github.com/apple/container/blob/main/Sources/Plugins/NetworkVmnet/NetworkVmnetHelper.swift) (handles network isolation). The [`Sources/Services/RuntimeLinux/Server/NonisolatedInterfaceStrategy.swift`](https://github.com/apple/container/blob/main/Sources/Services/RuntimeLinux/Server/NonisolatedInterfaceStrategy.swift) file distinguishes between isolated and non-isolated network interfaces. ### Does Apple Container isolate the filesystem between containers? Yes. Each container runs in its own VM with an independent virtualized block device and Linux kernel. Only explicitly mounted host directories are visible inside the container, and there is no shared filesystem layer between containers. This provides stronger privacy isolation than traditional overlay filesystem approaches used in standard container runtimes.