rund: a containerd shim that runs containers on macOS

What a Darwin shim can and cannot do

rund is an experimental containerd shim for running Darwin containers on Darwin, and the second sentence of the README is the one that matters most for anyone evaluating it. Rund does not offer the usual level of container isolation that is achievable on other operating systems, due to the limited Darwin kernel API. The list of what it does provide is short and worth reading exactly. Filesystem isolation comes through chroot, cleanup of container processes uses a process group, there is OCI Runtime Specification compatibility to the extent it is possible on Darwin, host-network mode only, and bind mounts. The three-way split is clear. Darwin has no Linux namespaces, so there is no PID namespace, no mount namespace and no user namespace, and the containment that a Linux container gets from the kernel is simply unavailable. The chroot plus the process group is what is left, and a process group is what makes cleanup work, since a container's processes can be signalled as a group rather than tracked individually. The host-network-only limitation is the second half of that story, because without network namespaces a container shares the host's interfaces, so a container that binds a port binds it on the host, and port mapping has to be arranged outside the runtime.

The three ways to drive it, and they share a common base

The README documents three ways to use rund, and the structure of the instructions is that the first one is the base for the other two. The containerd section tells you to authenticate to the GitHub Package Registry first, then to clone rund and build it, then to clone containerd and run its daemon, and then to continue from a separate terminal without stopping containerd, where you pull a base image and run your first container.

# Download rund
git clone https://github.com/darwin-containers/rund
cd rund
# Build rund
go build -o bin/ cmd/*.go
cd ..

# Download containerd
git clone https://github.com/darwin-containers/containerd
cd containerd
# Run containerd
sudo go run cmd/containerd/main.go

The run command then passes the shim path as the runtime, and the image differs by architecture.

sudo go run cmd/ctr/main.go run --rm -t --runtime "$(pwd)/../rund/bin/containerd-shim-rund-v1" ghcr.io/darwin-containers/darwin-jail/ventura-arm64:latest my_container /bin/sh -c 'echo "Hello from Darwin container ^_^"'

The BuildKit section says to perform all the steps from the containerd section, and then to point the buildkit daemon at the rund shim through a configuration file.

[worker.containerd]
runtime = "/path/to/rund/bin/containerd-shim-rund-v1"

The Docker section says the same, perform all the steps from the containerd section, with the note that you do not need the BuildKit daemon to use Docker on Darwin. Docker on Darwin needs a daemon configuration naming the rund shim as the default runtime.

{
  "data-root": "/private/d/",
  "default-runtime": "/path/to/rund/bin/containerd-shim-rund-v1",
  "runtimes": {
    "/path/to/rund/bin/containerd-shim-rund-v1": {
      "runtimeType": "/path/to/rund/bin/containerd-shim-rund-v1"
    }
  }
}

The prerequisites are the real story

The development prerequisites section is where the constraints of this project become concrete, and the first item is the one that will stop most people. You have to disable System Integrity Protection, and the README links the containerd discussion explaining that SIP does not allow chroot. That is not a minor setting, since SIP is the mechanism that keeps a Mac from running unsigned or untrusted code at the kernel level, and turning it off on a developer machine to run containers is a meaningful change to the security posture of that machine. The second and third prerequisites are about filesystems. You need macFUSE or fuse-t installed, and you need bindfs, with the README linking build instructions for the latter, and bindfs is what makes a bind mount inside the chroot resolve to the right host path. The chroot plus the FUSE layer is essentially the whole architecture, and it is a long way from the namespace based isolation that a Linux container gets for free, which is exactly what the README means by the limited Darwin kernel API. End users are pointed elsewhere, to a homebrew-formula repository for installation and usage instructions, so the README in this repository is aimed at people working on rund itself rather than at people who just want to run a container.

The dependency list is a containerd implementation in disguise

The module manifest shows what this project actually is, and the answer is a containerd shim rather than a container runtime from scratch. The direct dependencies are almost entirely containerd packages, with the api module, containerd/v2 itself, errdefs and its package, fifo, log, plugin, ttrpc for the task API and typeurl for type registration. The runtime specification is pulled in from opencontainers/runtime-spec, which is how the shim knows what an OCI runtime must do, and creack/pty is there for pseudo terminal handling, which is what makes an interactive exec in a container work. Everything else is indirect, and the indirect list is a good map of the containerd ecosystem: go-runc, cgroups, console, continuity, platforms, the opencontainers image spec and go-digest, plus the usual Go support libraries and the logrus logger. The module targets Go 1.25.0 and the project is Apache-2.0 licensed, with the tree at the top level containing cmd/, a containerd/ directory, the module files and a CHANGELOG.adoc alongside the README.adoc. So rund plugs into the containerd plugin model rather than implementing a runtime, and the OCI compatibility it claims is compatibility with the runtime specification as expressed through that model.

Where rund is the wrong tool

The first limit is the isolation, and it is not a caveat you can engineer around on the same machine. Without PID, mount and user namespaces, a container on macOS is a chroot with a process group, which means a process that escapes the chroot has the host's filesystem and the host's network, and the README does not claim otherwise. That makes it unsuitable for running untrusted code, and suitable for the case it was built for, which is building and testing images where the security boundary is between the build and your workstation rather than between tenants. The second is that host networking is the only mode, so any workflow that depends on port mapping or on a container having its own address is out, and the port conflict behaviour is the host's. The third is the price of entry, since SIP has to be off and a FUSE filesystem and bindfs have to be installed, and that is a different class of change from installing a package. The fourth is maturity, with the recent releases at 0.0.13 from 2026-07-12, 0.0.12 from 2025-12-14 and 0.0.11 from 2025-08-12, so the version is still pre-release and the gaps between tags are months. The fifth is that this is one component of a stack, since the containerd, BuildKit and Docker instructions each require cloning a fork of that project, so you are not installing a runtime so much as assembling a set of modified ones, and the image you run comes from a separate darwin-jail project, which is where the actual jail lives.

Editorial conclusion

Adopt rund if you need OCI containers to run natively on macOS, particularly to build and test Linux images on a Mac, and you accept that the isolation is weaker than on Linux. Skip it if you need production isolation on macOS, since the kernel API does not allow it and the project says so. Verify first that you can disable System Integrity Protection on the machine, since chroot requires it, that macFUSE or fuse-t is available for the bind mount support that bindfs provides, and that the containerd, BuildKit or Docker path you choose matches the image architecture of the machine.

Frequently asked questions

Official sources

1. darwin-containers/rund on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases