gVisor is an open-source application kernel that runs in userspace and provides a Linux-compatible interface for sandboxed programs. Written in Go, it handles application system calls through its Sentry kernel. Its runsc container runtime integrates with Docker and Kubernetes to isolate container workloads.
Copy link to headingWhat does an application kernel do?
An ordinary Linux container runs as isolated processes that share their container host's kernel. The host may itself be a virtual machine. Container packaging tells you which application files and dependencies travel together, but you also need to understand which kernel handles the running program's requests.
System calls request operating-system services. An application's runtime can use them to access a file or obtain information about its process. Under gVisor, the Sentry implements the system-call behavior the application sees. It also handles page faults and maintains the sandbox's process state.
Consider getpid, which asks for the calling process's identifier. The Sentry already tracks that process, so it can answer the request using its own state. It doesn't forward the application's call to the host kernel. When an operation needs host resources, the Sentry makes restricted host calls of its own.
This is why treating gVisor as a syscall filter misses its purpose. Syscall filters decide which calls may proceed; the Sentry implements the calls itself. Evaluate its Linux-compatible interface against the behavior your workload requires.
Copy link to headingHow do Sentry, Gofer, and runsc fit together?
The names describe different responsibilities within gVisor. Separating them helps when you're reading a runtime configuration or investigating why a container behaves differently under gVisor.
The Gofer manages filesystem access, while settings such as directfs and host networking affect the host interactions gVisor permits. Treat those settings as part of your isolation design. Understanding the Sentry alone doesn't tell you which host files a deployment exposes.
For a Docker deployment, registering and selecting runsc connects the container workflow to gVisor. Keep the runtime selection in your deployment configuration so reviewers can see which isolation mechanism a container uses. The application image alone doesn't identify the runtime.
Copy link to headingDoes gVisor use hardware virtualization?
gVisor supports different platforms for intercepting application execution. Systrap has been the default since mid-2023. It uses seccomp traps to hand system calls to gVisor without requiring hardware virtualization.
The KVM platform uses hardware virtualization extensions. Even in this configuration, gVisor keeps its application-kernel and process model without a conventional virtualized hardware layer. Selecting KVM doesn't turn the sandbox into a standard Linux guest operating system.
When evaluating a deployment, record the selected platform alongside the host configuration. Otherwise, two tests described as "running under gVisor" may exercise different interception mechanisms. Keep that configuration fixed when comparing results, then test a different platform separately if it is relevant to the environment you plan to operate.
Copy link to headingHow can you test gVisor with Docker?
Use a compatible Linux host with Docker and runsc installed, following the installation and runtime registration instructions. Some installation methods already register runsc, in which case you can proceed to running the container.
Register the runtime if installation hasn't already done so.
sudo runsc installRestart Docker after adding the runtime. On a systemd host, use:
sudo systemctl restart dockerRun the smoke test with the runtime selected explicitly.
docker run --runtime=runsc --rm hello-world
Use a successful smoke test as a starting point for testing your application. It doesn't establish that every dependency works or that the deployment has the intended permissions. The dmesg banner inside the sandbox can help diagnose runtime selection, but it isn't security attestation.
Next, run the image you intend to deploy with representative inputs and exercise the work it performs after startup. For a document-processing worker, test the conversion and inspect the output.
Copy link to headingHow should you evaluate compatibility and overhead?
gVisor implements a subset of the Linux syscall ABI, the binary interface programs use to request kernel services. Missing syscalls do not automatically make a language runtime incompatible. Many runtimes can use supported alternatives, so test the application rather than relying on a syscall checklist.
Build the evaluation around the operations the workload must complete. For a worker that processes uploaded files, use the dependency versions and input formats you expect in production.
Test malformed inputs as well as successful conversions. Compare results with the expected output and retain a reproducible example of any failure.
Separate functional failures from performance concerns. The Sentry consumes memory, and system calls traverse additional software layers. Those costs make measurements of your own workload more useful than a general claim that an isolation architecture is fast or slow.
Choose measurements that correspond to the service you operate. For an interactive task, completion latency may determine whether the result is usable. For a background worker, measure completed jobs under a representative concurrent load and account for memory consumption.
Keep inputs and host resources consistent across runs. Record the gVisor platform and configuration so later tests can reproduce the comparison.
Copy link to headingWhat doesn't gVisor protect?
Isolation preserves the access you deliberately allow. An application can still use mapped files and permitted network connections. Host cgroups enforce resource limits, network policy belongs outside the sandbox, and hardware side-channel defenses depend on the host and platform.
For a file-processing worker, mount only the inputs it needs and provide a deliberate location for results. Treat the result as application output that still needs validation before another system consumes it. Limiting host access doesn't establish that a generated file is correct or suitable for publication. Keep those output-handling decisions visible alongside the runtime configuration.
Copy link to headingWhen should you consider a different isolation architecture?
If your evaluation identifies required Linux behavior that gVisor doesn't implement, test the same application operations in a guest-kernel environment before choosing an architecture. Container packaging alone doesn't establish compatibility.
Copy link to headingHow does Vercel Sandbox approach code isolation?
Vercel Sandbox provides managed Firecracker microVMs, each with a dedicated guest kernel, filesystem, and network environment. Where gVisor implements application system calls in the Sentry, programs in Vercel Sandbox use the microVM's Linux kernel. This gives you a guest-kernel execution option without operating the underlying VM hosts yourself.
For the document-processing worker, your application can create a sandbox, write the selected input files, and run the conversion through the Sandbox SDK. Keep the conversion tools in a custom image built from a Dockerfile so each new environment starts with the tested dependencies.
Retrieve the result for validation before storing or publishing it. To try the SDK, configure authentication and run your first command.
For a conversion that needs no external services, set the Sandbox firewall to deny-all. Outbound traffic is allowed by default.
Sandboxes also persist their files between sessions by default. Choose persistent: false for disposable jobs, or retain a workspace when later work needs its files. Reuse the tool image for unrelated jobs while keeping each job's input files in its own sandbox.
Copy link to headingFrequently asked questions
Copy link to headingIs gVisor a virtual machine?
gVisor runs an application kernel instead of booting a full guest operating system. Its optional KVM platform uses virtualization extensions but retains gVisor's process model without a conventional virtualized hardware layer.
Copy link to headingDoes gVisor replace Docker?
No. Docker can use gVisor's runsc container runtime. Select runsc when launching a container to apply gVisor's isolation to that workload.
Copy link to headingCan gVisor run every Linux application?
No. gVisor supports a subset of the Linux syscall ABI, so required kernel behavior may be missing. Test your application and dependencies, since runtimes can sometimes use supported alternatives to unavailable calls.
Copy link to headingDoes gVisor require hardware virtualization?
No. Systrap, the default platform, intercepts system calls with seccomp traps. Hardware virtualization is required for the KVM platform.