gVisor

What it is

gVisor is an OCI-compatible container runtime that implements a substantial portion of the Linux kernel surface in userspace, written in Go. Instead of containers making syscalls directly to the host kernel (as with runc), gVisor intercepts them and handles them in its own sandbox kernel (Sentry), backed by either ptrace or KVM. The goal is to reduce the attack surface of the host kernel when running untrusted or semi-trusted workloads. It ships as runsc and drops into the same places runc does — Docker's --runtime flag, containerd shims, and Kubernetes via a RuntimeClass.

Description metadata isn't publicly available beyond this, but functionally: it's a sandboxing layer for container isolation, not a full VM, not a full kernel replacement.

Who builds it and why

gVisor originated at Google and is maintained primarily by Google engineers, though it's open source under Apache-2.0 and takes outside contributions (348 contributors on GitHub). It exists because Google runs multi-tenant, untrusted workloads (think Cloud Run, GKE Sandbox, App Engine) and needed stronger isolation than a shared-kernel container gives you, without paying the overhead and operational complexity of a full VM per workload. It's infrastructure Google built for its own cloud products first; open-sourcing it was secondary.

CNCF maturity level is not publicly available — worth checking directly if that matters for your adoption criteria, since gVisor is sometimes miscategorized as a CNCF project when it's Google-governed.

Production readiness signal

18,640 GitHub stars and 348 contributors is a solid signal of real usage, not a toy project. Active commit history through mid-2026 confirms it's not abandoned. It underpins production services at Google (GKE Sandbox, Cloud Run, Cloud Functions), which is a stronger readiness signal than star count — this isn't a side project, it's load-bearing infrastructure for a hyperscaler's multi-tenant compute.

That said: latest release version and founding date are not publicly available from the data given, so you'll want to check the release cadence and changelog yourself before committing to a version pin in a production manifest.

Who should use this

• Platforms running untrusted or third-party code — CI runners, PaaS offerings, FaaS platforms, anywhere you accept arbitrary customer workloads.
• Teams that need defense-in-depth beyond seccomp/AppArmor/SELinux profiles but can't justify per-workload VMs (Firecracker, etc.) for cost or density reasons.
• Kubernetes operators who want to sandbox specific namespaces or workloads via RuntimeClass without re-architecting the whole cluster.

Who should NOT use this

• Syscall-heavy or highly optimized workloads. gVisor's userspace syscall interception adds real overhead — I/O-bound and syscall-dense apps (databases, some ML training pipelines) will feel it. Benchmark before you commit.
• Workloads needing full Linux kernel compatibility. gVisor doesn't implement 100% of the syscall surface. Niche ioctls, certain namespaces, and some device access patterns will break. If your app does anything unusual with the kernel, test first.
• Teams wanting simplicity. If your threat model doesn't include untrusted code execution, runc is simpler, faster, and has fewer moving parts. Don't add sandboxing overhead for workloads you already trust.
• GPU/accelerator-heavy workloads, historically — device passthrough support has been limited and evolving; verify current state for your specific hardware before assuming it works.

Alternatives

• Kata Containers: lightweight VMs per pod instead of userspace syscall interception — stronger isolation boundary, different performance tradeoffs.
• Firecracker: microVM-based isolation (AWS), commonly paired with container orchestration for stronger per-workload isolation than namespaces alone.
• runc (default): no sandboxing overhead, standard shared-kernel isolation — the right choice when you trust what you're running.

Pricing

Fully open source, Apache-2.0. No paid tier, no vendor lock-in. Cost is operational: engineering time to integrate, tune, and validate compatibility with your workloads, plus the runtime performance overhead in production.