Open source · written in Rust · 0.1.0 for Apple silicon

The container runtime
that does less.

Kiri runs your containers with one minimal VM, one daemon and a single clone3. No dockerd, no containerd, no shims, no runc. It speaks the Docker CLI and API you already use.

1.14 ms Measured

p50 of 30 runs to create an alpine container, run true, exit and remove it, through the Docker Engine API with Docker's default bridge networking. Same test, same API: Docker Desktop 119.1 ms, OrbStack 270.3 ms. Through the same docker CLI: Kiri 13.4 ms, Docker Desktop 115.8 ms, OrbStack 281.7 ms.

Measured Cold VM to agent ready in 112 ms, down from 810 ms.

Download for Mac Watch the race

$ kiri run --rm alpine echo "ntakịrị" prints ntakịrị. $ kiri run -d --name web nginx prints a container ID. $ kiri ps lists the running web container. $ curl http://web.kiri.localhost reaches it by name, with no port to remember. $ docker ps shows the same container, because Kiri answers the Docker API.

Illustrative session. With Kiri open, the ordinary docker command runs on Kiri.

Why it's fast

Same command, three routes.

A container start on Docker Desktop or OrbStack crosses a chain of programs, each with its own socket and process. Kiri's crosses one Rust daemon that calls the kernel directly. All three are driven by the same docker CLI. Watch it slowed down to see each stop, or in real time to feel the gap.

docker run --rm --network none alpine true
OrbStackMeasured0 ms

Five hops. One shim process stays resident for every running container.

Docker DesktopMeasured0 ms

The same five hops, and a shim per running container.

KiriMeasured0 ms

One daemon creates namespaces, cgroups and mounts itself. Nothing per container is left running. Most of this time is the docker CLI starting up; Kiri's engine part is about 1.3 ms.

p50 of 30 runs on one Apple Silicon Mac, all three through the same docker CLI with --network none, since Kiri has no container networking yet. Stops are drawn evenly; only the totals are figures. Details and caveats are in the benchmarks below.

Measured

What already runs, measured.

The VM, the channel between your Mac and the VM, and the binaries already run. These numbers come from one Apple Silicon Mac.

Cold boot to agent ready Measured

112ms

  1. Stock kernel810
  2. allnoconfig175
  3. Expedited RCU140
  4. virtio reset patch112

Mac to VM round trip Measured

31µs

p50 over vsock. p99 is 62 µs.

Inside the VM Measured

360KB

Rust PID 1. The kernel reaches it in 8 ms.

Memory for running containers

OrbStack, like Docker Desktop, keeps a shim per container. On OrbStack: 143 × 7.9 MB = 1.13 GB Measured

Kiri keeps none, with one daemon on a 10 MB budget: 0 MB Target

Benchmarks

Numbers, with their labels on.

The container lifecycle is measured on all three engines, on one machine, with the fairness notes beside it. Kiri's other container operations are still targets: design budgets we hold ourselves to, not results. Every figure says which it is.

Kiri, measured Kiri, target (not yet measured) Docker Desktop, measured OrbStack, measured
Loading bench/results.json…

Container lifecycle, three engines

alpine → true → exit → removed. p50 of 30 runs, p99 alongside. Milliseconds on a log scale, lower is better.

    Other container operations

    OrbStack measured against Kiri targets. Milliseconds, lower is better, one linear scale. Docker Desktop has not been measured for these yet.

    Engine memory

    Megabytes resident, lower is better. Docker Desktop has not been measured for these yet.

    Where container-start time goes

    The kernel work underneath a container start, measured inside a Linux 7.2 VM.

    Kernel primitive timings in milliseconds
    OperationTimeRelative time

    Method and machine

    Machine
    Apple Silicon Mac
    OrbStack
    OrbStack with the Docker CLI
    Last updated
    2026
    Status key
    measured = measured on this machine; target = design budget

    Both runtimes are timed on the same machine. Kiri's lifecycle and memory targets will be replaced with measurements, on that machine, once the daemon runs containers end to end. Until then the chart draws them hatched and labels them "target".

    This page renders straight from bench/results.json. Change the file and the page changes with it.

    All figures as a table
    Every benchmark figure
    RuntimeMetricValueStatus

    Architecture

    One small VM. One daemon. A socket between them.

    On macOS, Kiri boots a single Linux VM through Apple's Virtualization.framework, with a custom kernel and a 360 KB Rust init as PID 1. The host and guest talk over vsock. Inside, the Kiri daemon creates each container with clone3.

    Kiri architecture on macOS On the Mac host, the kiri CLI, the Docker CLI and later stormglass talk to the kiri host process, which runs the VM through Virtualization.framework. A vsock channel connects it to the Linux guest, where kiri-init is PID 1 and the kiri daemon creates containers with clone3. macOS host stormglass later docker / kiri CLI kiri hostDocker API socket · 409 KB Virtualization.framework One VM for every container. No per-container process on the host. vsock 31 µs round trip, p50 Linux VM custom minimal kernel kiri-init · PID 1 · 360 KB kiri daemon clone3 containers: namespaces + cgroup + overlay Kiri architecture on macOS: host, vsock, Linux VM with kiri-init, kiri daemon and containers macOS host stormglass later docker / kiri CLI kiri hostDocker API socket · 409 KB Virtualization.framework vsock 31 µs p50 Linux VM custom minimal kernel kiri-init · PID 1 · 360 KB kiri daemon clone3 → containers

    Boot once

    One VM for every container. From cold to agent ready takes 112 ms Measured, and the kernel reaches PID 1 in 8 ms.

    Talk directly

    Requests cross vsock to the guest, not a chain of Unix sockets. The p99 round trip is 62 µs Measured.

    Leave nothing behind

    No per-container process. A clean guest shutdown takes 2.2 ms Measured.

    The app

    A Mac app, not a web wrapper.

    Kiri's window is drawn with AppKit and the system WebKit. No Electron, no bundled browser. It manages containers, images, volumes and networks, groups Compose projects, and gives each container a page with live stats, logs, a terminal and its files. Running apps open by name, at myapp.kiri.local, over HTTPS if you like. It moves your images, volumes and containers over from OrbStack or Docker Desktop, and it lives in the menu bar.

    • macOSOne minimal Linux VM through Virtualization.framework
    • LinuxNative, no VM at all: the daemon calls clone3 on your kernel
    • WindowsInside WSL2, on the Linux kernel Windows already ships (experimental)

    Containers

    No containers yet

    Containers you start with docker run or Compose show up here, with the kiri context.

    Planned for stormglass

    Later: the Docker runtime inside stormglass.

    stormglass is a desktop client for Kubernetes. The plan is for Kiri to ship inside it later as the built-in Docker runtime, so stormglass users get containers on their Mac without installing OrbStack or Docker Desktop. One app, one small VM, nothing else to keep updated.

    ntakịrị

    The name

    Kiri means "a little".

    In Igbo, ntakịrị means "small" or "a little". We took the end of the word as our name because it is the whole idea: a little code, a little memory, a little time. We hope we do the word justice.

    Install

    Kiri 0.1.0 for Mac.

    For Apple silicon Macs on macOS 14 or later. Open the disk image, drag Kiri to Applications and open it. Kiri sets up a kiri docker context and brings its own docker, Compose and buildx, so nothing else needs installing.

    Download Kiri 0.1.0

    $ kiri run --rm hello-world
    Signed and notarized by Apple · 45 MB