gVisor

Executive Summary

gVisor is Google's answer to a hard question: how do you run untrusted containerized code without exposing the host Linux kernel's enormous attack surface, and without paying for a full virtual machine? Its answer is an application kernel — the Sentry — written in Go, which intercepts a container's system calls and services them in userspace, so the workload never talks to the host kernel directly.^[1] Open-sourced by Google in 2018, the repository has 18,500+ stars and 1,600+ forks as of June 2026, with near-weekly release tags.^[2]

What separates gVisor from most isolation projects is production proof: Google runs millions of gVisor sandbox instances daily, and it is the isolation layer behind GKE Sandbox, Cloud Run, and App Engine.^[3] In the AI era it has found a second life as the containment layer for agent-generated code — Anthropic uses it to contain code execution in claude.ai, OpenAI uses it for higher-risk tasks including code execution, and Cloudflare, DigitalOcean, Modal, and Ant Group all run it in production.^[3] The counterweight is performance: independent research measured simple syscalls at 2.2x slower than runc and worst-case file operations dramatically slower, so fit depends on workload shape.^[4]

---

Product Overview

gVisor presents itself to the container ecosystem as runsc, a drop-in OCI runtime: you register it with Docker or containerd and run containers exactly as before, except each one now executes against the Sentry instead of the host kernel.^[1] The Sentry implements a substantial portion of the Linux syscall surface itself; a separate process, the Gofer, mediates filesystem access, so even a fully compromised application is boxed in by two layers of seccomp-restricted userspace processes.^[1]

On Kubernetes, gVisor is consumed through GKE Sandbox or by installing the containerd shim and selecting it per-pod via RuntimeClass — making isolation a scheduling decision rather than an infrastructure rebuild.^[1] Several companies also use gVisor's components à la carte: Docker integrates gVisor's netstack (its userspace network stack) in Docker for Mac, and Tailscale builds its userspace networking on the same library.^[3]

Key Capabilities

Product Surfaces

---

Technical Architecture

The architecture is the differentiator in this category. Where Firecracker and Kata boot a real guest kernel inside a VM, gVisor reimplements the kernel interface: the Sentry is a Linux-compatible kernel in Go that handles syscalls, manages memory, and runs its own network stack in userspace.^[1] How syscalls get intercepted is pluggable. The default systrap platform uses seccomp's SIGSYS signal mechanism and performs well inside VMs (no nested virtualization needed); the KVM platform uses virtualization extensions and is best on bare metal; the original ptrace platform is deprecated due to high context-switch overhead.^[5]

# Register runsc with Docker, then:
docker run --runtime=runsc --rm hello-world

For AI workloads, nvproxy proxies the application's interactions with the host NVIDIA driver, passing through an allowlisted set of ioctls with negligible overhead for GPU-bound work. It supports T4, A100, A10G, L4, and H100 GPUs (and likely other cards on the same microarchitectures), targeting CUDA workloads like PyTorch, LLMs, and Stable Diffusion — but it requires strict driver-version matching and explicitly does not protect against vulnerabilities in the NVIDIA driver itself.^[6]

Key Technical Details

---

Strengths

• Proven at Google scale — Millions of sandbox instances daily; the production substrate of GKE Sandbox, Cloud Run, and App Engine^[3]
• The AI containment incumbent — Anthropic contains claude.ai code execution with it, OpenAI uses it for higher-risk tasks, and Modal virtualizes compute jobs with it^[3]
• No VM to boot or manage — Works inside existing VMs without nested virtualization (systrap), unlike VM-based runtimes^[5]
• Drop-in adoption — OCI-compatible runsc means unchanged images and per-pod opt-in via Kubernetes RuntimeClass^[1]
• GPU support exists — nvproxy makes sandboxed CUDA/PyTorch/LLM workloads viable with negligible GPU-path overhead, a gap in many sandboxing approaches^[6]
• Active, predictable maintenance — Near-weekly release tags and daily pushes as of June 2026, backed by Google rather than a startup^[2]
• No CPU emulation — Raw instruction execution is untouched, so compute-bound workloads see minimal penalty^[7]

---

Cautions

• Syscall overhead is structural — The USENIX "True Cost of Containing" study measured simple syscalls at 2.2x+ slower than standard containers, the fastest configuration (Sentry-only on KVM) at 2.8x slower than native, and worst-case open/close on external tmpfs at 216x slower^[4]
• Syscall-heavy workloads suffer most — gVisor's own docs flag networking and file I/O as the largest overhead sources, with Redis-style small-operation workloads as the worst case^[7]
• Public perception fights benchmarks — A widely shared HN thread claimed GKE Sandbox syscall performance was "at least 100x worse than virtualization"; defenders noted the figure reflected the now-deprecated ptrace platform, but the criticism stuck^[8]
• Compatibility is a moving subset — The Sentry reimplements the Linux interface rather than running a real kernel, so apps depending on uncommon syscalls or kernel features can break in ways VM-based runtimes don't
• GPU support is narrow and version-locked — Allowlisted ioctls, restricted device files, strict driver-version matching, and no protection against NVIDIA driver vulnerabilities themselves^[6]
• Network stack is less mature — gVisor classifies netstack's CPU efficiency and missing recovery mechanisms as known "implementation costs" still being optimized^[7]

---

Pricing & Licensing

Licensing model: Free and open source (Apache 2.0), developed and maintained by Google.^[2]

Hidden costs: The performance tax is the price — syscall- and I/O-heavy workloads need more CPU for the same throughput, and engineering time goes to platform selection (systrap vs KVM) and compatibility validation.^[7]

---

Competitive Positioning

Direct Competitors

When to Choose gVisor Over Alternatives

• Choose gVisor when: You're running untrusted or AI-generated code on infrastructure where nested virtualization is unavailable, you want per-pod opt-in isolation on Kubernetes, or you're on Google Cloud where it's the managed default
• Choose Firecracker when: You control bare metal, need hard multi-tenant boundaries with full kernel semantics, and can build the orchestration layer (or use a platform that has)
• Choose Kata Containers when: You need maximum Linux compatibility with VM isolation behind a standard OCI/Kubernetes interface
• Choose plain runc when: The workload is trusted and performance is paramount^[4]

---

Ideal Customer Profile

Best fit:

• Platforms executing untrusted or AI-agent-generated code — the pattern validated by Anthropic, OpenAI, Modal, and Cloudflare^[3]
• Kubernetes teams wanting per-workload sandboxing via RuntimeClass without changing images
• Cloud environments without nested virtualization, where VM-based runtimes can't run^[5]
• Sandboxed ML/CUDA inference on supported NVIDIA GPUs^[6]
• Compute-bound workloads where CPU execution dominates over syscalls^[7]

Poor fit:

• Syscall-, network-, or file-I/O-heavy services (databases, caches, static file serving) where overhead compounds^[7]
• Workloads depending on obscure kernel features the Sentry doesn't implement
• Teams needing exotic GPU configurations or unsupported driver versions^[6]

---

Viability Assessment

gVisor's viability question isn't survival — Google's serverless business runs on it — but governance: it lives in the google/ org with no foundation, so the roadmap follows Google's priorities. The eight-year production record and the roster of named adopters running untrusted AI code suggest that, for its niche, it has already won the credibility argument.^[3]

---

Bottom Line

gVisor is the most production-proven way to give containers a real isolation boundary without booting VMs. The userspace-kernel design is a genuine third option between "share the host kernel" and "boot a guest kernel," and the customer list — Google itself at millions of daily instances, plus Anthropic, OpenAI, Cloudflare, and Modal containing untrusted code — is unmatched in the category.^[3]

The trade is permanent and well-documented: every syscall pays an interception tax, independent benchmarks put simple syscalls at 2.2x+ slower and pathological file patterns far worse, and gVisor's own docs concede networking and file I/O remain the weak spots.^[4] Profile your workload before committing.

Recommended for: Platforms running untrusted or AI-generated code — especially on Kubernetes or inside VMs where nested virtualization rules out microVM runtimes — and teams wanting Google-grade sandboxing with zero licensing cost.

Not recommended for: I/O-bound or syscall-heavy services where the overhead compounds, or workloads needing full Linux kernel compatibility — those belong on Kata Containers or bare runc.

Outlook: The AI code-execution wave is pulling gVisor into its second act; nvproxy's GPU support targets exactly that market. Expect continued performance work on netstack and the VFS layer, and watch whether single-vendor governance becomes a friction point as adoption outside Google grows.

---

Research by Ry Walker Research • methodology