Apple's container Hits 1.0.0: Linux Containers on macOS Without Docker Desktop

One year after the WWDC 2025 announcement, Apple's container project shipped 1.0.0 on June 9, 2026. That version number matters: until now, every minor release carried breaking changes, and recommending it for daily work was a gamble. With 1.0.0, the CLI and XPC APIs are stable, and the question changes from "is this a toy?" to "should this replace Docker Desktop on my Mac?"

Short answer: for some workflows, yes — and the architecture is genuinely different from everything else in the macOS container space, not just another Docker Desktop reskin. (If you'd rather learn by doing, I've written a hands-on getting-started tutorial that takes you from install to building images.)

What It Actually Is

container is a command-line tool, written entirely in Swift, that runs Linux containers on Apple silicon Macs. It builds and runs standard OCI images, pushes and pulls from any registry, and consumes the same Dockerfiles you already have. Under the hood it sits on top of Containerization, Apple's open-source Swift framework for container, image, and VM management.

The part that makes it interesting: every container gets its own lightweight virtual machine.

Docker Desktop, Colima, and OrbStack all share one design — a single Linux VM runs on your Mac, and all your containers share that VM's kernel, the same way they would on a Linux host. Apple inverted this. Each container run boots a fresh VM via the macOS Virtualization framework, with its own kernel.

If "VM per container" sounds slow, it isn't. The stack is aggressively minimal:

• The kernel is an optimized build from the Kata Containers project — the same kernel config battle-tested for exactly this microVM-per-workload pattern in multi-tenant clouds.
• The init system is vminitd, a purpose-built init written in Swift and cross-compiled with the Swift Static Linux SDK against musl libc (the same libc Alpine uses). No systemd, no distro userland — the VM boots straight into your container's entrypoint.
• Image layers are unpacked into ext4 block devices by a userspace ext4 implementation written in Swift, so the guest mounts a real filesystem instead of layering overlayfs across a VM boundary.

Cold start to a running Alpine shell is sub-second. That's the same order of magnitude as starting a container in a shared-kernel runtime, with a hard isolation boundary you don't get from namespaces and cgroups.

The Networking Model Is the Best Part

Every container gets its own IP address on a vmnet network. There is no port mapping.

1container system start
2container run --detach --name web nginx:latest
3container ls
4# NAME  IMAGE         STATE    ADDR
5# web   nginx:latest  running  192.168.64.3
6
7curl http://192.168.64.3

No -p 8080:80, no "port already allocated" because some other project's Postgres is squatting on 5432, no remembering which of your six compose stacks owns which host port. You run two services that both listen on 80 and they coexist, because they're different hosts as far as the network stack is concerned.

This is how container networking works on a real Linux box with a CNI, and it's something macOS developers have never had. Once you work this way for a week, port forwarding feels like the workaround it always was. Container-to-container networking requires macOS 26 — the vmnet APIs it depends on don't exist on Sequoia, and the project explicitly targets macOS 26+ only.

What 1.0.0 Added

The releases between the announcement and 1.0.0 quietly closed most of the day-one gaps: IPv6 and read-only mounts (0.8), a Kata 3.26 kernel, zstd layer support, and host.docker.internal-style host access (0.9), build secrets (0.11), and --cap-add/--cap-drop (0.12). The 1.0.0 release itself brings:

• container machine — a long-lived Linux environment with host integration, for when you want a persistent VM rather than ephemeral per-command containers. This is clearly aimed at the Colima/Lima crowd.
• container cp — host ↔ container file transfer, the absence of which was a constant paper cut.
• A TOML config file replacing the old defaults write-style system properties.
• API stability — XPC and CLI interfaces are now versioned commitments, which is what tooling authors were waiting for.

And yes, it runs amd64 images: Rosetta 2 translates x86_64 binaries inside the guest, so --arch amd64 works on the same images you'd pull on an Intel machine — typically faster than QEMU emulation under Docker Desktop.

Where It Loses to Docker Desktop (Today)

I'm not going to pretend this is a drop-in replacement, because it isn't:

No Compose. There is no container compose, and most real local dev is a compose file with four services in it. You can script container run invocations, and the per-container IPs make service discovery less painful than you'd think, but it's still DIY — I've written a tutorial that rebuilds a full compose stack (Postgres, Redis, app) with DNS service discovery and a Makefile, which is how I'd do it today. If your team lives in compose files, see Kubernetes vs Docker Compose for where that road leads anyway.

No local Kubernetes story. kind and minikube assume a Docker-compatible socket. Nothing here speaks the Docker API, so your DOCKER_HOST-dependent tooling — testcontainers, IDE integrations, devcontainers — doesn't work either. This is the single biggest adoption blocker and the ecosystem gap 1.0.0's stable APIs are meant to let third parties fill.

Memory accounting is per-VM. Each container carries its own kernel and a host-side helper process for I/O and networking. The kernels are tiny, but twenty containers means twenty VMs, and the shared-VM crowd (especially OrbStack, which is excellent at memory reclaim) will be lighter on a loaded laptop.

Big-image unpacking is slow. The Swift userspace ext4 writer struggles with images containing hundreds of thousands of small files — multi-gigabyte ML images that Docker unpacks in seconds have taken minutes in reports upstream. Fine for Alpine and slim images; painful for the kitchen-sink ones (which you shouldn't be shipping anyway — see my Docker image optimization guide).

Apple silicon + macOS 26 only. No Intel Macs, no older macOS. For a personal machine that's probably fine in 2026; for a fleet of corporate Macs on an N-1 OS policy, it's disqualifying for another year.

My Take: Who Should Switch

The isolation story is the underrated headline. A kernel-per-container boundary is the same defense Kata Containers and Firecracker sell in multi-tenant clouds — a container escape has to beat a hypervisor, not just namespaces. If you're running untrusted or semi-trusted code on your Mac — AI agents executing generated code, customer-submitted workloads, security research — that boundary is worth real money. It's the same trend I wrote about in NVIDIA, OpenShell, and AI agent sandboxing: the industry keeps rediscovering that the kernel is the boundary that matters.

Where I'd use it today:

• Single-container workflows — build, run, test, push. It's fast, it's native, there's no licensing conversation, and no background VM eating RAM while idle.
• Sandboxing anything you don't fully trust, where VM isolation per workload is the feature.
• CI on Mac runners, where a signed Apple installer and a system service beat managing Docker Desktop licenses.

Where I wouldn't (yet): compose-centric app development, local Kubernetes, testcontainers-heavy test suites, and giant-image ML work. Docker Desktop and OrbStack keep those crowns for now — but "now" is doing a lot of work in that sentence. Apple ships this as a signed installer with one year of velocity behind it, and the 1.0.0 API freeze is an invitation for the ecosystem to build the compose layer Apple didn't.

Frequently Asked Questions

Is Apple's container tool a Docker replacement?

Functionally it replaces Docker Desktop for building and running individual OCI containers on Apple silicon. It does not implement the Docker API, so anything that talks to a Docker socket — Compose, kind, testcontainers, devcontainers — won't work with it. Treat it as a new runtime with stock Dockerfile and registry compatibility, not a drop-in swap.

Does it run x86_64 (amd64) images on Apple silicon?

Yes. The Containerization framework uses Rosetta 2 to translate x86_64 binaries inside the Linux guest, so amd64 images run without QEMU-style full emulation and are generally faster than the equivalent under Docker Desktop's emulation path.

Why does each container get its own virtual machine? Isn't that wasteful?

Each VM boots an optimized Kata Containers kernel with a minimal Swift init (vminitd) in under a second, so the startup cost is negligible. The payoff is hardware-virtualization isolation per container — a much stronger security boundary than shared-kernel namespaces — at the cost of higher aggregate memory use when you run many containers at once.

What are the system requirements?

An Apple silicon Mac running macOS 26 (Tahoe) or later. The tool technically installs on macOS 15, but core features like container-to-container networking need vmnet APIs that only exist in macOS 26, and the project doesn't address issues on older releases.

Still weighing your options? The Apple container vs OrbStack vs Colima comparison puts the three Docker Desktop alternatives side by side. And if you're refreshing the rest of your container fundamentals, the Docker cheat sheet and Docker vs Podman security comparison pair well with this.

Evaluating container runtimes or hardening your build pipeline and want a second opinion? Get in touch.

Official References

• Dockerfile best practices — layer caching, image size and build ordering
• Dockerfile reference — every instruction and its semantics
• Linux kernel admin guide — sysctl, cgroups and kernel tunables