Apple research team recently released the container project. It is an open-source command-line tool written in Swift. It creates and runs Linux containers as lightweight virtual machines on a Mac. The project ships under the Apache 2.0 license and targets Apple silicon.

Containers are how you ship reproducible environments from a laptop to a datacenter. Apple now offers a native path that avoids a single always-on Linux VM.

What is Apple’s container ?

container is a CLI tool that can be used to build images, run containers, and move images to and from registries. It consumes and produces OCI-compatible container images. So you can pull from Docker Hub or GitHub Container Registry and run those images. You can also push images you build to any standard registry.

container uses the open-source Containerization Swift package. That package handles low-level container, image, and process management. The tool requires a Mac with Apple silicon. Intel Macs are not supported. Apple supports container on macOS 26, which adds virtualization and networking enhancements. You can run it on macOS 15, but with networking limitations.

How container Runs Your Containers

Most macOS container tools run one shared Linux VM that hosts every container. Apple takes a different path. container runs a separate lightweight VM for each container you create. Apple describes three properties of this design:

• Security: Each container has the isolation of a full VM. A minimal set of core utilities and dynamic libraries reduces resource use and attack surface.
• Privacy: You mount only the data each VM needs, instead of sharing everything.
• Performance: These containers use less memory than full VMs. Boot times are comparable to containers in a shared VM.

The runtime integrates several macOS frameworks. It uses the Virtualization framework for the VMs, and the vmnet framework for networking. It uses XPC for interprocess communication, launchd for service management, and Keychain services for registry credentials.

The control plane has a few moving parts. container system start launches container-apiserver, a launch agent. The apiserver then starts an XPC helper container-core-images for image management and the local content store. It also starts container-network-vmnet for the virtual network. For each container, it launches container-runtime-linux, the per-container management helper.

Interactive Explainer

Use Cases With Examples

Local backend development. Run a service in its own isolated VM, then forward a port to your loopback address.

container run -d --rm -p 127.0.0.1:8080:8000 \
  node:latest npx http-server -a :: -p 8000
curl http://127.0.0.1:8080

Reproducible CI-style builds. container build starts a builder utility container that uses BuildKit. You can size the builder VM for heavy builds.

container builder start --cpus 8 --memory 32g
container build --tag web-test:latest --file Dockerfile 

Cross-architecture images for datacenter deployment. Build one image for both Apple silicon and x86-64 servers. The amd64 variant runs under Rosetta translation.

container build --arch arm64 --arch amd64 \
  --tag registry.example.com/fido/web-test:latest

Mounting datasets for analysis. Share a host folder into the container with --volume. This is useful for feeding local data into a containerized job.

container run --volume ${HOME}/Desktop/assets:/content/assets \
  docker.io/python:alpine ls -l /content/assets

Isolating untrusted or generated code. Each container runs in its own VM, not a shared kernel. That boundary suits running code from an agent or an unknown image with less host exposure.

Hands-On: Core Commands

Default container resources are 1 GiB of RAM and 4 CPUs. You override them per run.

container run --rm --cpus 8 --memory 32g big

Inspect live resource usage, similar to top for processes.

container stats --no-stream my-web-server

Read virtual machine boot and init logs when debugging startup.

container logs --boot my-web-server

On macOS 26, you can create isolated networks. Containers on different networks cannot reach each other.

container network create foo --subnet 192.168.100.0/24
container run -d --name web --network foo --rm web-test

By default, containers start with a restricted set of Linux capabilities. You tune them explicitly.

container run --cap-drop ALL --cap-add SETUID --cap-add SETGID alpine id

Version 1.0.0 also adds container machines. These are persistent Linux environments built from OCI images. Your home directory is mounted in, and the login user matches your Mac account. The filesystem survives stop and start. Any image containing /sbin/init qualifies as a container machine.

Two other 1.0.0 changes affect upgraders. System settings moved to a TOML file at ~/.config/container/config.toml. The container system property get and set subcommands were removed. The tool also added structured JSON, YAML, and TOML output for list and inspect, easing automation.

Apple container vs Docker Desktop

Strengths and Limitations

Strengths: Per-container VM isolation reduces shared attack surface versus a shared kernel. Idle memory cost is low, since stopped containers free their footprint. OCI compatibility means your images run elsewhere without conversion. The Apache 2.0 license carries no feature paywall.

Limitations: The macOS Virtualization framework supports only partial memory ballooning. Pages freed inside a container are not always relinquished to the host. Heavy workloads may need occasional restarts to reduce memory use. There is no built-in Docker Compose. macOS 15 users face networking restrictions, and Intel Macs are unsupported.

Check out the Repo here. Also, feel free to follow us on Twitter and don’t forget to join our 150k+ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well.

Need to partner with us for promoting your GitHub Repo OR Hugging Face Page OR Product Release OR Webinar etc.? Connect with us