DEVOPS

Persistent containers promise native tooling and strong isolation, though docs, features, and memory handling need polish

HANDS ON At WWDC this week, Apple introduced container machines, which are persistent virtual machines running Linux, bearing some resemblance to Windows Subsystem for Linux (WSL) on Microsoft's operating system.

Developers using macOS, as with those on Windows, face the problem that most applications are deployed to Linux, creating a mismatch between the development machine and the deployment target. The friction is less for macOS, which, like Linux, is Unix-like, but still exists.

Apple's solution builds on the Container project previewed at WWDC last year. Version 1.0 was released at this year's WWDC, complete with the new container machine feature. The project uses standard Open Container Initiative (OCI) containers, and both the containers and container machines run on lightweight virtual machines (VMs), giving strong isolation.

On Windows, WSL is an important tool for developers. Could container machines have a similar impact for Mac devs? There is potential, but Apple has work to do both on features and documentation, and the project is tucked away on GitHub rather than being presented as part of macOS.

The code is written in Swift and is open source on GitHub under the Apache 2.0 license. It uses another Swift package called containerization, which is also open source.

We tried a brief hands-on, installing the 1.0 release from the GitHub release package on Tahoe 26.5.1. Only macOS 26 is supported.

The name "container machine" is intended to convey that the feature combines both a container and a VM. The feature uses Apple's native virtualization framework, and the command line interface integrates well with macOS. Once installed, the command container machine run will open a terminal in the default container machine.

Another option is to run a command such as container machine run uname -a, which will execute in the default container machine but without leaving the macOS shell.

Once installed, the command container machine create is enabled, though only containers that include the /sbin/init system initialization program will work. Many container images designed for running applications, rather than being used for persistent VMs, do not include this. The solution is to build a custom container image from a Dockerfile, for which the documentation now includes examples.

We used the Dockerfile supplied in a tutorial that sets up a container machine based on Ubuntu 24.04 with the Swift SDK included, followed by the steps to develop using Visual Studio Code running on macOS and connecting to the container machine via VS Code remoting. This worked and we were able to build a project on Linux and run it using VS Code and Safari on the Mac side, but debugging breakpoints were not hit. We tried again with a .NET project, for which debugging worked correctly.

By default, a container machine mounts the macOS home directory with read-write permissions. This is great for accessing code or other assets from both macOS and the container machine, but not good for security. A rogue package installed on Linux, for example, could easily harvest credentials from a .ssh folder in macOS. This is configurable via the --home-mount argument. Setting access to "none" is more secure. 

The memory available to a container machine defaults to half the system memory. In our case that is 32 GB, but after launching the VM and starting PostgreSQL, the actual memory used, according to Activity Monitor, was only 1 GB. Additional memory is used on demand, but a limitation described in the technical overview is that memory cannot be released back to the host. In other words, memory usage will increase during use and can only be released by restarting the VM.

WSL supports GUI applications via the X11 or Wayland graphic systems. An issue raised by a user about GUI applications in containers was closed on the basis that developers can install XQuartz, a project for running the X windows system on macOS, and then use container-to-host networking to connect, though we did not try this. GUI support appears not to be a goal of the project.

Mac developers already have many ways to run Linux containers or VMs, including the mature ecosystem around Docker, Podman, Colima, UTM, VirtualBox, and OrbStack, to mention some contenders, as well as the option of using SSH to connect to a remote Linux VM. That means Apple has some work to do to establish its native container tools, and now container machines, as serious alternatives.

On the plus side, the system is lightweight, aside from the inability to release memory, and performed well in our quick hands-on.

A WWDC video has further details, alongside the documentation on GitHub. ®