COMPARE

Kiri vs OrbStack

OrbStack and Kiri set out to do the same job on a Mac: run Docker containers in a light Linux VM, fast, with the Mac close at hand. Both speak the Docker Engine API, so the docker CLI and Compose work with either. OrbStack is the more complete product today. Kiri is pre-release, and is smaller and quicker at the core.

Side by side

Kiri OrbStack
Docker Engine API, docker CLI, Compose, buildx Yes Yes
amd64 images through Rosetta Yes Yes
Names like web.kiri.local / web.orb.local, with HTTPS Yes Yes
Container files in Finder Read-only, at ~/Kiri Yes, and you can edit them
SSH agent inside containers Yes Yes
Kubernetes Single-node k3s Yes
Linux machines Containers with your user and /Users Isolated machines, with cloud-init
Import from Docker Desktop kiri import desktop-linux Yes
Import from OrbStack kiri import orbstack n/a
Reach a container by its IP from the Mac No: ports, names and localhost Yes
USB devices, sound No Yes
A debug shell for minimal containers No Yes (Debug Shell)
Resource graphs Per container, in each container’s page Activity Monitor for the whole system
Platforms Mac (Apple Silicon), Linux, Windows (experimental) Mac
Licence Open source: Apache-2.0 or MIT Proprietary

Speed

Measured on one Apple Silicon Mac: create a container from alpine, run true, wait until it’s removed. Median of 30 runs, all engines driven by the same docker CLI in one run, with the default bridge network.

docker run --rm alpine true, p50 of 30, bridge network. With --network none: Kiri 2.68 ms and 14.0 ms, OrbStack 310 ms and 317 ms.

These favour Kiri more than a quiet Mac would: during the run OrbStack had 86 containers and a Kubernetes cluster running, which widens its spread. Most of Kiri’s CLI figure is the docker CLI starting up. All the figures and caveats are on Benchmarks.

Memory

OrbStack runs Docker’s engine in its VM, with a shim process for each running container. Kiri has one small daemon on the Mac and one agent in the VM that supervises every container itself.

Resident memory measured on the same Mac. OrbStack: dockerd plus containerd, and 143 shims holding 1133 MB. Kiri: the daemon (9.0 MB) plus the agent in the VM (0.69 MB), and no shim at all.

Kiri’s VM also gives memory back through a balloon while it runs, and powers off after 60 s with no containers running, so an idle Kiri holds no VM memory at all. See Memory and sleep.

What OrbStack has that Kiri doesn’t

Choose OrbStack if you rely on any of these:

  • USB passthrough and sound for containers and machines.
  • Debug Shell, to get tools into minimal containers that have no shell.
  • Isolated Linux machines with cloud-init. Kiri’s kiri machine is a long-lived container sharing your user and /Users, not a separate VM.
  • Editable files from Finder. Kiri’s ~/Kiri is read-only.
  • Direct IP access to containers from the Mac. With Kiri you reach them through published ports or names.
  • Activity Monitor graphs across the whole system.
  • A finished product. Kiri is pre-release.

What Kiri adds

  • Speed at the core: about 2.5 ms to start and remove a container through the API, and a 112 ms cold boot for its VM.
  • Sleep when idle: the VM powers off and comes back on the next request in about 0.15 s.
  • The same engine on Linux and Windows. On Linux there’s no VM at all, and on Windows it runs in WSL2. See Kiri on Linux and Kiri on Windows.
  • Open source, dual-licensed under Apache-2.0 or MIT.

Trying both

Kiri uses its own socket, ~/.kiri/run/docker.sock, next to OrbStack’s ~/.orbstack/run/docker.sock, and its own kiri Docker context. Both can run at once. kiri import orbstack copies images, volumes and containers over, reading from OrbStack only; containers arrive stopped.

kiri import orbstack --list   # see what would come over
docker context use kiri

© 2026 Kiri · runkiri.com