explaingit

google/gvisor

📈 Trending18,339GoAudience · ops devopsComplexity · 4/5ActiveLicenseSetup · hard

TLDR

A security sandbox for containers that intercepts system calls, reducing kernel exposure and preventing container escapes without the overhead of a full virtual machine.

Mindmap

mindmap
  root((gVisor))
    What it does
      Intercepts system calls
      Isolates containers
      Prevents escapes
    How it works
      Application kernel layer
      Memory-safe Go code
      Lightweight runtime
    Tech stack
      Go language
      Linux kernel
      x86-64 and ARM64
    Use cases
      Untrusted workloads
      Multi-tenant systems
      Kubernetes security
    Integration
      Docker compatible
      Kubernetes ready
      runsc runtime

Things people build with this

USE CASE 1

Run untrusted or third-party code safely in containers without risking the host system.

USE CASE 2

Build multi-tenant container platforms where workloads from different customers must be isolated from each other.

USE CASE 3

Deploy Kubernetes clusters with stronger security boundaries between pods without switching to full virtual machines.

Tech stack

GoLinuxx86-64ARM64DockerKubernetes

Getting it running

Difficulty · hard Time to first run · 1h+

Requires Linux kernel with seccomp/BPF support, Docker/container runtime, and understanding of syscall filtering to validate functionality.

Use freely for any purpose, including commercial use, as long as you keep the copyright notice and license text.

In plain English

gVisor is a security sandbox for containers, created by Google. To understand why it exists, a little background helps: containers (like those managed by Docker or Kubernetes) are a way to run multiple isolated applications on a single computer. However, all containers on a machine share the same underlying operating system kernel, the core software that manages hardware and system calls. That shared kernel means a vulnerability in one container could potentially be exploited to escape the container and affect the host machine or other containers. gVisor takes a different approach. It acts as an application kernel, essentially a lightweight software layer that sits between a containerized application and the real host kernel. When a containerized app wants to do something at the system level (read a file, open a network connection, etc.), those requests go to gVisor first rather than directly to the host kernel. gVisor intercepts and handles them, dramatically reducing how much of the host kernel is exposed to the application. Crucially, gVisor itself is written in Go, a memory-safe programming language, which avoids entire categories of common security bugs. It is not a virtual machine in the traditional sense, it has a much smaller resource footprint and starts quickly. It ships with a runtime component called runsc that plugs into Docker and Kubernetes, so existing container workflows require minimal changes to gain the added isolation. gVisor runs on x86-64 and ARM64 Linux systems.

Copy-paste prompts

Prompt 1
How do I install gVisor's runsc runtime and configure Docker to use it for running containers with sandboxing?
Prompt 2
What are the performance trade-offs of using gVisor compared to running containers directly on the host kernel?
Prompt 3
Show me how to set up a Kubernetes cluster where certain pods run under gVisor for additional isolation.
Prompt 4
How does gVisor prevent container escape attacks compared to traditional container runtimes?
Open on GitHub → Explain another repo

Generated 2026-05-18 · Model: sonnet-4-6 · Verify against the repo before relying on details.