Kiri 0.2.1 released as fast Docker Desktop alternative, claims 8× speed

What is Kiri and why it matters?

Kiri is a modern container runtime that aims to replace Docker Desktop on macOS, Windows and Linux. The project ships a native application that bundles its own Docker CLI, Compose, buildx and a lightweight Linux VM (or runs directly on the host kernel on Linux). According to the Kiri website, the runtime can start a container in as little as 22 ms, which the developers say is roughly eight times faster than Docker Desktop on the same hardware. For developers who spend minutes waiting for containers to spin up, that speed gain can translate into noticeably tighter feedback loops.

How does Kiri achieve the claimed speed boost?

Kiri’s architecture differs from the typical Docker Desktop stack. Traditional setups involve several processes – a Docker daemon, a shim per container and multiple socket hops – before the kernel finally creates the container. Kiri replaces that chain with a single daemon that talks to the host over a vsock channel (on macOS) or a named pipe (on Windows). Inside the VM the daemon invokes the Linux clone3 system call directly, eliminating the need for per‑container shim processes. The result is a single round‑trip latency of about 31 µs, and a measured end‑to‑end container lifecycle of 3.1 ms when invoked through the Docker API. The VM itself is tiny (about 15 MB) and sleeps after a minute of inactivity, further reducing resource overhead.

How does Kiri compare with Docker Desktop and other alternatives?

Benchmark data published on the Kiri site shows the following start‑up times for a simple docker run --rm alpine true command on an Apple‑silicon Mac limited to 2 CPU cores and 8 GB RAM:

• Kiri: 22 ms
• Docker Desktop: 178 ms
• Colima: 152 ms
• OrbStack: 279 ms

The same command measured on Windows follows a similar pattern, though exact numbers differ due to the underlying WSL2 layer. In addition to raw speed, Kiri consumes far less memory while idle because it does not keep a shim per container. For ten containers running simultaneously, Kiri’s daemon stays around 15 MB, whereas OrbStack’s shims occupied over 1 GB in the same test.

Which additional features does Kiri bring to the container workflow?

Beyond raw performance, Kiri bundles several capabilities that developers normally reach for separate tools:

• Docker‑compatible CLI: All standard docker, docker compose and docker buildx commands work unchanged because Kiri implements the Docker Engine API.
• BuildKit builds with vulnerability scanning: Image builds are visible in a dedicated “Builds” view and each resulting image is scanned for known CVEs.
• One‑click Kubernetes: Running kiri k8s start launches a lightweight k3s cluster in about 20 seconds, with pods and services displayed in the UI. The kind tool also works.
• Linux machines: kiri machine create dev --distro ubuntu provisions a full Ubuntu VM that mirrors the host’s file paths, useful for development environments.
• Public sharing: The “Share” button generates a HTTPS link (e.g., web.runkiri.cloud) that exposes a running container to the internet until manually disconnected. A warning page protects against phishing.
• Automatic resource reclamation: Unused memory is returned to the host and the VM sleeps after a minute of idle time.

How to install and try Kiri on your machine

Getting started takes four simple steps:

1. Install – Download the DMG (macOS) or installer for Windows/Linux, drag Kiri to the Applications folder, and launch it. The app automatically creates a Docker context named kiri.
2. Pull an image – Use the built‑in image browser or run docker pull nginx from a terminal.
3. Run a container – Click Run in the UI or execute docker run -p 80:80 nginx. The container should be up in milliseconds.
4. Share (optional) – Select a running container and press Share to obtain a public URL, or run kiri share 80 from the command line.

If you are already using Docker Desktop, OrbStack or another runtime, Kiri can import existing images, volumes and containers, then swap the Docker context to point at its daemon with a single click.

What this means for Grafy users

Grafy’s Code studio lets developers write, test and iterate on code inside a browser‑based environment. By configuring the workspace to point at a local Kiri Docker context, you can spin up containers for databases, message brokers or custom services in seconds, then connect your code to them without leaving the Grafy interface. The fast start‑up times reduce the latency of integration tests that rely on containerised dependencies. For creators who need a quick sandbox to render AI‑generated assets (e.g., using the Creator app) inside a container, Kiri’s lightweight VM and on‑demand sharing feature can expose those services to other Grafy apps without complex networking setups.

---

Frequently asked questions

How does Kiri’s container start time compare to Docker Desktop on the same hardware?

In the benchmark published by the Kiri team, a simple docker run command completed in 22 ms on Kiri versus 178 ms on Docker Desktop, representing roughly an eight‑fold speed improvement on an Apple‑silicon Mac limited to 2 CPU cores and 8 GB RAM.

Does Kiri require a separate virtual machine on Linux?

No. On Linux the Kiri daemon runs directly on the host kernel and creates containers with the native clone3 system call. The VM layer is only used on macOS (via Apple’s Virtualization.framework) and Windows (inside WSL2).

Can I use Kiri’s public sharing feature with Grafy apps?

Yes. The Share button generates a HTTPS URL that points to the running container. You can paste that URL into any Grafy app that accepts external endpoints – for example, feeding a container‑hosted API into a Code project or displaying a live video stream in Video Edit.

---

Source: Hacker News — front page — Kiri – The Modern Container Runtime