apple/container: Linux containers as lightweight VMs on Apple silicon

What apple/container is for, and who it is not for

The README describes `container` as a tool for creating and running Linux containers as lightweight virtual machines on a Mac, written in Swift and optimized for Apple silicon. That sentence carries the whole scope. It is not a Linux container runtime ported to macOS, and it is not a Docker Desktop replacement in the sense of running the Docker Engine inside a VM. Each container is a VM, and the project uses the Containerization Swift package for low-level container, image, and process management.

The audience is narrow on purpose. You need a Mac with Apple silicon, and the README states support for macOS 26 only, because the tool takes advantage of virtualization and networking changes in that release. The maintainers say they typically will not address issues that cannot be reproduced on macOS 26. If you are on an Intel Mac or an older macOS, this is not a tool you can evaluate at all.

On the image side the reach is wide. The tool consumes and produces OCI-compatible container images, so pulls work against any standard container registry, and images you build can be pushed back and run in other OCI-compatible applications. The restriction is the host, not the image format.

The VM-per-container model and what it changes

The README is explicit that `container` runs images inside lightweight Linux VMs rather than sharing a single Linux kernel. That is the central design choice and it drives everything else. Isolation between containers comes from the virtual machine boundary, not from namespaces and cgroups alone, because there is no shared Linux kernel to divide.

The project does not implement that boundary itself. It sits on top of the Containerization Swift package, which the README credits with low-level container, image, and process management. So the repository you are reading is the CLI and service layer, while the VM and image machinery live in a separate package. Anyone evaluating the security posture or the performance characteristics of the isolation needs to read that package too; the `container` README does not restate its internals.

There is also a system service. The README's install steps end with `container system start`, and the upgrade path begins with `container system stop`. A background service owns the container state, which is why stopping it is a prerequisite for changing versions rather than an optional courtesy.

Installing apple/container and running a first container

Installation is not a package manager command. The README points to the GitHub release page for the latest signed installer package, and says to double-click the package file and follow the instructions, entering your administrator password when prompted so the installer can place files under `/usr/local`. The current release listed in the repository is 1.3.1.

After installing, start the system service. The README gives this exact command:

container system start

The service must be running before anything else works. Once it is up, the first real use is a one-liner that pulls an image, runs it, prints output, and cleans up:

container run --rm alpine echo hello

According to the README, this pulls the `alpine` image, runs it in a lightweight Linux VM, prints `hello`, and removes the container when it exits. If you see `hello` and the command returns to your prompt, the whole path from registry pull to VM boot to process execution is working. The README points to a tutorial under `docs/tutorials/start-here.md` for a fuller walkthrough that builds and publishes an image of your own.

Upgrading, downgrading, and the pre-1.0 stability boundary

The project states its own stability terms, and they are stricter than the release cadence suggests. The README says stability is only guaranteed within patch versions, such as between 0.1.1 and 0.1.2, and that minor version releases may include breaking changes until a 1.0.0 release. Three releases shipped in August 2026 alone (1.2.2, 1.3.0, 1.3.1), so the version number is not a quiet signal.

Upgrades and downgrades share a path. You stop the running service first:

container system stop

Then either reinstall the signed package manually or run the script the installer places at `/usr/local/bin`. Upgrading to the latest release is a single command:

/usr/local/bin/update-container.sh

Downgrading is more involved, and the README is specific about the order. You must uninstall the existing tool first, choosing whether to keep user data with `-k` or remove it with `-d`, then run the update script against the older version:

/usr/local/bin/uninstall-container.sh -k
/usr/local/bin/update-container.sh -v 0.3.0

After either direction, you start the service again. The uninstall script is also the removal path on its own: `/usr/local/bin/uninstall-container.sh -d` removes the tool and your user data, while `-k` keeps the data for a later reinstall. The README does not document any in-place rollback for a service that is already running, which is why the stop step is not optional.

Where apple/container is the wrong tool

The platform floor is the first hard limit. macOS 26 is a requirement, not a recommendation, and the maintainers say they typically will not fix issues that cannot be reproduced there. A team with a mixed fleet of Macs on older releases cannot standardize on this tool today.

The pre-1.0 policy is the second. If your workflow pins a minor version and expects configuration, CLI surface, and on-disk state to survive an upgrade, the README's own statement about breaking changes between minor versions should stop you. The upgrade procedure itself, which requires stopping the service and, for a downgrade, uninstalling first, is more disruptive than swapping a binary.

The third limit is less obvious. Because each container is a virtual machine, this is not a way to run a dense fleet of processes on one Mac. The README never frames the tool as a server-side runtime or a CI fleet manager, and the supported host is a single Apple silicon Mac. If you want many long-lived containers packed onto one host with shared kernel semantics, a Linux container runtime on Linux is the right shape, and this is not it.

How it compares with Docker Desktop and with Colima

Docker Desktop also gives Mac users Linux containers, and it also runs a Linux VM underneath. The difference is what sits inside that VM. Docker Desktop runs the Docker Engine and the full Docker toolchain, so `docker` commands, Compose, and the engine API behave as they do on Linux, and containers inside the VM share a kernel. With `container`, the VM boundary is per container, and the interface is the `container` CLI rather than the Docker CLI. The README does not claim Docker CLI compatibility, so do not assume your existing `docker` scripts port over unchanged.

Colima takes a third position: it manages a Linux VM on macOS and runs a container runtime inside it, giving you a Docker or containerd endpoint. It is a lighter-weight wrapper around a single VM, and it is not tied to macOS 26 or to Apple silicon in the same way. If your reason for looking at `container` is that you want the VM per container rather than a shared VM, Colima does not offer that. If your reason is simply that you want Linux containers on a Mac with the Docker interface, Colima and Docker Desktop both keep that interface and `container` does not.

The honest summary is that `container` trades ecosystem compatibility for a different isolation model and a tighter fit with Apple's virtualization stack. Whether that trade is worth it depends on whether you need the per-container VM boundary at all.

Licence, contribution, and what to check before you depend on it

The repository is Apache-2.0, with a `LICENSE` file, a `NOTICE.md`, and a `licenserc.toml` at the top level. Apache-2.0 is a permissive licence that includes an explicit patent grant, which matters for a tool that touches virtualization and networking. That is a description of the licence text, not legal advice; if you redistribute the tool inside a product, have your own counsel read the notice file and the source headers, which carry Apple copyright lines.

Contributions go through the contributing guide in the sibling `containerization` repository rather than this one, and `MAINTAINERS.txt` lists who owns the project. The repository also carries a `BUILDING.md` for building from source, a `Makefile` whose default `BUILD_CONFIGURATION` is `debug` and which compiles with `-warnings-as-errors` unless you set `WARNINGS_AS_ERRORS=false`, and a `Protobuf.Makefile`, which tells you the service interface involves protobuf definitions.

The dependency to weigh is the Containerization package. It is a separate repository and a separate moving part, so a bug in VM or image handling may not be fixed in this repository's issue tracker. Before adopting, check that package's release notes alongside this project's, and confirm which version `Package.resolved` pins.

Editorial conclusion

Adopt apple/container if you develop on an Apple silicon Mac running macOS 26 and want OCI images without a full Linux VM daemon, and you can accept pre-1.0 churn. Do not adopt it if you need macOS versions below 26, Intel Macs, or a stability guarantee across minor releases. Before committing, verify that your machine is Apple silicon on macOS 26, that the signed installer for 1.3.1 installs cleanly, and that `container run --rm alpine echo hello` produces output after `container system start`.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes