The WWDC26 announcement everyone missed: your Mac is about to become a real Linux dev machine

I scrolled the WWDC26 session list and stopped at 389. Every headline was Apple Intelligence, the new Siri, the AI Agent in Xcode, Vision Pro. Wedged in among them was an 11-minute session nobody promoted.

Short title.

Discover container machines

An Apple engineer named Michael shows up, skips the fancy graphics, and opens a terminal. Three commands.

container machine create --name demo --set-default alpine
container machine run uname
container machine run

A Linux environment comes up inside the Mac.

It doesn't feel like the containers I'm used to. Files stick around. It ties into my macOS user account. The directory I'm working in is right there. It runs OCI images unchanged. And this one Linux environment lives inside its own lightweight VM.

Apple calls it a Container Machine.

For anyone doing infra or backend work, I think this was the most interesting thing at WWDC26. Simple reason: Apple isn't just building a container tool to go head-to-head with Docker Desktop. It's trying to shrink the development gap between Mac and Linux.

It started at WWDC25

To understand Container Machine you have to go back a year.

At WWDC25, Apple announced a project called Containerization — an open source framework written in Swift. The mandate is clear: run Linux containers on a Mac.

Containerization covers image management, container execution, networking, storage, a Linux init system, and VM-based isolation. On top of that sits the CLI developers actually touch. Short name too: container

Because it pulls and runs OCI-compatible images, it plugs straight into the existing container registry ecosystem.

But one design decision jumps out.

Apple spins up a VM per container

To run Linux containers on macOS you need a Linux kernel. The macOS kernel is Darwin/XNU. So tools like Docker Desktop boot a Linux VM under the hood.

Roughly, the usual structure looks like this.

Mac
 │
 └─ Linux VM
      │
      ├─ Container A
      ├─ Container B
      ├─ Container C
      └─ Container D

Apple Containerization does it differently.

Mac
 │
 ├─ Lightweight VM
 │      └─ Container A
 │
 ├─ Lightweight VM
 │      └─ Container B
 │
 └─ Lightweight VM
        └─ Container C

Every container gets its own lightweight VM. Apple describes this as VM-based isolation.

The word VM triggers one immediate thought.

"So it's slow, right?"

That was my reaction too. Since WWDC25 Apple has been hammering on sub-second startup for these lightweight VMs — under one second to boot. They're aiming at the middle ground between traditional VMs and containers.

Why bother with a VM per container

Isolation.

Container tech assumes a shared kernel. On a normal Linux box, multiple containers split the host kernel between them.

Container A ─┐
Container B ─┼─ Linux Kernel
Container C ─┘

That's why containers are lighter than VMs. A VM, by contrast, boots its own kernel. Apple leaned on Apple Silicon's virtualization performance to push that boundary all the way down to the container level. One container environment can fall over without blurring the isolation boundary next to it.

This is the most unusual part of Apple Containerization.

Then WWDC26 pushed it further

If that were the whole story, the takeaway would've been "Apple built a Docker replacement." WWDC26 added one more piece.

Container Machine.

Apple's pitch, condensed: a Linux environment as fast and light as a container, but persistent like a VM.

Ordinary containers assume disposability. Delete the container and everything you changed inside goes with it. If you need data to survive, you attach a volume.

Container Machines keep state.

Install a package with apt install nginx inside Linux today and it's still there when you boot it tomorrow.

One line summary: containers' fast creation + VMs' persistence + host integration with macOS. Apple carved out a new developer experience between containers and VMs.

Let's actually build one

Per the official docs, using it is pretty simple.

First you need an Apple Silicon Mac. The container project was built for Apple Silicon, and the currently supported environment is macOS 26. Installation means grabbing a signed installer package from GitHub Releases.

Once installed, bring up the system service.

container system start

Then create an Alpine-based Container Machine.

container machine create alpine:latest --name dev

To make it your default machine:

container machine set-default dev

Or set it at creation time.

container machine create \
  --name dev \
  --set-default \
  alpine

The WWDC26 demo runs almost exactly these commands.

Check that it's really Linux

Type uname in the Mac terminal and you get Darwin. Type container machine run uname and you get Linux.

Same terminal, one extra command in front. The kernel underneath changes. That difference matters more than it sounds.

Leave off the command and you just get an interactive shell.

container machine run

Here's where you can tell Apple sweated the details. If your Mac account is taewook, you're the same user inside the Container Machine. Your home directory carries over. If you were sitting in cd ~/projects/api-server on the Mac, the same project is right there inside the Container Machine. The docs call this automatic user creation, filesystem sharing, and consistent working directory.

From a developer's seat, that's a big shift.

The annoying part of container development today

The mental circuit used to run something like this.

My source is on the Mac → where do I mount it in the container? → -v ./src:/app/src → what's the working directory inside? → /app → file permissions? → check UID/GID → need to reach the service? → -p 8080:8080

Honestly, I've been running this circuit for years and I still occasionally blank on whether the host side of -v is the left or the right. Admitting it.

That context switching is exactly what Container Machine is trying to cut. Same paths, same user. It feels closer to swapping the kernel out for Linux and getting on with the work.

Container Machines have IPs too

Run container machine list and you get the machine list plus IPs and resource info.

In the WWDC26 demo they start a Vapor web server on Linux, then type the Container Machine's IP straight into Safari's address bar. Less need to keep Docker-style -p 8080:8080 port mapping loaded in your head for local development. Each machine has its own independent network environment.

And then systemd shows up

The other fun thing about Container Machine is how close it gets to a real Linux machine.

The official docs include an Ubuntu 24.04 example.

FROM ubuntu:24.04
ENV container container
RUN apt-get update && \
    apt-get install -y \
    dbus \
    systemd \
    openssh-server \
    curl \
    wget \
    vim \
    sudo
RUN systemctl set-default multi-user.target

Build it.

container build -t local/ubuntu-machine:latest .

Then turn it into a machine.

container machine create local/ubuntu-machine:latest --name ubuntu

Apple's own docs walk through using images that include /sbin/init as Container Machines, and ship that Ubuntu + systemd example directly.

Now you're past running a single process in a container and into an environment where PostgreSQL, Redis, nginx, and your application all run together under systemd. For backend and infra people this is the most appealing part.

It's getting closer to production Linux

Do server development on a Mac long enough and small differences always linger. Dev is macOS, production is Linux.

So the failures arrive in this order.

Works on my Mac → fails in CI → Linux library differences → permission problems → filesystem differences → systemd differences

Container Machine pulls the Linux runtime environment much closer without making you abandon the Mac.

You can keep several distros wired up at once. Create an alpine-test and an ubuntu-dev machine and use them like this.

container machine run -n alpine-test uname -a
container machine run -n ubuntu-dev uname -a

Split like that, one Mac gives you Ubuntu, Alpine, Fedora, whatever, carved up per project. Persistence means you can keep separate toolchains per project too. Project A on Ubuntu + Java 25, Project B on Alpine + Go, Project C on Ubuntu + Rust. No environment collisions, and none of the overhead of babysitting a separate VM for each.

The defaults are bigger than you'd think

Per the docs, a Container Machine's default memory is half your host memory. If you're running several machines, set resource sizes by hand.

container machine set -n dev cpus=4 memory=8G

Restart after changing.

container machine stop dev
container machine run -n dev

Add machines mindlessly on a 16GB MacBook and at some point the Mac runs out of breath first. Sketch out CPU and memory per development environment ahead of time.

Sharing your whole home directory is convenient and risky

By default, Container Machine mounts your Mac's home directory. Convenient. But it changes character the moment you run untrusted code inside a dev image.

Home usually holds ~/.ssh, ~/.aws, ~/.kube, ~/.config, git credentials, source code, personal documents. Think about a malicious npm package or a supply chain attack, and leaving all of home open read/write to every environment isn't something I'd do.

So Apple gives you home mount modes. The default is rw, but you can drop it to read-only or cut it off entirely.

container machine set -n dev home-mount=ro
container machine set -n dev home-mount=none

In real work this option matters quite a bit.

So is Docker Desktop done?

Don't get carried away here. Not yet.

Container Machine is genuinely interesting tech, but replacing the ecosystem Docker Desktop has accumulated is a different problem. Docker Desktop comes with Docker Compose, Kubernetes integration, extensions, BuildKit, Docker Context — all of it already in your muscle memory — plus a huge ecosystem around it.

Apple container uses OCI-compatible images, but it isn't the same product as the whole Docker ecosystem. The workflow where dozens of services come up with a single docker compose up is still very strong.

Writing "Docker Desktop is dead" at this point is an overstatement. This framing is more accurate: Apple has started building its own new base layer for Linux development environments on macOS.

The layer below Container Machine is the more interesting part

What I'm really watching is this line.

Container Machine → container CLI → Containerization → Apple Virtualization Framework → Apple Silicon

Apple didn't build a GUI Docker replacement. It's stacking vertically for Apple Silicon, from virtualization up through container runtime, networking, storage, and CLI. Classic Apple. Own the whole stack from hardware to developer tooling.

And it's already past 1.0

container 1.0.0 shipped on June 9, 2026. container machine was one of the headline features of that release. Apple's GitHub release notes at the time described it as long-lived Linux environments with tight host integration.

As of August 2026, GitHub Releases is up to 1.2.x. This isn't a research project that only exists as a WWDC demo — it's a real open source tool with hands on it continuously.

What Apple is going after

The intent looks pretty clear to me.

For a large share of developers on Macs today, the final deployment target is Linux.

Developer MacBook → Git → CI/CD → Container → Kubernetes → Linux Server

Developers use Macs, services run on Linux. Docker has been filling that gap for a long time. Apple wants to pull part of that connective layer inside its own platform. Container Machine makes that direction much more explicit.

The Mac/Linux boundary is blurring

Windows has had WSL for years. On the Mac that role has fallen to Docker Desktop, Colima, Lima, OrbStack. Now Apple itself has stepped in.

The approach is a little different, though. The experience Apple wants is probably this picture.

macOS
$ cd ~/projects/api
$ container machine run
Linux
$ make
$ cargo build
$ swift run

Fewer moments of "am I inside the VM right now?", "where did I mount that volume?", "why is my UID different?"

Why an 11-minute session mattered

The AI announcements are flashy. The new Siri catches the eye. Vision Pro demos make good headlines.

But changes to a development platform usually start quietly like this. An 11-minute session. A few lines of terminal. Underneath it: OCI, Linux, virtualization, container runtime, networking, storage, systemd, Apple Silicon — all wired together.

So I don't read WWDC26's Container Machine as one new CLI feature. It looks more like a signal that Apple has started dragging the Mac deeper into Linux server development territory.

No reason to delete Docker Desktop today. OrbStack and Colima don't suddenly become useless. If your dev environment is complex and Compose-centric, the existing tools are far more comfortable for a while yet.

The direction is fun, though. The old pitch was "run a Linux VM on your Mac." What Apple is building now is closer to "just develop on Linux, from your Mac."

The command that erases that boundary is this.

container machine run

In a few years, how you set up a Linux dev environment on a Mac might look pretty different from today. Or I might still have Docker Desktop running. All I've done so far is create one machine — the verdict comes after that.

References

• Apple WWDC26 — Discover container machines, Session 389. Apple describes Container Machine as a lightweight persistent Linux environment included with container.
• The Apple container project uses OCI-compatible images and was built for Apple Silicon. The current docs list macOS 26 as the supported environment.
• Home mount, CPU/memory settings, and the Ubuntu/systemd setup for container machine are documented in Apple's official GitHub docs.