container: Apple's Native Container Runtime

What is the `container` Tool?

`container` is a tool built by Apple that creates and runs Linux containers as lightweight virtual machines on a Mac, written in Swift and optimized for Apple silicon. It consumes and produces OCI-compatible container images, so you can pull from and push to any standard registry. Under the hood it relies on the separate Containerization Swift package that manages low-level container, image, and process operations rather than reimplementing that layer.

Key Capabilities

• ✓Consumes and produces OCI-compatible container images, so you can pull and push to any standard registry and run the resulting images in other OCI-compatible tools, per the README.
• ✓Each container runs in its own lightweight Linux virtual machine on the Mac, rather than containers sharing one VM.
• ✓Built on the separate Containerization Swift package that manages low-level containers, images, and processes.
• ✓Written in Swift and optimized for Apple silicon, per the repo description.
• ✓Runs as a system service you start and stop with `container system start` and `container system stop`.
• ✓Distributed as a signed installer package from the GitHub release page, installed under `/usr/local`.
• ✓Upgrades and downgrades are handled by the `update-container.sh` and `uninstall-container.sh` scripts, with flags to keep (`-k`) or remove (`-d`) user data.

Getting Started with `container`

You need a Mac with Apple silicon; the README states `container` is supported on macOS 26 and that older macOS versions aren't supported, since it depends on virtualization and networking features new in that release. Download the latest signed installer package from the GitHub release page, double-click it, and enter your administrator password when prompted — the installer places files under `/usr/local`. Start the background service with `container system start`. To build `container` from source instead, the README points to a separate BUILDING.md document rather than listing build steps inline. Upgrading later can be done with the `/usr/local/bin/update-container.sh` script after stopping the running service with `container system stop`.

Running Your First Container

The README's first example is `container run --rm alpine echo hello`: it pulls the `alpine` image, runs it inside a lightweight Linux VM, prints `hello`, and removes the container once it exits. For a fuller walkthrough that builds and publishes an image of your own, the README points to a tutorial at docs/tutorials/start-here.md, plus a separate how-to doc and a full command reference for exploring the rest of the CLI.

Comparing with Other Container Runtimes

Common Questions

The problem it solves

Docker Desktop on Mac runs every container inside one shared Linux VM, so all your containers share that VM's kernel and resources. `container` gives each container its own lightweight VM instead, built directly on Apple's virtualization and networking stack via the Containerization Swift package, and it produces and consumes standard OCI images so it slots into existing registries and OCI-compatible tooling without a new image format to learn.

Best use cases

• •Running Linux containers locally on a Mac with a dedicated VM per container instead of one shared VM.
• •Pulling and running standard OCI images from existing registries via `container run`, without adopting a new image format.
• •Building and publishing your own container image, following the README's guided walkthrough in docs/tutorials/start-here.md.
• •Working inside Apple's own Swift and Containerization stack, for teams already building on the Containerization package who want the CLI Apple ships on top of it.

Who should try it — and who should skip

Try `container` if you're on a Mac with Apple silicon running macOS 26 and want per-container VM isolation built on Apple's own virtualization stack instead of Docker Desktop's shared-VM model, especially if you're already comfortable pulling and pushing OCI images. Skip it if you're on an older macOS release, an Intel Mac, or need to target Linux or Windows hosts, since none of those are supported — and hold off on production use until the project's own README stops flagging active development and pre-1.0.0 breaking changes.