PandaStack vs gVisor: choosing your isolation boundary

"PandaStack vs gVisor" sounds like a head-to-head, but the honest framing is that these are two different points on the isolation spectrum — and two different things to buy. gVisor is a user-space kernel (the "Sentry") that intercepts a container's syscalls to shrink the host-kernel attack surface; it's an open-source runtime you drop in and operate yourself, and it's what powers GKE Sandbox and Google Cloud Run's container isolation. PandaStack is a managed platform of full Firecracker microVMs — each workload gets a real, separate guest kernel behind a hardware KVM boundary, exposed as an API. This post lays out how each model actually works, where each genuinely wins, and how to choose. I'm Ajay, founder of PandaStack — I'll be specific about PandaStack and fair about gVisor, and I'll flag where you should verify against the gVisor docs rather than take my word for it.

How gVisor works: a user-space kernel

gVisor's core idea is clever and worth understanding before you compare it to anything. A normal container makes syscalls directly to the host Linux kernel — that shared kernel is the attack surface. gVisor inserts itself in between: it runs an application-level kernel called the Sentry, written in Go, that implements a large subset of the Linux syscall interface in user space. The container's syscalls are trapped (via ptrace or a KVM-based platform) and serviced by the Sentry instead of the host kernel. The Sentry, in turn, talks to the host through a deliberately narrow, heavily restricted set of host syscalls protected by seccomp.

The payoff: an attacker inside the container who finds a Linux kernel bug is attacking the Sentry's reimplementation, not the host kernel directly — and the Sentry's own access to the host is tightly constrained. You get a meaningfully smaller host-kernel attack surface without booting a second operating system. Because there's no full guest kernel and no separate guest memory image, the per-sandbox memory overhead is typically lower than a VM's, and startup avoids a guest-kernel boot.

gVisor's honest trade-offs

Two costs come with the user-space-kernel model, and gVisor's own documentation is candid about both — verify the current state there, because the project moves fast and has closed many gaps over the years.

• Syscall compatibility gaps. The Sentry reimplements Linux, not the actual Linux kernel, so it supports a large but incomplete subset of syscalls and their edge-case behaviors. Most workloads run fine, but some applications hit an unimplemented syscall, an unsupported flag, or a behavioral difference (certain niche filesystem, networking, or /proc semantics). When code must see a bit-for-bit-faithful Linux, that's a risk.
• Interception performance cost. Trapping and servicing syscalls in a user-space kernel adds overhead, and the size of that overhead depends heavily on the platform (ptrace vs KVM) and the workload. Syscall-heavy and I/O-heavy workloads feel it most; CPU-bound code feels it least. Check gVisor's own performance guide for current numbers on your workload shape — don't trust a blanket figure.

There's also the operational dimension: gVisor is a runtime you install, configure, keep patched, and run on your own hosts. That's a feature if you want full control, and a cost if you'd rather not operate isolation infrastructure. Hold that thought — it's the biggest practical difference from PandaStack.

How PandaStack works: full microVMs behind a managed API

PandaStack takes the other approach to the attack surface: instead of reimplementing the kernel in user space, it gives each workload a real one. Every PandaStack sandbox, database, and hosted app runs in its own Firecracker microVM — a genuine guest Linux kernel confined by hardware virtualization (KVM). The guest reaches the outside world only through a tiny set of emulated virtio devices. An exploit inside the guest isn't attacking a syscall reimplementation; it's attacking the hypervisor boundary itself, which is a much smaller and more heavily audited surface than the full Linux syscall interface.

Because it's a real kernel, you get full Linux compatibility — the guest is Linux, so there are no syscall gaps to design around. The historical objection to VMs is startup cost, and PandaStack answers that with snapshot-restore: the first spawn of a template does a cold boot (~3s) and captures a snapshot; every subsequent create restores that baked snapshot, patches networking, and resumes. In practice that's a p50 create of ~179ms (p99 ~203ms), with the underlying snapshot restore landing around ~49ms — VM-grade isolation at latencies people associate with containers. There's no warm pool of idle VMs to manage; every create takes the restore fast path.

And critically, PandaStack is a managed API, not a runtime you operate. You call an endpoint (or the SDK), get an isolated machine, and drive it with exec, filesystem, snapshot, fork, and hibernate/wake. You don't install a runtime, tune a platform, or keep a Sentry patched. The core is also Apache-2.0 and self-hostable on your own KVM hosts if you do want to own the data path.

Side by side

• Isolation mechanism — gVisor: a user-space kernel (Sentry) intercepts container syscalls; host kernel is shielded but still the ultimate boundary. PandaStack: a real guest kernel per workload behind a hardware KVM boundary.
• Guest kernel — gVisor: none; the Sentry reimplements a subset of Linux in Go. PandaStack: a full, separate Linux guest kernel per microVM.
• Linux compatibility — gVisor: large but incomplete syscall subset; some apps hit gaps or behavioral differences (verify in gVisor docs). PandaStack: full Linux compatibility because the guest is Linux.
• Performance profile — gVisor: lower memory overhead, but syscall/I/O interception adds cost that varies by platform and workload. PandaStack: a few MB of guest overhead, no syscall interception tax; create p50 ~179ms via snapshot-restore.
• What it is — gVisor: an open-source runtime you self-operate (drop into containerd/Docker). PandaStack: a managed API/platform (also Apache-2.0 and self-hostable).
• Statefulness — gVisor: a container runtime; state and lifecycle are yours to manage. PandaStack: stateful machines you can snapshot, fork (same-host 400–750ms, cross-host 1.2–3.5s), and hibernate/wake.
• Surrounding platform — gVisor: isolation only; you bring the rest. PandaStack: managed Postgres 16, durable volumes, git-driven app hosting, preview URLs.
• Best fit — gVisor: you already run a container platform and want to harden it in place with control. PandaStack: you want VM-grade isolation and a sandbox/app/db platform as an API without operating it.

Where gVisor wins

Be honest with yourself about your starting point. If you already operate a Kubernetes or containerd platform and your security ask is "reduce host-kernel exposure for these workloads without re-architecting," gVisor is an excellent fit. You add a runtime class and route the risky pods to it — no new control plane, no new API to integrate. If your workloads are CPU-bound and syscall-light, the interception overhead is minimal and you keep container ergonomics and density. And because it's open source and runs on your hardware, you get full control with no managed-service dependency. gVisor is the right tool when the job is hardening containers you already run.

Where PandaStack wins

Reach for PandaStack when the strongest practical boundary and full Linux fidelity matter more than reusing your container stack — and when you'd rather consume isolation than operate it.

• Untrusted or AI-generated code where you want a hardware boundary and a separate guest kernel per task, not a shielded shared kernel.
• Workloads that need faithful Linux behavior — anything that might trip a syscall reimplementation runs unchanged in a real guest kernel.
• Stateful agent loops: snapshot a setup once, fork it cheaply (same-host 400–750ms) to explore branches, hibernate/wake for scale-to-zero.
• You want the whole platform, not just isolation: managed PostgreSQL 16, durable volumes, and git-driven app hosting to ship what an agent builds.
• You'd rather call an API than install, tune, and patch an isolation runtime — while keeping the option to self-host the Apache-2.0 core on your own KVM hosts.

What each looks like in practice

Here's gVisor's posture: it slots in as a container runtime. Once runsc is installed and registered with your container engine, you opt a workload into it — for example with Docker:

# Run an untrusted container under the gVisor (runsc) runtime.
# Syscalls are serviced by the Sentry, not the host kernel directly.
docker run --rm --runtime=runsc \
  python:3.12-slim \
  python -c "import sys; print(sys.version)"

And here's PandaStack: you don't install a runtime, you call an API. The Python SDK reads PANDASTACK_API_KEY from the environment and talks to https://api.pandastack.ai. Create a microVM, exec code an agent generated, then tear it down:

from pandastack import Sandbox

# Spin up an isolated Firecracker microVM (real guest kernel, KVM boundary).
# p50 create ~179ms via snapshot-restore — no runtime to operate.
sbx = Sandbox.create(template="code-interpreter", ttl_seconds=300)

try:
    # Execute code the agent wrote — confined to this VM's own kernel.
    result = sbx.exec("python -c 'import sys; print(sys.version)'")
    print(result.stdout, result.exit_code)
finally:
    sbx.kill()

Notice the shape of each. With gVisor you're operating a runtime and reasoning about which pods get the hardened class. With PandaStack you're operating nothing — you ask for a machine and get one, with the isolation already decided for you at the hardware boundary.

How to choose

The decision usually collapses to two questions. First: do you want to harden a container platform you already run, or consume isolation as a service? If the former, gVisor is a natural, low-friction win. If the latter, PandaStack hands you the boundary and the lifecycle without operational burden. Second: how much do you care about full Linux fidelity and the strength of the boundary? A real guest kernel behind KVM is the stronger, more compatible boundary; a user-space kernel is a lighter, in-place improvement to a shared kernel. Neither answer is universally right — they're different tools for different starting points.

It's also not strictly either/or. Plenty of teams run gVisor to harden their general container fleet and reach for PandaStack specifically for the per-task, untrusted, AI-generated workloads where they want a separate kernel and stateful snapshot/fork. Match each workload to the boundary whose trade-offs fit it — and for the current state of gVisor's compatibility and performance, always check the gVisor docs rather than a blog's snapshot in time.