COMPARE

Kiri vs Docker Desktop

Docker Desktop and Kiri both run Linux containers on your Mac in a VM, and both serve the Docker Engine API. So the docker CLI, Compose and buildx work with either. The differences are in what sits behind that API, how fast and light it is, and what each one adds around it.

What stays the same

• The API and the tools. Kiri serves the Docker Engine API, and its app bundles the docker CLI, Compose and buildx. Your images, compose.yaml files and scripts don’t change.
• A Docker context. Kiri adds a kiri context on first open and doesn’t touch /var/run/docker.sock or /usr/local/bin/docker, so both can be installed side by side. Switch with docker context use.
• The everyday features: published ports on localhost, bind mounts of Mac folders, named volumes, user networks with DNS by name, host.docker.internal, SSH agent forwarding, amd64 images through Rosetta, docker build through BuildKit, and a single-node Kubernetes cluster.
• Moving over. kiri import desktop-linux copies images, volumes and containers from Docker Desktop. It only reads from Docker Desktop. See Moving from Docker Desktop.

What’s behind the API

Docker Desktop runs Docker’s own engine in its VM: dockerd, containerd, a containerd-shim per container and runc. Kiri replaces all of them with one daemon on the Mac and one agent in the VM, which starts each container with a single clone3.

The details are in How it works.

Speed

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

Most of Kiri’s CLI figure is the docker CLI itself starting up. On Windows, from PowerShell, Kiri measured 78 ms and Docker Desktop 491 ms for the same command. The method, the p99s and the caveats (Docker Desktop’s VM shared the Mac with a loaded OrbStack during the run) are on Benchmarks.

What Kiri does differently

• It gives memory back and sleeps. A balloon keeps Kiri’s VM near what containers use, and the VM powers off after 60 s with nothing running, waking in about 0.15 s. The daemon on the Mac stays at about 15 MB, and there’s no process per container. See Memory and sleep.
• Containers have names. http://web.kiri.local reaches a container called web once you turn names on (web.kiri.localhost works with no setup), Compose services answer at <service>.<project>.kiri.local, and HTTPS works with Kiri’s own certificate authority. See Domain names.
• Container files are in Finder at ~/Kiri, read-only and always current. See Container files in Finder.
• Linux machines. kiri machine create dev gives you a long-lived Linux environment with your user and /Users at the same path. See Linux machines.
• It’s small and open source. The kiri host binary is about 2 MB. Kiri is dual-licensed under Apache-2.0 or MIT, at your option.

What Docker Desktop has that Kiri doesn’t

Kiri is pre-release, and Docker Desktop is a mature product. Choose Docker Desktop if you need:

• Intel Macs. Kiri runs on Apple Silicon only (macOS 14 or later).
• Windows containers. Kiri on Windows is experimental and runs Linux containers in WSL2.
• Docker’s own engine. Kiri implements the Engine API itself. Features of dockerd that Kiri doesn’t implement answer with an error saying so.
• Docker’s wider product: Extensions, Docker’s other tools built into its app, and the administration features organisations use to manage many installs.
• A vendor behind it. Docker Desktop comes from Docker, Inc. under its own terms, which require a paid subscription for larger companies. Check Docker’s current terms for your case.

Trying both

Because each one has its own Docker context, you can keep Docker Desktop and try Kiri next to it.

docker context use kiri            # Kiri
docker context use desktop-linux   # back to Docker Desktop

© 2026 Kiri · runkiri.com