Apple’s own answer to “Docker on a Mac”
container is a command-line tool from Apple that runs Linux containers on macOS, written in Swift and built for Apple silicon. On the surface it looks like the Docker CLI: you pull an image, run it, publish it back to a registry. Underneath it makes a different bet than every Mac container tool before it, and that bet is the whole story.
The one architectural decision that matters
Docker Desktop, Colima, OrbStack, and the rest all share a shape: one Linux virtual machine boots on your Mac, and every container you run lives inside that single shared VM, sharing one Linux kernel. container instead gives each container its own lightweight virtual machine, built on Apple’s Containerization Swift package and the system Virtualization framework.
That sounds heavier and is, in fact, designed to be lighter to reason about. Each workload gets a real isolation boundary at the VM level rather than a namespace inside a kernel everything else also touches. For anyone who has worried about container escape on a shared host, that is a meaningfully stronger default. The cost is that the model only makes sense where VM startup is cheap, which is exactly what Apple silicon plus a stripped-down guest is tuned for.
It consumes and produces OCI-compatible images, so this is not a walled garden. You pull from Docker Hub or any standard registry, and images you build push back to the same places and run anywhere else OCI runs.
What you actually need to run it
This is the part the marketing glosses and the issue tracker shouts: container targets macOS 26. The maintainers state plainly that they typically will not address issues that cannot be reproduced on macOS 26, and you need a Mac with Apple silicon. There is no Intel build and no Linux or Windows port. It is a macOS-26-on-Apple-silicon tool, full stop.
Install
Download the signed installer package from the GitHub releases page, open it, and authorize installation under /usr/local. Then start the background service:
container system startTo upgrade later, Apple ships a helper script rather than a package manager:
container system stop
/usr/local/bin/update-container.shUninstalling keeps or drops your data depending on the flag (-k keeps, -d deletes):
/usr/local/bin/uninstall-container.sh -kThere is no brew install path in the README; the signed package is the supported route.
First run
The command surface tracks Docker closely enough that muscle memory carries over:
container system start
container run --rm docker.io/library/alpine echo "hello from a VM"The guided tutorial in the repo walks through building, running, and publishing a small web server image, which is the fastest way to confirm your setup end to end.
Where the issue tracker earns its keep
The README is a download-and-go page. The most-discussed open issues are where the real limits live, and two stand out as of 2026-06:
- Outbound networking breaks on older macOS. The single loudest thread reports that on macOS Sequoia a container resolves DNS but cannot actually reach the internet. This is the practical face of the “macOS 26 only” policy: run it a major version back and core networking quietly fails. Do not treat the macOS requirement as a suggestion.
- Private registry auth is rough. A long thread documents
container image pullreturning 401 against Azure Container Registry even after a successful login. If your images live behind a cloud registry rather than Docker Hub, test authentication before you build a workflow on it.
Neither is fatal, but both reset expectations. This is a young 1.0 with 294 open issues as of 2026-06, not a decade-hardened daemon.
A note on the version
The README’s project-status text still warns that stability is only guaranteed within patch versions and that breaking changes may land before 1.0.0. That text is now behind the tags: container cut 1.0.0 in June 2026. Read the status note as historical caution rather than current state, and watch the releases page for the real cadence.
container versus the other Mac options
| apple/container | Docker Desktop | Colima | Lima | |
|---|---|---|---|---|
| Stars | 27,983 | proprietary app | 29,219 | 21,204 |
| Isolation | one VM per container | shared Linux VM | shared Linux VM | shared Linux VM |
| License | Apache-2.0 | proprietary, paid for large orgs | MIT | Apache-2.0 |
| Platforms | macOS 26, Apple silicon | macOS, Windows, Linux | macOS, Linux | macOS, Linux |
| Best at | per-workload isolation on new Macs | cross-platform team default | free Docker-compatible CLI | scriptable Linux VMs |
Counts are from GitHub as of June 2026. Colima and Lima are the open, free comparison points; both run the conventional shared-VM model and work across Intel and Apple silicon. Docker Desktop remains the cross-platform default and the safe choice for mixed teams, with paid licensing for larger companies. OrbStack is a fast proprietary Mac app with no public repository to measure. container is the outlier on isolation model and the strictest on requirements.
Where it fits, and where it does not
Reach for container if you develop on a recent Apple-silicon Mac, you are on macOS 26, and you want native, fast, per-container isolation without Docker Desktop’s licensing question. It slots into existing OCI workflows, so adopting it does not strand your images.
Look elsewhere if you need one tool across macOS, Windows, and Linux, if your team is not uniformly on macOS 26, or if you depend today on a mature multi-container orchestration story and broad third-party tooling. Those are Docker Desktop’s turf for now.
Related
For the broader picture of what is climbing on GitHub, see the daily trending digest and the weekly report. If you run language models locally on the same Mac, Ollama is a common companion to a container-based dev setup.
FAQ
Does apple/container replace Docker? For local development on a supported Mac, it can. It speaks OCI, so it uses the same images and registries. It does not replace Docker Desktop’s cross-platform reach or its orchestration ecosystem.
Can I run it on an Intel Mac or older macOS? No. It requires Apple silicon and targets macOS 26; on older macOS, outbound networking is among the reported failures.
Is it free? Yes, it is Apache-2.0 licensed and open source.
Why one VM per container? Stronger isolation. Each container gets a real VM boundary instead of sharing one kernel with every other container, a trade Apple silicon makes cheap enough to be practical.