gvisor

gVisor is an application kernel, written in Go, that sits between containerized applications and the host Linux kernel. It implements a Linux-like interface in userspace and intercepts syscalls, reducing the amount of host kernel surface an application can reach. It ships with runsc, an OCI-compatible runtime that plugs into Docker and Kubernetes, so you can run sandboxed containers with existing tooling. It's aimed at platform engineers and infrastructure teams who run untrusted or multi-tenant workloads and want stronger isolation than a shared-kernel container gives them.

The project is explicit about what it is not: it's not a syscall filter like seccomp-bpf, not a wrapper over Linux isolation primitives like AppArmor or firejail, and not a full VM like QEMU or VirtualBox. Instead it reimplements much of the Linux kernel interface in a memory-safe userspace process, giving many of the security properties of VM-level isolation while keeping the startup speed and density of regular containers.

Key features

• Application kernel architecture: implements Linux syscalls, signal handling, and other kernel interfaces in userspace, in Go, rather than relying on the host kernel to mediate every call.
• OCI runtime (runsc): a drop-in runtime that works with existing container tooling instead of requiring a new orchestration model.
• Docker and Kubernetes integration: works as an alternative runtime for containers you already build and deploy through standard workflows.
• containerd shim support: ships a containerd-shim-runsc-v1 binary so it plugs into containerd-based clusters.
• Memory-safe implementation: written in Go rather than C, which removes a class of memory-corruption bugs common in traditional kernel code.
• Reduced host kernel exposure: limits which host kernel syscalls and features a sandboxed application can directly reach, shrinking the attack surface for container escapes.
• Runs as a normal process: doesn't require dedicated physical resources or a hypervisor; it leverages existing host kernel functionality and runs like any other userspace process.
• Netstack: a userspace network stack (available as an importable Go package) that can be used independently in other Go projects.

Ideal use cases

gVisor fits well when you run untrusted or third-party code inside containers, such as multi-tenant SaaS platforms, CI runners that execute arbitrary user-submitted code, or serverless/FaaS platforms that need stronger tenant isolation than the default container boundary. It's also useful in Kubernetes clusters where you want an extra isolation layer for specific pods without switching to full VMs per workload.

It's not the right tool if your workload is trusted and performance-sensitive at the syscall level. Because gVisor intercepts syscalls in userspace, workloads with heavy syscall traffic (intensive I/O, unusual syscall patterns) can see a real performance cost compared to native containers. It's also not a replacement for host hardening, integrity checks, or scoping what data a container can access. gVisor addresses kernel isolation specifically. It's not designed as a general-purpose seccomp replacement or an application-level access control mechanism, and it explicitly isn't a VM, so don't expect VM-level hardware isolation guarantees.

Installation

gVisor builds on x86_64 and ARM64 and requires Linux 5.6+ and Docker 17.09.0 or greater. Builds run inside a Docker-wrapped Bazel environment by default.

Build a release tarball containing runsc, the containerd shim, and sidecar binaries, then install it:

make release-tarball DESTINATION=bin/
sudo tar -C /usr/local/bin -xf bin/gvisor.tar.bz2

To build a specific library or binary target:

make build TARGETS="//pkg/tcpip:tcpip"

You can also build directly with Bazel, though the Makefile path is recommended to avoid extra setup overhead. Install bazelisk or match the version in .bazelversion, then run:

bazel build -c opt //debian:gvisor-release-tar-bz2

To run tests:

make unit-tests
make tests

Or target a specific test:

make test TARGETS="//runsc:version_test"
bazel test //runsc:version_test

For Go projects that only need gVisor's Go packages (e.g. Netstack) without building runsc itself, use the synthetic go branch:

go get gvisor.dev/gvisor/pkg/tcpip/transport/tcp@go

Note that runsc builds are not supported from the go branch; it's maintained on a best-effort basis for library consumers, and actual development happens on master.

After installing runsc, you'll typically configure it as an alternate runtime in Docker's or Kubernetes' container runtime configuration; see the full setup guide at gvisor.dev for those integration steps.