Rust-based Container Runtime Kiri: 18ms Startup, a Docker Challenger?

On Hacker News' Show HN section, an open-source project called Kiri has drawn attention. It bills itself as a container runtime written in Rust and claims that executing docker run takes only 18 milliseconds. If this number holds true, it would be significantly faster than the startup time of traditional Docker containers.

Why Does Container Startup Speed Matter So Much?

One of the core advantages of container technology is rapid deployment and elastic scaling. In microservices architectures, serverless computing, and CI/CD pipelines, container startup speed directly affects resource utilization and user experience. Faster startup means shorter cold-start times, higher deployment density, and more agile failure recovery.

Although traditional Docker containers are lighter than virtual machines, their startup process involves the daemon, image layer mounting, network configuration, and other steps, typically taking hundreds of milliseconds or even seconds. Kiri's claimed 18 milliseconds, if reproducible in real-world scenarios, would be an order-of-magnitude improvement.

What Makes Up Container Startup Time

Container startup time is not the duration of a single step but the accumulation of multiple steps: from client command parsing, communication with the container daemon, image layer decompression and mounting (or preparing the union filesystem), creating namespaces and cgroups, configuring network interfaces and routing rules, to finally launching the user process. In the traditional Docker architecture, the dockerd daemon and containerd add overhead for inter-process communication and state management; and while the image layering mechanism saves storage, the first startup requires mounting layer by layer, and if the cache is missed, pulling from the image registry is often the main source of hundreds of milliseconds or even seconds of delay. A so-called "18 milliseconds" usually means most of these steps have been bypassed or pre-warmed—for example, using an in-memory root filesystem directly, skipping network plugin initialization, or reusing already-created namespaces. Understanding these steps helps determine under what boundary conditions a given startup time figure was obtained.

What Is Kiri?

According to the project description, Kiri is an open-source container runtime written entirely in Rust. The Rust language is known for its memory safety and high performance, and has risen rapidly in the systems programming field in recent years. Kiri aims to provide a Docker-compatible experience (starting directly from the docker run command) but dramatically reduce startup overhead by streamlining its architecture and leveraging Rust's low-level control capabilities.

Currently, public information about Kiri is still very limited. The Hacker News post has only 4 points and 0 comments, suggesting it may have just been released and has not yet been widely tested by the community. Therefore, we should maintain a cautious attitude toward the "18 milliseconds" figure.

Rust's Suitability for Systems Programming

The key reason Rust is used for low-level system software like container runtimes is that its ownership model eliminates memory safety issues such as data races and dangling pointers at compile time, without introducing garbage-collector pauses. Container runtimes need to make frequent system calls (such as clone, unshare, mount), manage file descriptors, and handle lifecycle events concurrently—scenarios that are latency-sensitive and error-prone. Rust's zero-cost abstractions allow developers to write code with performance close to C, while the standard library and community crates provide relatively safe wrappers around system calls. However, Rust cannot automatically solve the architectural overhead of a container runtime—it optimizes the execution efficiency and reliability of the runtime's own code, not the time consumed by external steps such as image distribution, storage drivers, or network configuration. Therefore, language choice is one necessary condition for performance, but far from a sufficient one.

Technical Highlights and Potential Advantages

Despite the lack of detail, several technical directions for Kiri can be inferred from the available information:

• Minimalist architecture: It may remove unnecessary components found in traditional container runtimes and directly invoke Linux kernel features (such as namespaces and cgroups) to isolate processes.
• Rust's performance and safety: Rust's zero-cost abstractions and lack of garbage collection make the runtime's own overhead extremely low while avoiding common memory safety vulnerabilities.
• Docker command compatibility: This lowers the migration cost for users, allowing developers to continue using the familiar docker run syntax.

If Kiri can deliver on its performance promises, it will be attractive in scenarios requiring fast startup, such as function computing platforms, edge computing nodes, and developers' local environments.

Doubts and Points to Be Verified

A Show HN post with only 4 points means Kiri has not yet received sufficient community scrutiny. The 18-millisecond startup time may be a best-case result under specific conditions, such as:

• The image is already pre-warmed in memory
• The container configuration is extremely minimal (no network, no volume mounts)
• The host hardware has extremely high performance

Container startup in real production environments often involves complex factors such as image pulling, storage drivers, and network plugins, all of which add time. Therefore, Kiri's actual performance requires more independent testing to verify.

In addition, key questions about Kiri's maturity, ecosystem compatibility (such as integration with Kubernetes), and strength of security isolation remain unanswered.

Isolation and Compatibility Benchmarks for Container Runtimes

Evaluating a container runtime cannot rely on startup speed alone; its isolation strength and ecosystem compatibility must also be examined. In terms of isolation, traditional containers rely on Linux namespaces for view isolation, cgroups for resource limits, and often work with mechanisms like seccomp and AppArmor/SELinux to tighten the system call surface. A runtime pursuing minimalism and low latency that reduces these security layers under default configurations may trade isolation strength for speed. In terms of compatibility, the OCI (Open Container Initiative) specification defines image formats and runtime interfaces, while Kubernetes interacts with runtimes through the CRI (Container Runtime Interface). If Kiri is only compatible with the docker run command line and has not yet implemented the OCI runtime specification or the CRI interface, its usability in orchestration systems will be very limited. Independent evaluation of these dimensions is just as important as startup time data.

Conclusion

Kiri brings new ideas to the container runtime field: rewriting the low-level layer in Rust and pursuing extreme startup speed. Although information is currently limited, its emergence reflects the community's ongoing exploration of lighter and more efficient container technology. For developers interested in cloud-native and systems programming, Kiri is worth keeping an eye on.

In the absence of independent benchmarks and community feedback, we should treat it as an interesting technical experiment rather than a mature Docker replacement.