Avik
back|containers

I Tried Apple's Native Container CLI So You Don't Have To (Yet)

By Avik MukherjeeMay 2, 202612 min readUpdated May 2, 2026

I Tried Apple's Native Container CLI So You Don't Have To (Yet)#

I've been using Docker Desktop on my Mac for years. It just worked. Never questioned it. Never had a reason to. Then Apple shipped macOS 26 Tahoe with a native container CLI, and I finally had a reason.

So I spent a weekend with it. Spun up containers. Built images. Hit walls. Found workarounds. Hit more walls.

This is what I actually found.

What Even Is the Apple Container CLI?#

There were two things announced at WWDC 2025: a Containerization framework and a container CLI tool that aims to be OCI compliant. The CLI is written in Swift, open sourced on GitHub, and it takes advantage of new virtualization and networking features in macOS 26.

The key idea is VM per container. Where Docker Desktop runs all your containers inside a single shared Linux VM, Apple boots a dedicated lightweight VM for each one. The isolation boundary is not a Linux namespace. It is a full virtual machine.

Why does that matter? If a vulnerability in your container allows kernel level exploitation, it hits that VM's wall and stops there. No shared kernel. No noisy neighbors. Each container is its own little fortress.

The kernel comes from the Kata Containers project, and you get prompted to install it the first time you start the service. That tells you something important: Apple isn't building a new kernel. They're using a proven one and wrapping it in their virtualization framework.

Getting It Running#

You need an Apple Silicon Mac (M1 or later) and macOS 26 Tahoe. Install via Homebrew:

bash
brew install container

Verify it is there:

bash
container --version

Then start the service:

bash
container system start

On the first run, it prompts you to install a Linux kernel:

code
Verifying apiserver is running...
Installing base container filesystem...
No default kernel configured.
Install the recommended default kernel from [...kata-containers...]? [Y/n]: y
Installing kernel...

Once that finishes, list all containers to confirm everything is working:

bash
container list --all

Empty list means you are good to go. That's it. No Docker account. No license agreement. No "Docker Desktop is starting..." spinner that feels like it's mining Bitcoin in the background.

Running Your First Container#

The syntax is deliberately familiar. If you have used Docker, almost everything maps directly:

bash
container run --name web --detach -p 8080:80/tcp nginx:latest

Each container gets its own IP on a private network. No shared kernel. Containers achieve sub-second start times using an optimized Linux kernel configuration. Resource efficiency is real too: containers consume resources only when active, and when no containers are running, no system resources are consumed.

Test it:

bash
curl http://localhost:8080

You should see the nginx welcome page. If you see an empty reply instead, that is a macOS Local Network firewall issue. Go to System Settings, Privacy and Security, Local Network, and toggle your terminal app and container-runtime-linux both to ON. That is the fix. I spent 20 minutes on this before finding it. You're welcome.

Building Images#

The Dockerfile syntax is identical to Docker. Here is a simple Python web server:

dockerfile
FROM docker.io/python:alpine
WORKDIR /content
RUN apk add curl
RUN echo '<!DOCTYPE html><html><head><title>Hello</title></head><body><h1>Hello, world!</h1></body></html>' > index.html
CMD ["python3", "-m", "http.server", "80", "--bind", "0.0.0.0"]

Build it:

bash
container build --tag web-test --file Dockerfile .

Run it:

bash
container run --name my-web-server --detach --rm web-test

List images and you will see both the base image and the one you just built:

code
NAME      TAG     DIGEST
python    alpine  b4d299311845...
web-test  latest  25b99501f174...

That felt weirdly smooth. Building and running worked exactly like Docker. No gotchas. No "you need to configure X first." It just worked.

Day to Day Commands#

These all map directly from Docker muscle memory:

bash
# View logs
container logs -f my-web-server
 
# Monitor resource usage
container stats my-web-server
 
# Run a command inside a running container
container exec my-web-server ls /content
 
# Get an interactive shell
container exec -ti my-web-server sh
 
# Stop and clean up
container stop my-web-server
container system stop

The --rm flag removes the container automatically when it stops, which is what you want for most development workflows.

Setting Up Local DNS#

The CLI ships with an embedded DNS service. You can set up a local domain so containers are reachable by name instead of IP:

bash
sudo container system dns create test
container system property set dns.domain test

After that, a container started with --name my-web-server is reachable at my-web-server.test. Much cleaner than memorizing IP addresses. This is one of those small quality of life things that Docker doesn't give you out of the box.

Where It Still Falls Short#

Here is where I stop being nice.

There is no compose. Not yet. You are given primitives like container run, container build, container system dns, container network and expected to assemble them yourself. Community projects like container-compose on GitHub are starting to fill this gap, but nothing is production ready.

Inter-container networking only works fully on macOS 26. If you are on macOS 15, containers on the same network cannot communicate with each other. That is a hard blocker for most real development work.

Memory usage adds up fast. Running a three service stack means three separate VMs. Each one has its own kernel. That adds up. Docker Desktop uses one shared VM, which has overhead but is more memory efficient for development where you spin up 4 or 5 services with a database.

This is fine for production use where extra isolation is appropriate in a multitenant cloud environment, but it is rough for local development. I tried running a typical web app + postgres + redis stack and my M2 Pro started sweating.

The ecosystem is thin. No comprehensive monitoring solutions. No enterprise management capabilities. No Kubernetes integration. Docker's tooling ecosystem is years ahead and that gap shows immediately when you try to do anything beyond basic container operations.

When to Use It vs Docker Desktop#

After spending a weekend with it, here is my honest take.

Use the Apple container CLI when you are running isolated, single container workflows. Spinning up a database to test a migration. Running a build tool in a clean environment. Testing a container image before pushing it. For these cases it is faster, lighter, and better isolated than Docker.

Stay with Docker Desktop when you need multi service orchestration with Compose, local Kubernetes testing, or you are on an Intel Mac.

A practical hybrid approach that makes sense right now: use container for quick isolated runs, and reach for Docker when a project needs a full stack. That is what I have been doing this week and it works.

What I Actually Learned#

I want to be honest: I went into this expecting to be underwhelmed. Apple making a container runtime? Sounded like a "me too" product.

I was wrong about a few things.

VM per container is a genuinely different approach. It is not just "Docker but Apple." The isolation model is fundamentally different. Whether that matters for your day to day development workflow is debatable, but for security sensitive environments, it is real.

Sub-second cold starts are not marketing. Containers genuinely start fast. No background daemon eating RAM when you are not using it. No licensing fees. The "it just works when you need it, disappears when you don't" experience is something Docker Desktop has never quite achieved.

The gap is mostly orchestration and ecosystem maturity. The core container runtime works. Building, running, stopping containers all worked reliably in my testing. What is missing is the glue: compose, service discovery at scale, monitoring dashboards, Kubernetes integration. Both of those close over time.

Docker's shared VM model has real overhead, but its tooling ecosystem is years ahead. That is the tradeoff. Apple gives you better isolation and lower idle resource usage. Docker gives you a complete workflow. Neither is objectively better. They are different tools for different situations.

What's Missing vs Docker Desktop#

A lot. And that is fine for a pre 1.0 tool.

  • Docker Compose - The biggest gap. No multi-service orchestration.
  • Volume management - No persistent volumes worth talking about.
  • Network orchestration - Basic networking works, complex topologies do not.
  • Kubernetes support - None. Not even hinted at.
  • Image registry integration - Basic pull/push works, but no advanced auth or registry management.
  • GUI - CLI only. Docker Desktop's dashboard is actually useful for visualizing what is running.

The Apple container CLI is a solid foundation. It is not a Docker Desktop replacement yet. It might be one day. Today it is a very good tool for very specific use cases.

The Bigger Picture#

Apple entering the container runtime space is significant regardless of whether this tool is ready for prime time.

The foundation is genuinely solid. Sub-second cold starts. VM level isolation. No background daemon eating RAM when you are not using it. No licensing fees. Swift based, open source, built on Apple's own virtualization framework.

The gap between what this tool can do today and what Docker Desktop offers is mostly in orchestration and ecosystem maturity. Both of those close over time. The underlying architecture does not need to change. It just needs more tooling built on top of it.

I did not expect to say this a week ago, but I think Apple is serious about this.

The Bottom Line#

The Apple container CLI is not a Docker Desktop killer. Not today. Maybe not this year.

But it is a very good tool for isolated container workflows, and it is only going to get better. If your daily work involves spinning up single containers for testing, building, or quick experiments, give it a try. You might find yourself reaching for Docker Desktop less often than you expect.

The core insight: Apple did not build a Docker clone. They built a container runtime with a fundamentally different isolation model, optimized for Apple Silicon, integrated into the OS. Whether that matters to you depends entirely on what you use containers for.

Let's Keep Talking#

Have you tried the Apple container CLI yet? What was your experience like?

Are you still on Docker Desktop, or have you moved to something like Podman or Colima?

Do share this post if you found it useful, or reach out on GitHub. If you spot something I got wrong about the container CLI, I'd rather fix it than leave it wrong.

Until next time.

If you want to talk containers, developer tooling, or just what it's like to be a developer in 2026 — find me on GitHub, X, Peerlist, or LinkedIn.

Feedback welcome.

Related posts

Sponsor

Support my open-source work

If my projects, blog posts, or tools have helped you, consider sponsoring me on GitHub. Every contribution keeps the side projects shipping.

Sponsor on GitHub