DEV Community

Cover image for I Replaced runc with a Rust Container Runtime (youki) for a Week
Bhargav Bhatt
Bhargav Bhatt

Posted on Fully Autonomous

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

#rust #containers #programming

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.

Fact Detail
Language Rust (pure, except a libseccomp-rs FFI shim being replaced)
CNCF status Sandbox (accepted Oct 17, 2024)
GitHub youki-dev/youki
Stars ~7,300
License Apache 2.0
Adopters Azure Kubernetes Service, Docker, containerd/runwasi
Contributing orgs Microsoft, Docker, Red Hat

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%
Enter fullscreen mode Exit fullscreen mode

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

Here's the honest context:

Scenario Does it matter?
Single long-lived container No. 100ms of startup is noise over a 7-day uptime.
Serverless: 10k containers/min Yes. A 100ms savings × 10k = 1,000 CPU-seconds per minute reclaimed.
K8s pod churn (CI/CD, spot nodes) Moderately. Image pull + CNI + scheduling dominate; runtime is ~5–10% of total.
Edge/embedded (tight RAM) Yes. youki's binary is smaller and RSS is lower per instance.

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
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

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/
Enter fullscreen mode Exit fullscreen mode

Restart containerd:

sudo systemctl restart containerd
Enter fullscreen mode Exit fullscreen mode

Step 3: Create a RuntimeClass 

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: youki
handler: youki
scheduling:
  nodeSelector:
    kubernetes.io/arch: amd64
Enter fullscreen mode Exit fullscreen mode 
kubectl apply -f runtimeclass-youki.yaml
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode 
kubectl apply -f youki-pod.yaml
kubectl get pod youki-test -o wide
# youki-test   1/1   Running   0   2s
Enter fullscreen mode Exit fullscreen mode

Verify it's actually using youki:

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

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

Dimension runc crun youki
Language Go + C C Rust
Memory safety ❌ (C portion) ❌ ✅ (99% — one FFI shim)
Create→delete (benchmark) 224 ms 47 ms 111 ms
Binary size ~12 MB ~3 MB ~8 MB
cgroups v2 ✅ ✅ ✅
Rootless ✅ ✅ ✅ (cleanest)
CRIU (checkpoint/restore) ✅ ✅ ❌ (roadmap)
Wasm support ❌ ❌ ✅ (first-class)
CNCF governance ❌ (OCI) ✅ (Sandbox) ✅ (Sandbox)
Production battle-testing 10+ years 5+ years ~3 years
Best for Default, compatibility Max performance, minimal footprint Safety + Wasm + future-proofing

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
Enter fullscreen mode Exit fullscreen mode

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:

Layer Rust project Role
Runtime youki OCI container lifecycle
Shim runwasi Wasm on containerd
Orchestrator SpinKube Wasm on Kubernetes
Image tooling naftiko Build OCI/Wasm images
Spec oci-spec (Rust crate) The spec itself, in Rust

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

Question Answer
Is youki production-ready? For new, non-critical workloads: yes. For a 500-node cluster: not yet.
Is it faster than runc? ~2× for create/delete. Yes, but crun is faster still.
Is it safer than runc? Yes — memory-safe Rust eliminates the C nsenter attack surface.
Should I switch today? If you're running Wasm workloads or want to be early on the Rust container stack: yes. Otherwise: watch this space.
What's the risk? It's a Sandbox project. The API could shift. CRIU is missing. Docs are thin.

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.*

Top comments (0)