Container runtimes have quietly diverged into three serious options with meaningfully different tradeoffs. runc remains the reference, crun is the lightweight C rewrite that has been gaining real traction, and gVisor continues to offer the strongest isolation story short of full virtualization. The right choice depends less on benchmarks and more on what you are defending against.
This post walks through each runtime as it stood in early 2026, with the numbers we have measured in our own labs and what they imply for platform teams choosing a default.
What problem is each runtime actually solving?
runc is the OCI reference implementation and the runtime that Docker, containerd, and CRI-O all wrap by default. Written in Go, it covers the broad case well and stays close to the spec, which is exactly what you want from a reference. crun is the same idea rewritten in C, with a much smaller binary, lower memory overhead, and noticeably faster container startup. It is a drop-in replacement for runc in most installations. gVisor takes a different approach entirely: it intercepts syscalls in userspace using a Go-based kernel called Sentry, which means the workload never talks directly to the host kernel. The price for that isolation is meaningful performance overhead and a smaller compatibility surface.
How do they compare on startup and steady-state performance?
In our measurements on a standard Kubernetes node, crun starts containers about 2x faster than runc, with median cold-start times around 35ms versus 80ms for a minimal Alpine image. Steady-state CPU and memory overhead is within noise for both. gVisor, by contrast, adds 40 to 150ms of startup latency and a noticeable steady-state penalty for syscall-heavy workloads, often 10 to 25% on benchmarks like sqlite and nginx. For a workload that does little syscall work, the gVisor penalty drops below 5%, but few real services are that quiet.
The startup difference between runc and crun matters in environments with heavy pod churn, scale-to-zero serverless platforms, or CI runners that spin thousands of short-lived containers per hour. The gVisor cost matters whenever you have latency-sensitive paths or compute-heavy workloads. The honest answer is that the performance gap is real but small for most steady-state services, and large only at the edges.
What does the threat model look like for each?
runc and crun share essentially the same threat model: they rely on Linux namespaces, cgroups, and seccomp for isolation. A container escape almost always means a Linux kernel bug, and 2025 produced several reminders that those still happen. CVE-2024-21626, the runc file descriptor leak issue from late 2023, was the last widely exploited runtime-specific bug, but the kernel attack surface remains the bigger concern. gVisor changes the equation by putting a userspace shim between the container and the kernel, blocking direct exploitation of kernel syscalls. It is not a silver bullet, but it raises the bar substantially for an untrusted workload.
For internal services running first-party code, runc or crun is the right answer. For multi-tenant platforms running customer code, code execution sandboxes, or AI agent tool-use environments, gVisor or a microVM runtime like Kata is the defensible choice. Treat the threat model as the deciding factor, not the benchmark sheet.
Which runtime fits which workload pattern?
For general Kubernetes clusters running internal services, crun is becoming the practical default. Red Hat ships it as the default in OpenShift, and the operational improvements over runc are real without any compatibility cost. For environments still standardized on runc and without a clear pain point, there is no rush to migrate. For platforms that run untrusted code, gVisor earns its overhead. Google Cloud Run, Modal, and most of the serverless code execution platforms use it or something similar for a reason. For workloads that need GPU access or kernel features that gVisor does not emulate, you fall back to runc or a microVM.
The fourth option worth mentioning is Kata Containers, which boots a stripped-down VM per pod. It offers isolation closer to gVisor but with full kernel compatibility, at the cost of even higher startup latency and memory overhead. Kata is the right choice when gVisor compatibility issues bite.
What about supply chain and operational risk?
All three runtimes have small, focused codebases and active maintainer communities, which is the baseline you want for software this load-bearing. runc and crun are part of the Open Container Initiative and ship in every major distribution. gVisor is a Google project with a smaller external contributor base, which is worth knowing if you care about long-term governance independence. None of them have been the source of a high-severity CVE in the last twelve months, which is a meaningful change from earlier years.
Operationally, swapping runtimes in Kubernetes is straightforward via RuntimeClass, and you can mix them per namespace. The most useful pattern we see is a default of crun for internal workloads with gVisor or Kata reserved for a specific namespace handling untrusted execution.
How Safeguard Helps
Safeguard treats container runtime choice as part of your supply chain posture. Our SBOM analysis and reachability engine work across runc, crun, and gVisor without configuration changes, and Griffin AI correlates runtime-specific CVEs with your deployed images to flag exposure within hours of disclosure. Policy gates in CI can require gVisor or Kata for namespaces handling untrusted code, blocking deploys that route the wrong workload to the wrong runtime. Our zero-CVE base images ship optimized for both runc and crun, and TPRM scoring incorporates runtime maintainer responsiveness so you can make a defensible default-runtime choice for your platform without guesswork.