What Apple’s Native Containers Mean for Docker Users

Did you know you can now run containers natively on macOS? At WWDC 2025, Apple announced Containerization and Container CLI — in other words, native Linux container support. Historically, running containers on macOS required launching a full Linux VM, typically via HyperKit or QEMU, to host the Docker Engine. That’s no longer necessary. This is a major shift because Apple’s containerization framework means developers may no longer need third-party tools like Docker for local container execution.

Using Apple's new Virtualization and Containerization frameworks, each container runs natively on macOS inside its own lightweight Linux VM. These VMs boot in under a second, isolate workloads cleanly, and are tightly optimized for Apple silicon. Effectively, Apple gives each container a minimal kernel environment without the overhead of managing a full VM runtime.

Getting Started With Apple’s Container Tool

Let’s test it! Before you begin, note that the tool is only compatible with M series Macs; Intel-based Macs aren't supported. Install the CLI from Apple’s GitHub release under Assets.

Once installed, start it with the following command:

container system start

On first run, it may pull a minimal Linux kernel used to spin up VMs. Accept the prompt if needed.

Run your first container:

container run -t -i alpine:latest sh

Run a Container Application

Let’s containerize a sample Python app from sylvainkalache/sample-web-apps/python.

The Container tool expects an OCI image, typically built from a Dockerfile:

container build -t my-python-app .

But I’d prefer to skip writing a Dockerfile entirely. Instead, I use Buildpacks, which do a better job of containerizing apps anyway.

Install the pack CLI (instructions online), then run:

pack build my-python-app

This builds a full OCI image, which you can then run natively:

container run my-python-app

Behind the scenes, macOS spins up a Swift-optimized Linux VM and runs the app in a Linux environment — no Docker Engine required.

What Makes Apple’s Approach Different

There are a few things that make Apple’s approach to containers different and improve the non-native implementation we are used to.

Regarding security, traditional containers share the host kernel, leaving them vulnerable to shared-kernel vulnerabilities. Apple’s model runs each workload inside its own VM with minimal dependencies, reducing attack surfaces. 

Then, every container receives its own IP address, eliminating the need for port forwarding and providing high-performance network access. Also, CPU and memory resources are allocated per container, with no resource consumption when containers aren't running.

How Fast Is It

As mentioned earlier, even though each container runs in its own VM, the framework can still spin up containers in under a second thanks to a few specific optimizations.

First, it leverages EXT4 block devices for high-performance disk access. Second, Apple customizes its kernel configuration for container workloads. Third, and not least, the entire stack is optimized for Apple’s custom silicon architecture, which is no surprise given the company's successful efforts to make its chips drastically faster. Intel must be closely watching.

Is This a Replacement for Docker

Might be the most important question, and in my opinion: not at all. Docker operates at a higher level. Docker Compose, desktop UI, debugging tools, and hub serve broader development and orchestration needs. Apple’s container runtime operates at a lower level. In fact, it can improve the Docker experience by itself because Docker no longer needs to manage its own background VM to run containers on macOS, which yields better performance and improved security.

For developers, the biggest win is ergonomics: standard OCI images still work, Docker Compose files remain useful, and build tools like Buildpacks produce runnable artifacts without extra shims. Native networking eliminates awkward port forwarding, while per-container micro-VMs enhance isolation without incurring a noticeable startup penalty. If Apple exposes more APIs, tools like kind and minikube could plug in directly, making local Kubernetes clusters faster, quieter, and far more predictable for everyday Mac development.

What This Means for Kubernetes?

While Apple’s long-term intentions are unclear, if the company continues to invest here, I believe we may see this runtime integrated directly into Kubernetes developer workflows. Tools like kind or minikube could leverage macOS’s native virtualization stack instead of relying on external VMs, simplifying cluster bootstrapping and making local testing more reliable. 

It also raises a bigger question: is Apple aligning with a broader industry trend toward containers as micro-VMs? With AWS Firecracker and Kata Containers already proving the model, native macOS support gives the approach even more legitimacy.

More Than 10 Years in the Making

Docker democratized containers over a decade ago, and finally, Apple delivers native support. The community had filled the gap with tools like OrbStack or Lazydocker, but now, with deep integration into macOS and Apple Silicon, the experience has gotten a lot smoother. 

I am looking forward to seeing what the community will do with this long-awaited native integration.