ZViz vs gVisor
ZViz denies dangerous syscalls and runs the rest on the host kernel natively; gVisor emulates the syscall ABI inside a userspace kernel (Sentry). ZViz is a single static binary with no daemon and needs Linux 5.13+; gVisor emulates more syscalls, so it supports workloads that need ptrace, mount, or nested containers.
gVisor is a userspace kernel from Google: it emulates the Linux syscall ABI in a Go runtime called Sentry. ZViz uses kernel primitives directly with a strict seccomp filter. Both raise the bar over plain runc; the difference is emulate-vs-deny.
Verdict: Choose ZViz for a smaller reachable syscall surface, native speed, and a no-daemon static binary. Choose gVisor when the workload needs syscalls ZViz blocks (ptrace, mount, unshare) — gVisor emulates them safely.
ZViz strengths
- Allowed syscalls run on the host kernel — no emulation layer
- Single static Zig binary, no daemon or supervisor process
- Small, readable policy: 132 allow / 24 deny / 1 argument-filter
- All 41 capabilities dropped plus a Landlock ruleset by default
gVisor strengths
- → Emulates the syscall ABI, so it supports ptrace, mount, and unshare
- → Runs Docker-in-Docker and Bazel/Nix sandboxed builds
- → Mature, widely deployed (Google Cloud Run, GKE Sandbox)
- → Works on older kernels (does not require Landlock/5.13)
Feature comparison
| Feature | ZViz | gVisor |
|---|---|---|
| Isolation mechanism | Kernel primitives: namespaces + 41 caps dropped + Landlock + seccomp-BPF + cgroups v2 | Userspace kernel (Sentry) emulates the syscall ABI |
| Allowed syscalls execute… | On the host kernel, natively | Inside the Sentry emulation layer |
| Reachable syscall surface | 132 allowed / 24 denied / 1 argument-filtered | A reduced host set reached via Sentry |
| ptrace inside container | Denied (EPERM) | Allowed (emulated) |
| mount / unshare inside container | Denied (EPERM) | Allowed (emulated) |
| Docker-in-Docker | Not supported (needs mount/unshare) | Supported |
| Runtime shape | Single static binary, no daemon | Sentry process supervises the sandbox |
| Implementation language | Zig | Go |
| Kernel minimum | Linux 5.13 (Landlock) | Linux 4.14+ |
| License | Apache 2.0 | Apache 2.0 |
Choose ZViz when
- → You run untrusted code that does not need ptrace/mount/unshare
- → You want the smallest reachable kernel surface, deny not emulate
- → You want a static binary with no daemon and native syscall speed
- → Your hosts run Linux 5.13+ with cgroups v2
Choose gVisor when
- → The workload needs ptrace (strace, debuggers) or mount/unshare
- → You need Docker-in-Docker or Bazel/Nix internal sandboxing
- → You must support older kernels without Landlock
- → You want maximum syscall compatibility for legacy workloads
Frequently Asked Questions
Is ZViz as isolated as gVisor?
They isolate differently. gVisor emulates syscalls in a userspace kernel so the host kernel never runs them; ZViz denies dangerous syscalls at the seccomp boundary and runs the rest on the host kernel. For syscalls ZViz denies outright, exploit code fails immediately. For syscalls it allows, the host kernel path is shared — ZViz assumes the host kernel is trusted.
Can I run ZViz where I run gVisor?
Often, but not always. If your workload needs ptrace, mount, unshare, Docker-in-Docker, or Bazel/Nix internal sandboxing, use gVisor — ZViz blocks those. Otherwise ZViz gives you a smaller surface with no emulation layer.
Why does ZViz need a newer kernel?
ZViz uses the Landlock LSM for unprivileged filesystem access control, which requires Linux 5.13+. gVisor does not depend on Landlock and runs on older kernels.