gVisor

Overview

gVisor is an open-source, Apache-2.0 "application kernel for containers" that originated at Google and "leverages years of experience isolating production workloads at Google". Rather than a seccomp filter or a VM, it implements a Linux-compatible kernel in Go that runs in user space and intercepts the application's system calls, so the host kernel sees only a narrow interface; the README summarises this as "gVisor implements Linux by way of Linux". It ships as an OCI runtime called runsc that plugs into Docker, containerd and Kubernetes. The default platform is systrap, which uses seccomp traps and "replaced ptrace as the default gVisor platform in mid-2023"; a KVM platform uses hardware virtualisation and "runs best on bare-metal setups". Hosts need Linux 5.6+ on x86_64 or arm64.

The adopters file shows how widely sandbox platforms build on it: "gVisor powers Google Cloud offerings GKE Sandbox, Cloud Run, App Engine"; Modal says "Compute jobs at Modal are containerized and virtualized using gVisor"; Beam combines "stateful snapshots, gVisor isolation, GPU acceleration"; Anthropic uses it "to securely contain code execution within claude.ai"; OpenAI uses it for "some higher-risk tasks"; Northflank "uses gVisor to run GPU workloads inside sandboxed environments"; Cloudflare, DigitalOcean, Snowflake and Ant Group are also listed. Two features matter for agent sandboxes: nvproxy passes NVIDIA driver ioctls through so CUDA workloads run inside the sandbox, and checkpoint/restore saves a running container to a state file. Releases are dated tags, most recently release-20261102.0.

Notable

• Adopters page: powers GKE Sandbox, Cloud Run and App Engine; also lists Modal, Beam, Anthropic (claude.ai), OpenAI, Northflank, Cloudflare, DigitalOcean, Snowflake and Ant Group
• systrap became the default platform in mid-2023; ptrace is "no longer supported and is expected to eventually be removed entirely"
• Latest release tag release-20261102.0 (2 November 2026); Apache-2.0

gVisor specifications

Facts from gVisor’s public documentation, verified November 9, 2026. Performance numbers are vendor claims.

Strengths and trade-offs

Strengths

• You want a kernel boundary without hardware virtualisation, so it works inside ordinary cloud VMs
• You need GPU workloads sandboxed, as Modal, Beam and Northflank do with nvproxy
• You run Docker or Kubernetes and want to swap in runsc as a runtime class
• You want checkpoint/restore of running containers

Trade-offs

• Syscall interception costs performance for syscall-heavy workloads; the KVM platform needs bare metal or nested virtualisation to perform well
• Only a limited set of NVIDIA ioctls and driver versions are supported, and gVisor "doesn't introduce any additional hardware-level isolation" for GPU driver bugs
• Not every Linux feature is implemented, so some applications need compatibility checks
• Linux x86_64 and arm64 hosts only

Good fit for: Sandboxing containers on hosts where you cannot or do not want to run a VM per workload, including GPU workloads.

Use cases gVisor fits

• GPU workloads: If you build your own: gVisor’s nvproxy runs most CUDA applications on T4, A100, A10G, L4 and H100, which is how several platforms run GPU sandboxes.

How gVisor compares

See all gVisor alternatives →

Frequently asked questions

Sources

1. gvisor.dev
2. github.com/google/gvisor
3. github.com/google/gvisor/blob/master/ADOPTERS.md
4. gvisor.dev/docs/architecture_guide/platforms/
5. gvisor.dev/docs/user_guide/gpu/
6. gvisor.dev/docs/user_guide/checkpoint_restore/
7. github.com/google/gvisor/releases
8. modal.com/docs/guide/security