# gVisor and runsc: an application kernel that sandboxes containers without a VM

> gVisor is Google's userspace application kernel for containers. It ships an OCI runtime called runsc that plugs into Docker and Kubernetes, and the README is explicit about what it is not: not a seccomp filter, not a QEMU-style VM.

**google/gvisor** — Project brief: Application Kernel for Containers. The runsc runtime integrates with Docker and Kubernetes, making it simple to run sandboxed containers.

- Repository: https://github.com/google/gvisor
- Website: https://gvisor.dev
- Stars: 19,431 · Forks: 2,012
- Language: Go
- License: Apache-2.0
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/google-gvisor

## The problem gVisor solves: containers share one kernel

Containers are not a sandbox. The README makes that argument directly: a single shared kernel is efficient, and it also means one kernel vulnerability is enough for a container escape. Namespaces, cgroups and capabilities divide resources, but every container syscall still lands in the same Linux kernel that the host runs on. If you are executing code you did not write, that surface is the risk.

gVisor is aimed at the people who feel that risk: platform teams running multi-tenant CI, function platforms, or customer-supplied code inside containers, and anyone who wants the isolation argument of a VM without paying the VM startup and memory cost. The README frames it as a distinct third approach, between syscall filtering and full virtualization, offering many security benefits of VMs while keeping the resource footprint and startup behaviour of a normal userspace process.

It is not a general hardening tool. The README says gVisor should not be confused with tools that harden containers against external threats, add integrity checks, or limit a service's access scope. It sits on the other side of the boundary: it reduces what the workload can ask of the host kernel.

## How the application kernel works: Linux implemented by way of Linux

gVisor implements a Linux-like interface in userspace, written in Go, a memory-safe language. The application's syscalls are intercepted and handled by that application kernel rather than by the host kernel, so the host kernel surface reachable from the container shrinks. The README's phrase for the arrangement is that gVisor implements Linux by way of Linux: it does not demand a fixed set of physical resources, it uses existing host kernel functionality and runs as an ordinary process.

The integration point is runsc, an OCI runtime. Because it speaks the OCI runtime contract, existing container tooling can drive it, which is why the README describes Docker and Kubernetes integration as the easy path. The repository layout matches that story: runsc/ holds the runtime, shim/ holds the containerd shim, sandboxexec/ and webhook/ are separate top-level components, and examples/ contains sandboxexec/ and seccheck/ sample directories.

The build produces more than one binary. The README describes a release tarball containing runsc, the containerd-shim-runsc-v1 containerd shim, and sidecar binaries that runsc expects to find in a gvisor-bin/ directory next to itself. That detail matters operationally: moving runsc without its sidecars breaks it, and it is also why the go branch cannot produce a supported runtime.

## Installing gVisor: build the release tarball and extract runsc

The README documents building from source rather than a package install. Requirements are Linux 5.6+ and Docker version 17.09.0 or greater; builds are supported on x86_64 and ARM64, with other architectures described as possibly available in the future. Bazel and the other build dependencies are wrapped in a build container, so the two commands below are the documented path. The first builds a release tarball into bin/, the second extracts it to /usr/local/bin, which is where the README expects the binaries to land.

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

After extraction you should have runsc, the containerd shim, and the sidecar binaries that runsc looks for in gvisor-bin/ beside itself. If you only need a specific library or binary, the Makefile takes a target list instead of the full release build.

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

The README notes that using Bazel directly is possible but not recommended because of the extra overhead. If you go that route anyway, it points at images/default/Dockerfile as the canonical dependency list, and at .bazelversion for the version you must match; bazelisk is the suggested way to get the right Bazel. The Makefile also exposes make help for the standard targets.

For Go code rather than the runtime, the README documents a synthetic go branch for importing gVisor subpackages such as userspace networking through Netstack. The branch must be selected explicitly, because @latest resolves master, which requires Bazel and is not compatible with standard Go tooling.

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

## Where gVisor is the wrong tool

The most concrete limitation is stated in the README itself: runsc builds from the go branch are not supported. The go branch exists for external Go packages that import gVisor subpackages, it is supported in a best effort capacity, and direct development on it is not supported. Anyone who assumes that go get gvisor.dev/gvisor gives them a container runtime has misread the project.

Second, gVisor is not a VM and does not claim to be one. If your threat model requires a hypervisor boundary, or your compliance story is written around hardware virtualization, an application kernel in userspace is a different answer to a different question. The README explicitly separates gVisor from VirtualBox and QEMU style VMs.

Third, the whole design rests on reimplementing a Linux interface. The README says gVisor gives applications access to all the features they expect, but a userspace kernel that intercepts syscalls is a compatibility surface, not the kernel itself. There is no compatibility matrix in the README, so the honest position is that you have to test your own workload. Workloads that lean on unusual syscalls, kernel-specific behaviour, or direct hardware access are the first places to look when something misbehaves under runsc.

Finally, gVisor is not a data control. The README is blunt that you should always be careful about what data is made available to a container. Isolation between the workload and the host kernel does not decide which secrets you mounted.

## gVisor compared with Firecracker and Kata Containers

The distinction that matters is where the boundary sits. Firecracker and Kata Containers both use virtual machines: Kata runs each container or pod inside a lightweight VM, and Firecracker is a minimal VMM built for that style of workload. The isolation boundary is the hypervisor, and the guest runs its own kernel.

gVisor does not boot a guest kernel. It intercepts syscalls and serves them from an application kernel written in Go, running as a normal process on the host. The README's framing is that this keeps the resource footprint, startup time and flexibility of a userspace application while providing many of the security benefits of a VM. The trade is compatibility: a VM runs a real Linux kernel, so the syscall surface is the kernel's own, while gVisor's surface is whatever the application kernel implements.

The practical consequence is that the choice is rarely about raw isolation strength in the abstract and more about which boundary your workload tolerates. If your workload needs a real kernel underneath it, a VM-based runtime is the safer default. If you want the isolation boundary without a separate kernel boot, runsc is the option this project offers, and it is driven through the same OCI tooling either way.

## Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-08-25, which is recent. The most recent release listed is release-20260817.0, dated 2026-08-25. That release cadence is worth noting if you deploy runsc: you are tracking a runtime that sits between your containers and the host kernel, so upgrades are not cosmetic. Because the release tarball carries runsc plus the containerd shim plus sidecars in gvisor-bin/, an upgrade is a coordinated replacement of that set, not a single binary swap.

The licence is Apache-2.0, which is a permissive licence with an explicit patent grant. That is a normal fit for commercial deployment. It is not legal advice, and the repository's SECURITY.md and GOVERNANCE.md are the places to look for the project's own policies rather than anything inferred here.

Build cost is real and the README is honest about it: Bazel and dependencies are wrapped in a build container to simplify up-front requirements, and building Bazel directly is described as extra overhead. The go branch exists precisely because the Bazel requirement is inconvenient for external Go consumers, and it comes with the explicit caveat that runsc cannot be built from it.

## Who should adopt gVisor, and what to check first

Adopt it if you run containers whose contents you do not fully trust and you want a second boundary that is not a hypervisor. The OCI runtime contract means you do not have to rewrite your deployment tooling to try it, and the README positions Docker and Kubernetes integration as the intended path.

Do not adopt it as a general container hardening measure, as a replacement for a VM boundary, or as a Go library that happens to include a runtime. The README rules out the first two by describing what gVisor is not, and the third by stating that runsc builds from the go branch are not supported.

Before you commit, confirm the host meets Linux 5.6+ and Docker 17.09.0 or greater, build the release tarball, and run one representative workload under runsc rather than a hello-world image. The thing to watch is syscall behaviour, because that is the surface gVisor reimplements. The README offers no compatibility list, so your own workload is the only test that answers the question.

## Conclusion

Adopt gVisor when you are running container workloads you do not fully trust and you can accept a userspace kernel between the workload and the host. Do not adopt it if you need a VM boundary, if your workload depends on syscalls the application kernel does not implement, or if you expect `go get` to produce a working runsc: the README states that runsc builds from the go branch are not supported. Verify first that your host is Linux 5.6+ with Docker 17.09.0 or greater, then run your own workload under runsc and watch for syscall errors rather than trusting a generic compatibility list.

## FAQ

### What does gVisor do?

It provides a layer of isolation between running applications and the host operating system by implementing a Linux-like interface as an application kernel in userspace. It ships an OCI runtime called runsc that integrates with Docker and Kubernetes.

### Is gVisor a VM?

No. The README states that gVisor is not a VM in the everyday sense of the term, naming VirtualBox and QEMU as examples, and that it is also not a syscall filter such as seccomp-bpf. It describes gVisor as a distinct third approach that keeps the resource footprint and startup behaviour of a userspace application.

### How do I install gVisor?

The README documents installing from source: build a release tarball with make release-tarball DESTINATION=bin/ and extract it to /usr/local/bin. Requirements are Linux 5.6+ and Docker version 17.09.0 or greater, and builds are supported on x86_64 and ARM64.

### What is gVisor in Kubernetes?

It is the same application kernel, reached through runsc, which is an OCI runtime. The README states that runsc integrates with Docker and Kubernetes, so sandboxed containers can be run through existing container tooling. The release tarball also includes the containerd-shim-runsc-v1 containerd shim.

### Is gVisor open source and free?

The repository is published under the Apache-2.0 licence, which is a permissive open source licence. Nothing in the README describes a paid tier or a commercial edition.

## Sources

- [Official documentation](https://gvisor.dev)
- [Official README](https://github.com/google/gvisor#readme)
- [Project repository](https://github.com/google/gvisor)
- [Release notes](https://github.com/google/gvisor/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/google-gvisor