Kiri's numbers, live
Move the sliders and press the buttons. The Mac numbers were measured on an Apple Silicon Mac, macOS 27.0.1, last run 2026-10-24; the Windows table is at the end.
How many containers fit?
Each engine spends memory of its own before your containers use any. Kiri runs one small daemon and no per-container process. OrbStack runs dockerd and containerd, plus a shim process for every container.
What's counted
- Kiri: the daemon and guest agent (9.7 MB) plus Apple's VM helper process (69 MB). No per-container memory: there is no shim.
- OrbStack: dockerd + containerd (216 MB) plus 7.9 MB for each container's shim (143 shims used 1133 MB).
- Not counted for either: the Linux kernel inside the VM, page cache, and OrbStack's own VM helper, which we didn't measure. That leaves out memory on OrbStack's side, so the gap is if anything larger than shown.
- Docker Desktop's engine memory isn't in our results yet, so it isn't here.
Start a container
Create from alpine, run true, exit, remove. Median of 30 runs per engine, on the same Mac, in the same session. The race below plays at real speed.
Kiri reports a --rm container's exit once its record is removed, then deletes its files just after; with the delete inside the timing it was about 3 ms. Through the docker CLI, most of Kiri's ~14 ms is the CLI starting up. OrbStack had 86 containers and a Kubernetes cluster running during the run, which widens its spread.
From 810 ms to 112 ms
Kiri boots a Linux VM before your first container. These are the steps that made it fast: cold boot to agent ready, median of 5.
- stock arm64 defconfig kernel810 ms
- allnoconfig + only what the VM has175 ms
- expedited RCU (cgroup2 mount 23 ms -> 0.1 ms)140 ms
- virtio-pci reset poll patch112 ms
Of the 112 ms, 95 ms is Apple's Virtualization.framework starting its helper. The kernel reaches PID 1 in 8 ms, and the agent is ready 0.4 ms after that.
On Windows
The same kind of run against the engines people use on Windows. Best in each column is highlighted.
| Engine | runlower is better | execlower is better | 200 MB outhigher is better | 200 MB inhigher is better | bind writehigher is better | bind readhigher is better | published porthigher is better | buildlower is better | pulllower is better |
|---|---|---|---|---|---|---|---|---|---|
| Kiri (main) | 188 ms | 187 ms | 209 MB/s | not yet | 1467 MB/s | 3851 MB/s | 10.3 Gbit/s | 1113 ms | 2862 ms |
| Docker Engine 29.9.2 | 697 ms | 224 ms | 56 MB/s | 129 MB/s | 819 MB/s | 1307 MB/s | 100.7 Gbit/s | 1723 ms | 2239 ms |
| Podman 4.9.3 | 1105 ms | 274 ms | 70 MB/s | 121 MB/s | 593 MB/s | 907 MB/s | 51.9 Gbit/s | 1148 ms | 4921 ms |
| nerdctl 2.4.1 | 631 ms | 57 ms | 72 MB/s | 131 MB/s | 845 MB/s | 1485 MB/s | 52.4 Gbit/s | 1211 ms | 1796 ms |
| Colima 0.10.3 | 635 ms | 226 ms | 20 MB/s | 70 MB/s | 493 MB/s | 1496 MB/s | 0.8 Gbit/s | 2472 ms | 4418 ms |
| Docker Desktop 29.8.2 | 714 ms | 224 ms | 114 MB/s | 143 MB/s | 826 MB/s | 1283 MB/s | 87.8 Gbit/s | 2008 ms | 2114 ms |
Kiri's "200 MB in" result wasn't valid in this run, so it's left out rather than guessed. Docker Engine leads on published ports by a wide margin; that's where Kiri has the most work left.
Raw data: runkiri.com/bench. Status "measured" means measured on that machine; design targets are left off this page.