Apple's `container` Grows Up: Container Machines Turn Your Mac Into a Persistent Linux Box

Apple's open-source container project has quietly shipped a feature that blurs the line between a container and a full dev VM. It's called a container machine, and it's less "run my app in isolation" and more "give me a real Linux box that knows who I am and where my code lives."

If you've spent years SSHing into a Vagrant box or babysitting a Docker Desktop VM just to get a Linux userland on your Mac, this is aimed squarely at you. The pitch is simple: a fast, lightweight, persistent Linux environment, built from standard OCI images, that mounts your macOS home directory and maps your user account into the guest automatically.

Container vs. container machine

The distinction Apple draws is worth internalizing. A regular container is modeled after a single application — it runs your process and gets out of the way. A container machine is modeled after a Linux environment: it boots the image's init system, which means long-running services and process supervision actually work the way you'd expect on a real box.

The practical payoff is systemd. On an image with systemd installed, systemctl start postgresql does exactly what it says — you get a real Linux service, not a foreground process wrapped in a shell script. That alone makes container machines a better fit for testing stacks that assume an init system, cron, sockets, the whole supervised-service apparatus.

You spin up one per target distro and they all share the same $HOME and dotfiles from your Mac:

container machine create alpine:latest --name dev
container machine run -n dev whoami   # your host username, not root
container machine run -n dev pwd      # your Mac home dir, mounted
container machine run -n dev          # interactive shell

Want Alpine, Ubuntu, and Debian side by side to check that your build behaves across libc and packaging differences? Create three machines, same home directory in each, and shell into whichever one you need.

"Edit on the Mac, build inside"

The headline feature is the shared filesystem, and it's the part most likely to change your daily flow. Your repo lives in $HOME on macOS and shows up inside the machine — the docs note it's mounted at /Users/<username> inside the guest, while your shell drops you into your home directory.

That means no copy step between "I built it" and "I'm inspecting it." You keep using your macOS editor, IDE, profilers, screenshot tools, browsers and GUI debuggers, and they all see the same files the Linux side just compiled. Build inside the container machine; inspect the artifacts with native Mac tooling. For anyone who's juggled rsync, bind mounts, or a remote-development plugin to get this working, the friction reduction is the whole point.

The automatic user mapping deserves a nod too. You're not root by default — run drops you in as a user that matches your host account, with a matching UID/GID, which keeps file ownership sane across the boundary instead of leaving root-owned droppings all over your repo.

The CLI is refreshingly boring

In the best way. The command surface reads like something you can guess after about ninety seconds:

There's an m alias, so m ls and m run work if you're allergic to typing. Resizing is config-on-disk that applies after a stop/start cycle:

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

Memory defaults to half your host's RAM, and the home mount is read-write by default but can be set to ro or none if you'd rather not expose your entire home directory to the guest — a reasonable knob to have when you're running someone else's image.

Bring your own image

This is where container machines stay honest to the OCI ecosystem rather than inventing a bespoke box format. Any Linux image with /sbin/init qualifies. Apple's example builds an Ubuntu 24.04 machine with systemd plus the usual command-line furniture — openssh-server, iproute2, curl, vim-tiny, sudo — and a pile of systemctl mask/disable lines to quiet the units that don't make sense inside a container (hugepages mounts, utmp updates, and friends). Build it with container build and create a machine from the result, same as any other image.

User provisioning is pluggable. By default container runs a built-in first-boot script to set up the account matching your host. Drop an executable at /etc/machine/create-user.sh in your image and that runs instead — once, as root, on first boot — with CONTAINER_USER, CONTAINER_UID, CONTAINER_GID, CONTAINER_HOME, and CONTAINER_MACHINE_ID set. If you need LDAP, a specific shell, extra groups, whatever — that's your hook.

Where this sits

A bit of context for the framing: Apple's container is a Swift project for Apple silicon that, as a matter of architecture, leans on the platform's virtualization stack to run Linux — each workload gets its own lightweight VM rather than sharing a single beefy one the way Docker Desktop traditionally did. So "no VM" isn't quite the right mental model; "a very thin, fast, per-environment VM that you barely notice" is closer. The project has clearly struck a nerve — it's sitting north of 27,000 GitHub stars — and container machines push it from "Docker-but-Apple" toward something that competes with the get-me-a-real-Linux-box tools developers reach for daily.

The honest caveat: this is a young, fast-moving open-source effort, and the feature is documented but worth kicking the tires on before you wire it into a team workflow. But the design choices — OCI images, real init systems, automatic user and home mapping — are the right ones. If it holds up, the case for keeping a hand-rolled Linux VM around just got a lot weaker.