What is gVisor?

gVisor is an open-source application kernel developed by Google that sandboxes containers by intercepting system calls in user space. It sits between your containerised workload and the host kernel, handling syscalls through its own sandboxed process rather than passing them directly to the host.

This article covers how gVisor works, what its components do, where it fits against containers and microVMs, its limitations, and when it is the right isolation tool.

gVisor is an application kernel that implements a Linux-compatible interface in user space. When a containerised workload makes a system call, gVisor's Sentry intercepts it and handles it without passing it to the host kernel. The host kernel's attack surface is reduced because the workload never talks to it directly.

It is not a VM in the conventional sense and not a syscall filter like seccomp-bpf, which still passes syscalls to the host kernel and relies on that kernel being unexploitable within the permitted set. gVisor takes a third approach: a per-sandbox application kernel that re-implements Linux system interfaces in Go, a memory-safe language.

The Sentry acts as both guest OS and VMM in KVM mode, leveraging virtualisation extensions for address space isolation and performance, with no virtualised hardware layer. In Systrap mode, seccomp intercepts syscalls and hands control to gVisor without requiring hardware virtualisation support.

gVisor ships an OCI-compatible runtime called runsc that integrates with Docker, containerd, and Kubernetes, so existing container workflows work with minimal changes.

Standard containers share the host kernel. Every syscall a container makes goes directly to the same Linux kernel shared by every other container on that host. A kernel vulnerability exploited by one container can affect the host and everything else running on it.

For trusted internal workloads, that tradeoff is acceptable. For workloads you do not control (AI-generated code, customer-submitted scripts, third-party dependencies), the shared kernel is the attack surface. See What is a microVM? for a full breakdown of why containers fall short for some workloads, and the approaches that address it.

gVisor inserts a user-space layer between your container and the host kernel. That layer has two main components.

The Sentry is gVisor's application kernel. It is a user-space process, written in Go, that intercepts system calls made by the sandboxed workload and handles them internally. The workload thinks it is talking to a Linux kernel. It is actually talking to the Sentry.

Because the Sentry is written in Go, a memory-safe language, a large class of memory corruption vulnerabilities common in C-based kernels does not apply. The Sentry itself is also constrained by seccomp filters that limit which host kernel syscalls it can make, so even if the Sentry were compromised, its ability to interact with the host is limited.

The Gofer is a separate process that handles filesystem access on behalf of the Sentry. Rather than letting the Sentry access the host filesystem directly, file operations go through the Gofer, which acts as a proxy. This is another layer of containment: the Sentry and the sandboxed workload are further isolated from host filesystem resources.

gVisor supports two execution platforms that determine how syscall interception works.

• Systrap: uses seccomp to intercept syscalls and redirect them to the Sentry. It works on any Linux host without hardware virtualisation support, making it the more portable option. It has good performance for most workloads.
• KVM: uses virtualisation hardware to intercept syscalls, with the Sentry running as a guest. It is faster than Systrap on bare-metal hosts where KVM is available, but does not require a full guest OS. Despite using KVM, this is not a microVM; there is no dedicated guest kernel per workload.

See how gVisor's isolation model compares to standard containers and microVMs:

gVisor sits between standard containers and microVMs on the isolation-overhead curve. It provides meaningfully stronger isolation than a standard container without the resource cost of a full microVM. For a broader comparison, see Containers vs virtual machines and What is a microVM?.

gVisor is the right tool in the right context. It also has real constraints worth understanding before you deploy it.

• Syscall compatibility: The Sentry re-implements Linux system interfaces but does not cover every syscall. Some applications that depend on less common or recently added syscalls may not work correctly under gVisor. Testing your specific workload matters.
• I/O overhead: Syscall interception adds latency on I/O-heavy workloads. Benchmarks suggest this can be in the range of 10 to 30% slower than native containers depending on workload type. CPU-bound workloads are less affected.
• Weaker isolation than microVMs: Even in KVM mode, gVisor does not provide a dedicated guest kernel or virtualised hardware layer per workload. The sandbox retains a process model. For actively adversarial multi-tenant workloads, microVMs provide a broader hardware-enforced boundary.
• Linux only: gVisor runs Linux workloads. Windows containers are not supported.
• Not a replacement for defence-in-depth: gVisor is designed to complement other security controls. It uses seccomp and Linux primitives as additional containment layers around the Sentry itself, not as its primary isolation mechanism

gVisor is a good fit when:

• Nested virtualisation is unavailable: If your host does not support KVM, you cannot run microVMs. gVisor's Systrap mode runs on any Linux host and provides meaningfully stronger isolation than standard containers.
• You want enhanced container security without VM overhead: For workloads where container isolation is insufficient but you do not need the full resource cost and operational complexity of microVMs, gVisor is a practical middle ground.
• Your workloads are not I/O-bound: The syscall overhead matters most on high-throughput filesystem or network workloads. CPU-bound workloads see much less impact.
• You need defence-in-depth: gVisor layers well with other security controls and is used in production environments as one part of a broader isolation strategy.

When microVMs are the better choice, gVisor is not the right tool. If your threat model involves actively adversarial workloads, multi-tenant environments where customers could be malicious, or untrusted code execution at scale, hardware-enforced isolation is the stronger guarantee. See Firecracker vs gVisor and Kata Containers vs Firecracker vs gVisor for a detailed comparison.

Northflank applies gVisor for workloads where syscall-interception isolation is sufficient or where nested virtualisation is unavailable on the underlying host. It runs alongside Kata Containers with Cloud Hypervisor and Firecracker, with the isolation technology applied based on workload requirements. The platform has been in production since 2021 across startups, public companies, and government deployments.

Sandboxes spin up in approximately 1 to 2 seconds, with compute pricing starting at $0.01667 per vCPU per hour and $0.00833 per GB of memory per hour. See the pricing page for full details.

Northflank supports both ephemeral and persistent sandbox environments on managed cloud or inside your own VPC, self-serve into AWS, GCP, Azure, Oracle, CoreWeave, Civo, on-premises, or bare-metal via bring your own cloud.

No. gVisor is an application kernel that runs in user space. While its KVM platform leverages virtualisation hardware for address space isolation and performance, it does not boot a dedicated guest kernel or emulate a full hardware layer per workload. The sandbox retains a process model in both execution modes, with the Sentry handling syscalls on behalf of the workload rather than a separate OS image running inside a VM boundary.

No. Standard containers share the host kernel and use Linux namespaces and cgroups for isolation. A gVisor sandbox intercepts syscalls through the Sentry before they reach the host kernel, providing a stronger isolation boundary than a standard container without requiring hardware virtualisation.

The Sentry is gVisor's user-space application kernel. It is a Go process that intercepts system calls made by sandboxed workloads and handles them internally, without passing them to the host kernel. It is the core component that provides gVisor's isolation.

Yes. gVisor ships an OCI runtime called runsc. In Kubernetes, you create a RuntimeClass pointing to runsc and reference it in your pod spec. Pods assigned that RuntimeClass run with gVisor's syscall interception rather than directly against the host kernel.

Firecracker creates microVMs with hardware-enforced isolation via KVM. Each workload gets its own dedicated Linux kernel inside a hardware boundary. gVisor intercepts syscalls in user space through the Sentry without booting a VM. Firecracker provides stronger isolation for actively adversarial workloads. gVisor has lower overhead and simpler integration for workloads where syscall-interception isolation is sufficient. See Firecracker vs gVisor for a full comparison.

Systrap uses seccomp to intercept syscalls and redirect them to the Sentry. It runs on any Linux host and is the more portable option. KVM mode uses virtualisation hardware to intercept syscalls, with the Sentry running as a guest, and is faster on bare-metal hosts where KVM is available. Neither mode boots a full guest OS per workload.

• What is a microVM?: how microVMs compare to containers and gVisor, and which technologies implement them
• Firecracker vs gVisor: a detailed comparison of hardware-level and syscall-level isolation approaches
• Kata Containers vs Firecracker vs gVisor: how the three leading isolation technologies compare on security, performance, and operational complexity
• What is AWS Firecracker?: a full technical breakdown of Firecracker's architecture and how it differs from gVisor
• Firecracker vs Docker: how microVM isolation compares to standard container isolation and when each is the right choice
• Containers vs virtual machines: the broader comparison covering containers, VMs, and where gVisor fits on the isolation curve
• How to sandbox AI agents: isolation architectures for AI agent execution environments
• Secure runtime for codegen tools: how production platforms run AI-generated code safely