Kiri – The Modern Container Runtime: Comments

Kiri has released version 0.2.1 of its container runtime for macOS, Windows, and Linux, introducing a single-daemon system to run Docker workloads. According to runkiri.com's report, the free beta maintains compatibility with existing docker CLI commands, Compose files, and the Docker Engine API. In benchmark tests on an Apple silicon Mac using two CPUs and eight gigabytes of memory, docker run completed in 22 milliseconds on Kiri compared to 178 milliseconds on Docker Desktop.

This report examines Kiri's kernel-level virtualization model, startup benchmarks, memory management, local networking configuration, and remote container sharing features. The release is designed for developers, DevOps teams, and software engineers seeking lower workstation resource consumption without changing existing project configurations. By eliminating per-container helper processes and automating virtual machine sleep cycles, Kiri accelerates everyday development while preserving standard workflows.

01Container execution speeds and benchmark comparisons

Benchmark tests recorded on Apple silicon hardware demonstrate measurable speed advantages over existing container engines. Executing docker run took 22 milliseconds on Kiri, compared to 152 milliseconds on Colima, 178 milliseconds on Docker Desktop, and 279 milliseconds on OrbStack under matching allocations of two CPUs and eight gigabytes of memory. Most of Kiri's 22-millisecond startup duration is consumed by the docker command-line client itself rather than the runtime daemon.

Direct communication through the Docker API reduces operational latency even further. When issuing commands directly to the socket, an entire container lifecycle completes in 3.1 milliseconds. This execution speed occurs because a single unified guest daemon creates namespaces, control groups, and overlay mounts without delegating work across secondary translation layers.

Competing developer environments introduce multi-step process pipelines that penalize throughput during iterative tasks. Docker Desktop and OrbStack both route container execution through five hops while running an independent shim process for every active container. Kiri eliminates per-container shim processes entirely, leaving nothing resident after container execution ends while using Docker's standard bridge network.

02Custom Linux kernel and vsock architecture

On macOS hosts, Kiri builds its virtualization layer directly on Apple's native Virtualization framework. A host-side process manages the Docker API socket while holding 409 kilobytes of memory. Standard docker commands and the dedicated kiri CLI connect directly to this endpoint, with future plans to route traffic from Stormglass through the same host interface.

Host processes communicate with the guest virtual machine through a direct vsock channel instead of chained Unix domain sockets. This design delivers a median p50 round-trip latency of 31 microseconds. The guest machine runs a custom minimal Linux kernel managed by kiri-init, a 360-kilobyte binary operating as process identifier one.

Container creation inside the guest kernel relies on the modern clone3 system call invoked directly by the kiri daemon. By avoiding nested hypervisor layers, the virtual machine achieves cold boot to ready status in 112 milliseconds. Under identical testing conditions, a stock Linux distribution kernel required 810 milliseconds to reach an operational state.

03Memory footprint and automatic resource reclamation

Accumulated memory overhead from background processes often constrains developer machines during extended working sessions. On an Apple silicon test machine running 143 containers under OrbStack, background shim processes held 1.13 gigabytes of resident memory. Because Kiri operates without auxiliary per-container shims, physical memory usage tracks only the demands of running user code.

The runtime also reclaims memory actively while containers execute, returning unreferenced memory pages directly to the host operating system. When container activity ceases for sixty seconds, the underlying virtual machine automatically enters an idle sleep state. In this suspended state, the resident background daemon maintains a memory footprint of approximately 15 megabytes.

Resuming the virtual machine from sleep takes 0.15 seconds, preventing latency spikes during interactive terminal work. Engineers transitioning from Docker Desktop or OrbStack can import existing container images, volumes, and running workloads directly within Kiri's desktop window. Following migration, Kiri configures the docker CLI context so development environments continue running without configuration rewrites.

04Native interface and cross platform support

Rather than relying on browser-based Electron frameworks, Kiri provides native application binaries across supported desktop platforms. The macOS client is built with AppKit and WebKit for macOS 14 and newer systems, residing directly in the menu bar. On Windows, the client combines Win32 libraries and WebView2, avoiding the memory consumption associated with bundled Chromium browsers.

Execution models adjust according to the underlying host architecture. On Windows, Kiri executes inside Windows Subsystem for Linux 2, exposing the Docker API via a local named pipe. On Linux installations, Kiri operates natively without a virtual machine, invoking the clone3 system call directly on the host kernel.

Kiri's management window supports fifteen localized languages, including English, Japanese, Korean, German, French, Spanish, Italian, Russian, Turkish, Polish, Indonesian, Vietnamese, and Chinese variants. The interface includes tools for monitoring BuildKit builds, searching Docker Hub, inspecting container files, and running vulnerability scans. On Apple silicon hardware, amd64 container images run through Rosetta emulation.

05Public tunnel sharing and local networking

Local networking inside Kiri provides predictable domain resolution without requiring manual port bindings. Containers become accessible at local addresses like web.kiri.local, while Compose services resolve using names like api.myapp.kiri.local. An integrated narrow certificate authority generates local HTTPS certificates, allowing developers to test secure connections without configuring external reverse proxies.

Remote sharing is built into the runtime through Kiri Share, which publishes local containers over public HTTPS at runkiri.cloud. Triggered via the desktop window or by running kiri share web, the feature creates shareable links and supports reserved addresses like myapp.runkiri.cloud. To prevent phishing and fraudulent impersonation, first-time visitors see an explicit warning banner before accessing the container.

Environment provisioning extends beyond standalone container instances. Running kiri k8s start deploys a functional k3s Kubernetes cluster in approximately 20 seconds, with management support for kind clusters inside the application. For general Linux tasks, kiri machine create dev --distro ubuntu spins up an Ubuntu virtual machine with user privileges and synchronized Mac filesystem paths.