Apple Container Machines: Linux VMs on macOS

Most of the attention at WWDC went to Apple's AI announcements and operating system updates, but one developer tool quietly stood out: Container Machines. It gives macOS developers a native way to run persistent Linux virtual machines, offering a new option for building and testing Linux workloads without relying on third-party virtualization tools.

Container Machines builds on Apple's open-source container project, which takes a different approach from traditional Docker setups. Instead of running containers inside a shared Linux environment, it uses lightweight virtual machines designed specifically for Apple Silicon. The result is a development environment that feels more integrated with macOS while still providing the Linux compatibility many developers need.

It's still early days, though. While Container Machines fits naturally into Apple's developer ecosystem, it doesn't yet match the maturity or feature set of tools like Docker Desktop or OrbStack. In this article, we'll explore how Container Machines works, walk through the setup process, and compare its capabilities and limitations with the most popular container runtimes available on macOS today.

How it works

Most Linux virtualization tools on macOS, including Docker Desktop, run a single shared Linux VM and schedule containers inside it. Apple's container tool takes a different approach: each container gets its own dedicated micro-VM, spun up using the native macOS Virtualization framework. Container Machines extends this to support persistent, full-system VMs built from OCI images.

The per-VM isolation model has a security benefit: a process that escapes a container is still sandboxed within its own VM rather than having access to a shared host environment. The tradeoff is startup time, which we'll cover in the benchmarks section.

Because the tool uses the native Virtualization framework rather than an emulation layer, CPU and memory performance are close to native on Apple Silicon.

Prerequisites

Container Machines require a Mac with Apple Silicon and macOS 26 (Sequoia) or newer. The container tool itself is available from the apple/container GitHub repository.

Download the .pkg installer from the Releases section and run it. Once installed, the container command is available in your terminal.

Building an Ubuntu machine

A Container Machine is created from an OCI image, the same format Docker uses. The image needs to include a system initialization program like systemd to function as a full operating system rather than just a container. Here's a Dockerfile that produces a working Ubuntu 24.04 machine:

FROM ubuntu:24.04

ENV container=container

RUN apt-get update && \
    apt-get install -y \
    dbus systemd openssh-server net-tools iproute2 iputils-ping curl git \
    && apt-get clean && \
    rm -rf /var/lib/apt/lists/* && \
    yes | unminimize

RUN > /etc/machine-id
RUN > /var/lib/dbus/machine-id

RUN systemctl set-default multi-user.target
RUN systemctl mask \
    dev-hugepages.mount \
    sys-fs-fuse-connections.mount \
    systemd-update-utmp.service \
    systemd-tmpfiles-setup.service \
    console-getty.service
RUN systemctl disable \
    networkd-dispatcher.service

RUN sed -i -e 's/^AcceptEnv LANG LC_.*$/#&/' /etc/ssh/sshd_config

Build the image with:

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

The build process works like docker build, downloading the base image and executing each RUN instruction with layer caching. Once it completes, create a machine from the image:

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

The --name flag assigns a friendly name and --set-default marks it as the target for subsequent commands so you don't have to specify the name each time. The machine boots in seconds.

Managing and accessing machines

container machine ls shows all running machines with their IP address, CPU count, memory allocation, disk usage, and state:

container machine ls

By default, a machine gets half your Mac's total RAM. To open an interactive shell:

container machine run

Your prompt changes to reflect the Linux environment. To verify:

uname -a

You can also run one-off commands without entering an interactive session:

container machine run ls -l /

File sharing

When a machine starts, your macOS username is mapped into the Linux environment and your entire home directory is automatically mounted with read-write access. There's no manual configuration, no SCP, no volume declarations.

This makes cross-platform development straightforward. You can write code with your regular macOS editor, compile a Linux binary on macOS, and immediately run it inside the VM since both environments see the same filesystem:

bun build ./src/server.ts --compile --target=bun-linux-arm64 --outfile ./dist/my-app-linux

Then inside the machine:

./dist/my-app-linux

The one gap is filesystem events. File changes made on the macOS side don't always propagate as events into the guest VM, which means hot-reloading in a development server running inside the machine may not pick up edits made from a macOS editor. The recommended workaround is VS Code's Remote - SSH extension, which connects directly to the machine over SSH so edits happen from the Linux side and events fire correctly.

Performance

Benchmarks from RepoFlow comparing Apple's container tool against Docker Desktop and OrbStack show strong CPU performance, on par with or slightly ahead of both alternatives for single-threaded and multi-threaded tasks. Memory throughput is the clearest win, significantly higher than both Docker Desktop and OrbStack.

The weak point is container startup time. Spinning up a dedicated micro-VM for each container is slower than scheduling a container inside an already-running shared VM. For long-running machines this doesn't matter much, but it's noticeable if you're starting and stopping containers frequently.

Limitations

A few limitations are worth knowing before committing to this tool.

Memory retention. The most significant operational issue is that memory allocated to a machine isn't released back to macOS when the processes using it finish. If a compilation job consumes several gigabytes, that memory stays allocated to the VM until you stop or restart it. OrbStack handles this with dynamic memory management; Apple's tool currently does not.

No GPU passthrough. You can't access the Mac GPU from inside a container machine, which rules it out for GPU-accelerated workloads like machine learning or video processing.

No USB passthrough. USB devices can't be connected from the host to the guest.

No GUI support. Running graphical Linux applications requires complex manual configuration and isn't supported out of the box.

Home directory access. The automatic read-write mount of your entire home directory is convenient but gives any code running inside the machine full access to SSH keys, cloud credentials, and everything else in your home folder. You can configure the mount as read-only or disable it, but there's currently no built-in way to mount only a specific project directory.

Feature requests for most of these are open on the project's GitHub.

When to use it

For CLI-based Linux development on Apple Silicon, Container Machines are a strong free alternative to Docker Desktop. Setup is fast, file sharing works without configuration, and CPU and memory performance are competitive. If you're running Docker Desktop mainly to get a Linux environment for compiling or testing, this is worth evaluating.

If you need dynamic memory management, GPU access, mature GUI support, or a more complete feature set, OrbStack remains the more capable option despite its commercial license for business use. Apple's tool is a solid foundation but still has gaps that matter for certain workflows.

Got an article suggestion? Let us know

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.