Rust project b0nker builds a minimal container runtime from Linux primitives

b0nker is the kind of Rust project that teaches containers by taking away most of the familiar tooling. Sreehari’s lightweight runtime skips a daemon, skips an image format, and skips the OCI runtime layer, then assembles isolation from Linux primitives you can actually name: namespaces, cgroups v2, overlay mounts, and pivot_root. The result is less about competing with Docker than about making the substrate visible again.

From OCI plumbing back to the kernel

That choice matters because the modern container stack is built to hide complexity. The Open Container Initiative, established in June 2015 by Docker and other industry leaders, created a Runtime Specification to standardize the configuration, execution environment, and lifecycle of containers, including the filesystem bundle and its config.json. containerd lives squarely in that world, with OCI Runtime Spec support and broader container runtime and lifecycle management.

b0nker deliberately stops well short of that full stack. Instead of presenting containers as a product surface, it treats them as a sequence of kernel operations, which makes it useful as a learning tool for anyone who wants to understand what Docker-like systems are doing below the abstraction layer.

How b0nker builds a container

The runtime’s control flow is easy to follow because each step maps to a concrete Linux primitive. It first creates namespaces, which the Linux kernel uses to isolate process views. It then applies cgroup v2 limits, using the single-hierarchy model that Linux documents for resource control, including memory and process counts. After that, it builds an isolated root filesystem with overlay mounts and pivot_root, then runs the requested command inside the new environment.

A compact way to think about the sequence is this:

The payoff shows up immediately when you inspect the process tree from inside the container. Running `ps` inside b0nker shows the process as PID 1, and it does not reveal the host process tree or host filesystem. That is the kind of concrete behavior that turns an abstract container lesson into something you can verify with your own eyes.

Why Rust fits this job

Rust is a particularly good fit for this kind of exercise because the runtime is almost entirely a choreography of system calls. That is where Rust’s memory safety and explicit control complement each other: you still deal with clone, unshare, mount, pivot_root, cgroups, and overlayfs directly, but you are not forced to manage every edge of the plumbing with the same footguns as a C prototype.

That is also why b0nker sits in an interesting part of the Rust infrastructure landscape. youki describes itself as a Rust container runtime and an implementation of the OCI runtime-spec, which places it on the production-facing end of the spectrum. b0nker is different in purpose, not in subject matter. Where youki wraps the OCI model, b0nker exposes the mechanics underneath it, making the same kernel-facing territory easier to study step by step.

For systems programmers, that is the real attraction. Rust is not just the implementation language here, it is part of the teaching strategy, because the code stays close to the kernel without turning the lesson into a pile of unsafe scaffolding.

The details that make it feel like a teaching artifact

Sreehari’s write-up adds a few touches that give b0nker a deliberately crafted feel. It can spin up multiple containers simultaneously and exits each container gracefully once done, which makes the runtime feel more like a small laboratory than a one-off demo. The naming also carries a little personality: the container struct is called Bonker, and the containers themselves are referred to as 0ysters.

Those details matter because they make the project memorable without obscuring the mechanism. The runtime still reads like a hands-on container lesson, but it has enough character to feel intentionally designed for exploration rather than just assembled to prove a point.

What the benchmark says, and what it suggests

The repository benchmark gives b0nker one more useful angle: it reports roughly 37 milliseconds mean runtime over 100 runs of `b0nker run true`. That figure fits the rest of the project’s shape. When the path from host to container is stripped down to kernel primitives, the result is both educational and fast enough to remind you how little ceremony is actually required for a trivial workload.

That does not make b0nker a replacement for containerd or other OCI-oriented runtimes. It makes it a clearer window into the machinery those tools wrap. The benchmark reinforces the same lesson as the code path itself: once you remove the extra layers, the container is no longer a mysterious platform feature, just a small, careful sequence of isolation steps.

b0nker ends up doing something a lot of hobby projects aspire to do and rarely achieve. It turns a dense systems topic into a buildable, inspectable object, then lets Rust keep the sharp edges visible without letting them cut the lesson apart. After one pass through namespaces, cgroups, overlayfs, and pivot_root, containers stop looking like magic and start looking like Linux doing exactly what it was designed to do.