google/gvisor

gVisor is worth considering when you already run containers for code you don't fully trust and want to reduce what a single kernel vulnerability exposes. It is not a drop-in performance win, and the setup cost is real.

The problem

A team packs an application into a container, hands it to Docker or Kubernetes, and assumes the container boundary is a security boundary. It is not: because containers share the host kernel, a kernel bug reached through the container's syscalls can compromise the node. The team wants to keep OCI tooling and image workflows but remove that shared-kernel path. With gVisor, the container's syscalls are served by runsc, which intercepts them and implements a Linux-like interface in a Go user-space kernel, so the application gets normal syscall behavior while the host kernel surface it can reach is reduced. The result is a container that still works with existing tooling but no longer runs directly on the host's own kernel.

What's different

The mechanism is an application kernel rather than a filter or a VM. runsc is an OCI runtime, so it plugs into Docker and Kubernetes and works with existing images; the documentation explicitly contrasts it with syscall filtering (seccomp-bpf), isolation wrappers such as firejail or AppArmor, and full VMs such as VirtualBox or QEMU project README. The claimed advantage is VM-like isolation with a smaller resource footprint and faster startup than a VM — an author's claim, not a benchmark result in the supplied material.

The most important trade-off is that this is a reimplementation of Linux interfaces, not Linux itself. Applications that depend on unusual syscalls, kernel-specific behavior or deep host integration are the ones most likely to notice the gap; that compatibility surface is the thing to test against your own workload. It also adds an operational layer between the container and the host: runsc and its sidecar binaries must be built and kept in place together, and the project's own instructions warn that runsc builds from the go branch are not supported project README.

Who should try it

Good fit: a platform team running multi-tenant or user-supplied containers, where a container escape is the threat being managed and the workloads are ordinary Linux services. The runtime's existing OCI integration means they can try it on a subset of workloads without rebuilding images.

Poor fit: a team that only needs to run its own trusted first-party services and cares mainly about raw syscall throughput, since the extra user-space kernel is the wrong tax for that case. Also a poor fit for anyone who cannot tolerate per-workload compatibility testing. gVisor is not a replacement for controlling what data and credentials are mounted into a container; the README says as much.

Requirements and limitations

Building from source targets Linux 5.6+ and Docker 17.09.0 or newer, with x86_64 and ARM64 supported; other architectures may come later project README. Builds are Bazel-based; the Docker build container is the intended path, and direct Bazel use is possible but not recommended. There is a go branch for importing subpackages such as userspace networking, but it is best-effort and not a supported way to build runsc.

Ongoing care matters more than the first build: keep runsc and its sidecar binaries installed together, and confirm that the syscalls and kernel behaviors your workloads rely on work under the application kernel before moving production traffic. Check release notes and the compatibility documentation for changes that affect your stack release documentation; the project also has its own security policy security policy.

HotRepo's take

HotRepo's coverage is thin: one monthly Go board observation, #13 with +409 stars on 2026-10-27. There is no comparable daily history, so persistence of interest cannot be judged from this data. On 2024-01-04 a commenter said they had used gVisor in production for customer workloads for about a year and a half and it was working well HN comment — one report, not consensus. The decision to verify is the syscall-compatibility list for your specific images, not the star count.