# What is gVisor?

gVisor is Google's open-source application kernel, written in Go, that intercepts a container's system calls and handles them in user space.

**Runtime gives each sandbox its own Linux kernel in a Firecracker microVM
instead**, so code talks to a real guest kernel behind a hardware
virtualization boundary. A new sandbox ran its first Python command 351 ms
after the request at the median, measured on 24 September 2026
([speed](/docs/speed)).

## How does gVisor work?

gVisor sits between an application and the host kernel. In its own words it
"intercepts application system calls and acts as the guest kernel, without the
need for translation through virtualized hardware." It has three parts:

- **Sentry**, the application kernel. It implements system calls, signal
  delivery, memory management and the threading model.
- **Gofer**, a host process that mediates file access for the Sentry.
- **runsc**, the OCI runtime that plugs gVisor into Docker and Kubernetes.

The Sentry itself calls only "a minimal set of host system calls", which do
not include opening files or creating sockets in the default modes. How system
calls reach the Sentry depends on the platform: systrap, the default since
mid-2023, uses seccomp to trap them; a KVM platform uses virtualization
extensions; ptrace is no longer supported.

## Facts

| Property        | gVisor, as the project states it                                             |
| --------------- | ---------------------------------------------------------------------------- |
| What it is      | An application kernel that implements a Linux-like interface                 |
| Language        | Go, memory-safe, running in user space                                       |
| Kernel boundary | Sentry in user space; no guest kernel, no device emulation                   |
| Interface       | runsc, an OCI runtime for Docker and Kubernetes                              |
| Overhead        | "A small, mostly fixed amount of memory"; no single start-time figure        |
| Trade-off       | "Reduced application compatibility and higher per-system call overhead"      |
| Used in         | GKE Sandbox, Cloud Run, App Engine; Modal and Northflank are listed as users |

## Is gVisor a virtual machine?

No. The project says it is not "a VM in the everyday sense" and not "a syscall
filter" either. It boots no guest kernel and emulates no devices. It also warns
that "one should not assume that the mere use of virtualization hardware makes
a system more or less secure". Its README says it provides "many security
benefits of VMs while maintaining the lower resource footprint, fast startup,
and flexibility of regular userspace applications."

## How Runtime relates to gVisor

Runtime's boundary is a Firecracker microVM rather than gVisor: each sandbox
runs a real Linux kernel of its own, with `sudo` working inside. Docker Engine
runs in a sandbox after `sudo enable-docker`
([sandbox environment](/docs/sandbox-environment#docker)). Modal's
sandboxes use gVisor ([Runtime vs Modal](/docs/modal-sandbox-alternative)).

Related: [microVM](/glossary/microvm), [Firecracker](/glossary/firecracker),
[Firecracker vs gVisor](/compare/firecracker-vs-gvisor),
[gVisor vs Docker](/compare/gvisor-vs-docker).

## Sources

Checked 25 September 2026.

- [gVisor documentation](https://gvisor.dev/docs/), [gVisor README](https://github.com/google/gvisor)
- [gVisor security model](https://gvisor.dev/docs/architecture_guide/security/)
- [gVisor platforms](https://gvisor.dev/docs/architecture_guide/platforms/)
- [gVisor performance guide](https://gvisor.dev/docs/architecture_guide/performance/)
- [gVisor users](https://gvisor.dev/users/)

Facts on this page were checked on 25 September 2026.