Apple’s Container CLI: Run Linux on macOS Without Docker Desktop

Apple’s container CLI has been available since WWDC 2025. Most developers either missed it or filed it under “interesting, not ready.” With macOS 26 Tahoe fully shipping and WWDC 2026 starting June 8, it’s time to actually look at what this tool does — and make a decision about whether to swap out Docker Desktop on your Mac. The short answer: for single-container workflows on Apple Silicon, yes. For everything else, not yet.

This Is Not Docker with Apple Branding

The first thing to understand is that Apple’s container runtime is architecturally different from Docker Desktop — not just a different CLI skin on top of the same engine.

Docker Desktop runs a single shared Linux VM on your Mac and puts all your containers inside it, isolated from each other using Linux kernel namespaces and cgroups. It’s lightweight because all containers share that one kernel. The trade-off: if something escapes the namespace boundary, every container on that machine is exposed.

Apple’s model flips this. Every container gets its own lightweight VM, running its own Linux kernel via Apple’s Virtualization.framework. A container escape attack can’t reach other containers or the host because there’s no shared kernel to escape to. Edera, the container security startup that has been arguing for this approach for years, put it plainly after Apple’s WWDC announcement: “Apple choosing per-VM isolation validates what we’ve been saying for 3 years — namespaces were never a security boundary.”

This matters more in June 2026 than it would have in 2023. AI-assisted zero-day discovery has made the economics of container escape attacks more favorable for attackers. Running untrusted code in a namespace-isolated container is a different risk calculation today than it was two years ago.

Getting Started Takes Five Minutes

Installation via Homebrew is the quickest path. The official GitHub repository also provides signed installer packages for direct download.

brew install container
container system start
container run -it ubuntu:22.04 bash

The CLI syntax is deliberately close to Docker. Most muscle memory transfers:

docker pull nginx              → container image pull nginx
docker run -it alpine sh       → container run -it alpine sh
docker ps                      → container list
docker stop myapp              → container stop myapp
docker build .                 → container build .
docker images                  → container image list

The networking behavior is where things get genuinely better. Docker requires port mapping to make a container accessible from your Mac. Apple’s container gives every container its own IP address and an automatic hostname on .dev.internal. Run a container named myapi and it’s immediately available at http://myapi.dev.internal — no -p 3000:3000 required. For multi-service local development, this eliminates an entire class of port-collision friction.

Performance: Better Where It Counts, Slower Where It Doesn’t

Benchmarks from repoflow.io (May 2026, Apple Container vs Docker Desktop vs OrbStack on Apple Silicon) show a consistent pattern: Apple Container wins on CPU throughput (55,415 events/s vs Docker Desktop’s ~52,000) and memory bandwidth (108,588 MiB/s vs 81,634 MiB/s — a 33% lead). For compute-intensive containers, the native Apple Silicon optimization is measurable.

Docker Desktop wins on container startup time: 0.21 seconds versus 0.92 seconds for Apple container. That gap exists because Docker is spinning up a process in an already-running VM, while Apple is booting a new VM per container. Sub-second is fast — but for workflows with rapid start/stop cycles, the difference accumulates.

What’s Missing

Apple’s container CLI is at version 0.6.0. That version number is telling you something. These features are currently absent:

• Docker Compose — Not supported. Multi-container stacks require shell scripts with individual container run calls.
• Health checks — --health-cmd is not implemented.
• Restart policies — --restart=always isn’t available. Use launchd for persistent containers.
• Platform support — macOS 26 and Apple Silicon only. Linux/Windows developers on your team can’t use this.
• Ecosystem tooling — Docker Scout, Docker Extensions, Portainer — none yet compatible with Apple container.

Worth noting: OrbStack outperforms both Docker Desktop and Apple container on disk I/O and small file operations, and it supports Docker Compose. It’s a serious third option before you make any decisions.

The Decision Framework

Use Apple’s container CLI when:

• You’re spinning up single-container tools — a local Postgres, Redis, or test runner
• Security isolation matters — running AI-generated code, untrusted dependencies, or anything worth sandboxing properly
• You want to drop Docker Desktop licensing costs (Apple container is free and open source)
• You’re on macOS 26 with Apple Silicon and Compose isn’t a daily requirement

Stay on Docker Desktop or switch to OrbStack when:

• Your project uses Docker Compose — which is most projects
• Your team includes Linux or Windows developers
• Your CI/CD pipeline runs on Linux and needs local parity
• You depend on Docker Scout, Compose Watch, or Docker ecosystem extensions

The Verdict

Apple’s per-VM-per-container model is the right architecture for local container runtimes. The hypervisor-isolation approach treats security as a first-class constraint rather than an afterthought. Docker’s shared-VM approach was a performance compromise that made sense when threat models were simpler. That’s less true in 2026.

Right now, Apple’s container CLI earns a slot in your toolkit for specific use cases. It doesn’t replace Docker Desktop — not at version 0.6.0 without Compose support. But for any Mac developer who pulls a Postgres container to run tests, or who wants to sandbox AI-generated code before running it locally, it’s the better tool for that job: free, native, and genuinely more isolated.

WWDC 2026 runs June 8-12. Expect developer sessions on the Containerization framework. The WWDC 2025 session that introduced it remains the best technical deep-dive — watch it if the architecture details above caught your attention. Version 1.0 has no announced date, but the framework is already production-ready for the use cases it covers today.