gVisor intercepts container system calls in userspace
Ordinary containers share the host kernel. A kernel escape can therefore cross the boundary that namespaces and cgroups are supposed to maintain. gVisor inserts its Sentry application kernel between the workload and the host. The container speaks a Linux-like system interface to Sentry, which exposes a smaller, restricted set of calls to the real kernel. runsc implements the OCI runtime interface, so Docker and Kubernetes can select this sandbox without changing the application image.
This design sits between runc and a conventional virtual machine. It does not boot a guest OS or emulate CPU instructions, but it reimplements a large Linux surface in Go. Our checkout contained 4,197 files, about 874,491 source lines, and 66.6 MB before dependencies. That size reflects an application kernel, network stack, filesystems, runtime, tooling, and platform integrations. Teams should evaluate it as a security subsystem, with upgrades and compatibility tests, rather than as a minor Docker option.
Compatibility stops short of full Linux behavior
gVisor's documentation says the only reliable compatibility test is running the actual container. Common language runtimes receive regression testing, and unsupported syscall variants often have fallbacks in their libraries. Gaps remain by design and by implementation. In-sandbox cgroups account for CPU and memory but do not enforce limits between processes in one sandbox. Block-device filesystems cannot be mounted inside it, iptables support is partial, io_uring is limited, and KVM cannot run inside the sandbox.
Those restrictions matter for infrastructure software that probes kernel features or manages devices. Issue #14470, updated August 28, 2026, reports a bind-mount regression for one root-path arrangement. One report does not establish general failure, but it is the kind of integration detail a staging suite should catch. The repository had 9 CI workflow files and a tests directory in our scan. That upstream coverage cannot substitute for booting your own images, exercising storage, and confirming shutdown plus restart behavior.
What happened when we ran it
Our sandbox installed 396 Go packages in 43 seconds at commit 4a7fcd5. The build succeeded in 19 seconds. The test step failed with exit code 1 after 4 seconds, before a test ran: the summary was 0 passed and 0 failed out of 0. This is a failed command, even though it contains no failed assertion.
The final log said updates to go.mod were needed and instructed us to run go mod tidy. We did not change the checkout, so the measured test command stopped there. The README explains that gVisor uses Bazel for builds and dependency management, while a synthetic go branch supports consumers importing selected packages. On our 3-CPU, 8 GB Debian box, the 19-second build result and 4-second go test failure describe different paths and should not be combined into a general quality claim.
Filesystem and network costs decide workload fit
System calls cross extra software layers, and Sentry keeps its own state. The official performance guide separates those structural costs from implementation costs in subsystems such as the network stack. CPU instructions still execute natively, so compute-heavy application code can be a good match. Calls that repeatedly touch files, sockets, or kernel services expose more of the isolation overhead. The production guide identifies file I/O as the most affected area and networking as the next.
We did not benchmark runtime throughput, latency, memory, storage, or networking in this lab run. Its measured scope was a 43-second package install, a 19-second build, and the failed 4-second test command. Any performance number borrowed from another machine would mislead a purchasing decision. Run a representative request mix under both runc and runsc, including cold starts and noisy neighbors, then price the difference against the threat model that motivated sandboxing.
Production installation changes the host runtime
The preferred Debian path installs the runsc package and configures Docker automatically. Manual installation puts runsc, the containerd shim, and a gvisor-bin directory on the host. Those sidecar programs must remain next to the runtime binary. Adding runsc to Docker requires elevated access and a daemon reload; Kubernetes requires a runtime class and container-runtime wiring. Linux 5.6 or newer on x86_64 or ARM64 is the supported base.
Source work is heavier than the successful 19-second build in our Go-oriented harness suggests. The README recommends its build container around Bazel, and direct Bazel use requires a matching version. Production also needs logging, runtime monitoring, upgrade procedures, and an escape hatch for incompatible images. Roll out by workload class. A public code runner and a trusted internal database do not have the same exposure, while sandboxing both can impose cost where little isolation value is gained.
Weekly releases and current commits show active maintenance
GitHub recorded 19,181 stars, 836 open issues and pull requests, and a push on August 28, 2026. Release 20260817.0 was published August 25 with filesystem, networking, GPU, checkpoint, and rootless Podman changes among its listed work. That combination shows active engineering and triage. The combined open count includes pull requests, so it should not be presented as 836 bugs.
For a multi-tenant platform, gVisor offers a meaningful isolation layer while preserving familiar container packaging. Its limits are documented more candidly than many infrastructure projects: Linux compatibility is incomplete, I/O can slow down, and sandboxing does not repair an insecure service design. Our 396-package run built cleanly but never entered tests because of the module-file check. Adopt it only after the exact images and workload paths pass under runsc; that is the price of gaining distance from the host kernel.