I Replaced runc with a Rust Container Runtime (youki) for a Week

The Boring Layer That Matters Most

Every container you've ever run — docker run hello-world included — went through a tiny binary called runc before it became a process. It creates the namespaces, sets up the cgroups, drops privileges, and hands off to your entrypoint.

You never think about it. And that's the problem.

runc is written in Go + C (yes, C — for the nsenter and pivot_root bits that Go can't handle cleanly). It's been the reference implementation since 2014. It's also the layer where CVE-2024-21626 (a container escape) lived.

What if that layer was memory-safe by construction?

Enter youki — a container runtime written entirely in Rust, now a CNCF Sandbox project.

What Is youki?

youki (Japanese for "container") is an OCI runtime-spec implementation in Rust. It's a drop-in replacement for runc: same CLI, same spec, same integration path through containerd, Podman, or Docker.

The key differentiator vs. runc: no Go runtime startup, no C nsenter binary, no mixed-language memory safety boundary. The entire create → start → delete lifecycle lives in one Rust binary with compile-time safety guarantees.

The Benchmarks (Honest Version)

The headline number from youki's own repo:

Runtime Time (mean ± σ)        Range (min … max)    vs youki
youki   111.5 ms ± 11.6 ms     84.0 ms … 142.5 ms   100%
runc    224.6 ms ± 12.0 ms     190.5 ms … 255.4 ms  200%
crun     47.3 ms ±  2.8 ms     42.4 ms …  56.2 ms   42%

Youki is ~2× faster than runc for create → start → delete. But crun is ~2.5× faster than youki.

Here's the honest context:

The real win isn't raw speed — it's the Rust safety guarantee. You're not betting your node's security on a C memcpy in nsenter.

Setup: Replacing runc on a K8s Node

Prerequisites

• Kubernetes 1.28+ with containerd (not Docker Engine)
• Linux kernel 5.10+ (youki drops older kernel support to use modern features)
• cargo / just for building from source (or use a pre-built binary)

Step 1: Build youki

git clone https://github.com/youki-dev/youki.git
cd youki
just build
# Binary: ./target/release/youki

Or grab a release binary from GitHub Releases.

Step 2: Register with containerd

Edit /etc/containerd/config.toml (or use containerd config path):

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.youki]
  runtimeType = "io.containerd.youki.v1"

Then install the shim (youki ships a containerd-compatible shim):

sudo cp target/release/youki /usr/local/bin/
sudo cp target/release/containerd-shim-youki-v1 /usr/local/bin/

Restart containerd:

sudo systemctl restart containerd

Step 3: Create a RuntimeClass

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: youki
handler: youki
scheduling:
  nodeSelector:
    kubernetes.io/arch: amd64

kubectl apply -f runtimeclass-youki.yaml

Step 4: Run a Pod with youki

apiVersion: v1
kind: Pod
metadata:
  name: youki-test
spec:
  runtimeClassName: youki
  containers:
  - name: app
    image: nginx:alpine
    resources:
      requests:
        memory: "32Mi"
        cpu: "10m"

kubectl apply -f youki-pod.yaml
kubectl get pod youki-test -o wide
# youki-test   1/1   Running   0   2s

Verify it's actually using youki:

kubectl exec youki-test -- cat /proc/1/cgroup
# Confirms cgroup v2 hierarchy managed by youki

Step 5: Run It for a Week (What I Noticed)

I ran a 3-node k3s cluster with a mix of workloads:

• 20 long-lived API pods (Go, ~50 MB each)
• A CI pipeline spawning 50–200 short-lived pods/day
• A cron job that scales a batch processor 0 → 10 → 0 every hour

What went well:

1. Zero crashes, zero OOMs in the runtime itself. The Rust error handling is visible in logs — when something goes wrong, you get a structured Error with context, not a segfault.
2. Short-lived pods were noticeably snappier. My CI pods (build → test → delete) came up ~30–50ms faster than runc. Not dramatic per-pod, but across 200 pods/day it added up.
3. Rootless mode was cleaner. youki create with --rootless worked without the newuidmap/subuid gymnastics that runc sometimes needs.
4. Binary size. youki: ~8 MB. runc: ~12 MB. crun: ~3 MB. On an edge node with 512 MB RAM, every MB counts.

What was rough:

1. cgroups v1 support is there but v2 is the path of least resistance. If your distro still defaults to v1 (looking at you, CentOS 7), you'll hit edge cases.
2. No --checkpoint/--restore (CRIU) yet. If you rely on live migration or pause/resume, you're stuck on runc.
3. Docs are thin. The user docs cover the basics but there's no "migrating a production cluster from runc to youki" guide. You're on your own.
4. One C dependency remains. libseccomp-rs is an FFI wrapper around the C libseccomp. The team is working on a pure-Rust replacement, but it's not done.

youki vs. runc vs. crun: Where Each Wins

The honest takeaway: If you need maximum raw speed today, crun wins. If you need the safest runtime with a path to Wasm workloads, youki is the pick. runc remains the "it just works" default.

The Wasm Angle (Why This Matters More Than You Think)

Here's the part that excites me: youki is the low-level runtime that powers runwasi (the containerd shim for Wasm workloads) and, by extension, SpinKube.

The architecture:

containerd
  └── containerd-shim-runwasi (Rust)
        └── youki libcontainer (Rust) ← shared library
              └── Wasmtime / Wasmer / WasmEdge

Youki's libcontainer crate is used as a library by other Rust container tools. That means the same memory-safe, OCI-compliant primitives that run your nginx:alpine pod also run your Wasm modules. One codebase, two workload types, same security guarantees.

This is the "Rust container stack" taking shape:

Youki is the foundation. If it's not solid, nothing above it is.

What's Missing (and Where Funding Helps)

youki is in CNCF Sandbox — the earliest maturity level. The project is healthy (active commits, 80+ contributors, backing from Microsoft/Docker/Red Hat) but under-resourced for what it needs to do:

• Pure-Rust seccomp (eliminate the last C dependency) — significant engineering effort
• SELinux in Rust — needed for RHEL/CentOS production adoption
• CRIU support — checkpoint/restore is table-stakes for production
• OCI conformance test suite — a dedicated, automated compliance harness
• Docs and migration guides — "how do I move a 500-node cluster from runc to youki?"
• Security audit — a formal audit would be a major trust signal for enterprise adoption
• Conference presence — KubeCon, RustConf, containersc — the project needs more visibility

No LFX Crowdfunding campaign is active yet. If you use or evaluate youki, the highest-impact things you can do:

1. Contribute — even docs, test cases, or bug reports. GitHub
2. Run it in production and report what breaks (or doesn't)
3. Write about it — this article is a start, but we need more "I ran youki in a real cluster" content
4. Watch for an LFX Crowdfunding launch — CNCF funding page

TL;DR

Final Thought

The container runtime is the most underappreciated layer in the stack. It's the thing that's always running, that touches every syscall, that sits between your workload and the kernel. For a decade, that layer was a Go binary with a C sidecar.

Now there's a Rust option with CNCF governance, major-company backing, and a clear path to being the foundation for the next generation of container workloads (including Wasm).

I ran it for a week. It didn't break. It was faster. And the Rust error messages in the logs were genuinely pleasant to read.

That's about as good as "boring infrastructure" gets.

Have you tried youki in production? What broke? What didn't? Drop your experience in the comments — I'm especially curious about anyone running it alongside runwasi or SpinKube.

If you want to support the project, the best things right now are **contributing code/docs* and writing about your experience. The CNCF funding infrastructure is ready when the project is.*