Apple container

Overview

Apple's container is an open-source, Swift-written command-line tool for creating and running Linux containers on Apple silicon Macs. Unlike Docker Desktop's single shared Linux VM, each container runs in its own lightweight virtual machine created through Apple's Containerization package on Virtualization.framework: the VM boots an optimised kernel and a minimal root filesystem with a small gRPC-over-vsock init (vminitd), and only the data a container needs is mounted into it, giving, in Apple's words, the isolation properties of a full VM with lower memory use. It consumes and produces standard OCI images, so images built elsewhere run and images built here push to ordinary registries; Rosetta 2 supports linux/amd64 images.

Installation is a signed package from GitHub releases followed by container system start; a launch agent (container-apiserver) and XPC helpers manage images, the vmnet network and one container-runtime-linux process per container. macOS 26 is required for full function (macOS 15 runs with limitations such as no container-to-container networking) and Xcode 26 is needed to build Containerization. The project is under active development with product (not semantic) versions; release 1.7.1 was current at verification. There is no daemon API documented for third-party SDKs and no snapshot or pause feature; the Containerization package also describes a Linux backend on cloud-hypervisor and KVM that shares the same guest contract.

Notable

• Apache-2.0; the container repository has roughly 51k GitHub stars and release 1.7.1 was current at verification; Containerization 0.1.0 is its first release with source-stability guarantees
• Requires an Apple silicon Mac and macOS 26 for full support; macOS 15 works with networking limitations
• Containerization README claims sub-second container start times from an optimised kernel and minimal root filesystem

Apple container specifications

Facts from Apple container’s public documentation, verified November 9, 2026. Performance numbers are vendor claims.

Strengths and trade-offs

Strengths

• You want per-container VM isolation on a Mac without running a shared Linux VM
• You need standard OCI images to work unchanged on Apple silicon, including amd64 via Rosetta
• You want each container to have its own IP so services are reachable without port forwarding
• You prefer an OS-vendor tool under Apache-2.0 to a commercial desktop container product

Trade-offs

• Apple silicon and macOS 26 only; Intel Macs, Linux and Windows hosts are not supported
• No snapshots, pause/resume or documented SDK beyond the CLI and an XPC API
• Memory freed inside a container's VM is not returned to macOS (ballooning only partially supported), so long-lived heavy containers may need restarts
• The project notes the initial release lacks many common containerisation features and that breaking changes may occur

Good fit for: Running Linux containers for coding agents on an Apple silicon Mac with VM-grade isolation instead of a shared VM.

Use cases Apple container fits

• Local agents: Apple’s open-source container tool runs each Linux container in its own lightweight VM on Apple silicon.

How Apple container compares

See all Apple container alternatives →

Frequently asked questions

Sources

1. github.com/apple/container
2. github.com/apple/container/blob/main/docs/technical-overview.md
3. github.com/apple/container/releases
4. github.com/apple/containerization