gVisor vs Docker: is gVisor safer than a container?
gVisor runs a container on a user-space kernel that answers its system calls, so they never go straight to the host kernel as in Docker.
Runtime goes one step further for agent code: a Firecracker microVM with its own Linux kernel for every sandbox. A new Runtime sandbox ran its first Python command 351 ms after the create request at the median, measured over the public internet on 24 September 2026 (speed), and Docker runs inside it.
Not either-or: gVisor runs under Docker
Docker is the tooling: images, the daemon, docker run. What isolates the
container is the runtime underneath. With the default runtime, the container is
a process on the host's kernel, and every container on the machine shares that
kernel. gVisor ships an OCI runtime, runsc, that Docker can use instead:
Terminalsudo runsc installdocker run --runtime=runsc --rm hello-worldThose are the commands from gVisor's Docker quick start. The image, the command and the workflow stay the same; the kernel the container talks to changes.
How Docker's default isolation works
Docker fences a container with features of the host kernel:
- Namespaces, "the first and most straightforward form of isolation."
- Control groups for "resource accounting and limiting."
- A restricted set of capabilities, so root in the container is not full root.
- A default seccomp profile that "disables around 44 system calls out of 300+."
- AppArmor or SELinux, optionally, and user namespaces, which map root in the container to an unprivileged user outside once enabled on the daemon.
The container still makes its remaining system calls straight into the host kernel.
How gVisor changes that
gVisor's Sentry "intercepts application system calls and acts as the guest kernel." It is written in Go, runs in user space, and itself uses only "a minimal set of host system calls." A Gofer process mediates file access. The project's principle is that "no system call is passed through directly to the host."
Side by side
| Docker, default runtime | Docker with gVisor (runsc) | |
|---|---|---|
| Isolation boundary | Namespaces, cgroups, capabilities, seccomp | A user-space application kernel, the Sentry |
| Kernel the code talks to | The host's, shared by every container | The Sentry, which implements a Linux-like interface |
| Attack surface to host | Host system calls, minus about 44 blocked by default | The Sentry's minimal, enumerated set of host calls |
| Start time | No figure published | No single figure published; gVisor says Docker is most of it |
| Memory overhead | No figure published | "A small, mostly fixed amount of memory", per the project |
| Compatibility | The host kernel's ABI, minus the calls seccomp blocks | "A subset of the Linux syscall ABI"; KVM inside not supported |
| Performance cost | No extra kernel layer | "Higher per-system call overhead", per the project |
| Who uses it | Container workloads; Daytona's sandboxes by default | GKE Sandbox, Cloud Run, App Engine; Modal |
Is gVisor safer than a container?
It narrows the path to the host. A plain container reaches the host kernel through every system call its seccomp profile allows. Under gVisor, the program's calls land in the Sentry, and only the Sentry's own short list reaches the host. A kernel bug the code goes after is then a bug in gVisor's kernel, not in the one every tenant shares.
The price is compatibility and speed on system-call-heavy work. gVisor says it "only implements a subset of the Linux syscall ABI", that io_uring is disabled by default, and that "usage of KVM from within the sandbox is not supported." Its releases run the regression tests of Python, Java, Node.js, PHP and Go.
When each fits
- Default Docker for your own code, CI and services you trust.
- Docker with gVisor when you run less trusted containers on Kubernetes or Docker and want a stronger boundary without managing virtual machines.
- A microVM when the code is untrusted and needs a complete Linux kernel of its own. See Firecracker vs gVisor.
Why Runtime chose a microVM instead
Agents run code nobody reviewed and install whatever a task needs.
Runtime gives each sandbox its own Linux kernel in a Firecracker microVM, so
there is no shared kernel and no reduced system-call interface. Ubuntu 24.04,
Python 3.12, Node.js 24, Bun, git and gcc are ready, sudo works, and the host
still enforces network rules, CPU, memory and cost from outside the guest
(security). Docker itself runs inside:
TypeScriptimport { Sandbox } from "withruntime";await using sbx = await Sandbox.create({ diskMiB: 8192 });await sbx.exec("sudo enable-docker", { check: true, timeoutMs: 300_000 });const run = await sbx.exec("docker run --rm hello-world", { timeoutMs: 300_000 });console.log(run.stdout);Pythonfrom withruntime import Sandboxwith Sandbox.create(disk_mib=8192) as sbx: sbx.exec("sudo enable-docker", check=True, timeout_ms=300_000) run = sbx.exec("docker run --rm hello-world", timeout_ms=300_000) print(run.stdout)New accounts get 50 free sandbox hours, no card.
More: what is gVisor?, microVM vs container, run Docker in a sandbox, Runtime vs Modal.
Sources
Checked 25 September 2026.
- gVisor documentation, Docker quick start, compatibility, security model, performance, users
- Docker Engine security, seccomp profiles, user namespaces, what is a container?
- Provider isolation from Runtime's comparisons, checked 23 September 2026: Modal, Daytona
Facts on this page were checked on 25 September 2026.