Code-execution platforms
Notebook services, online REPLs, and snippet runners execute code from anyone on the internet. ZViz gives each submission a hardened container on the host kernel — small surface, native speed, no daemon — so you can run many executions cheaply without trusting any of them.
The problem
A code-execution platform runs code submitted by strangers: a coding-interview sandbox, a documentation “try it” button, an online REPL, a notebook backend. Every submission is untrusted, and you may run thousands per hour. You need isolation that is both strong and cheap per execution.
How ZViz helps
ZViz is OCI-compatible, so you can package your language runtime once as a rootfs and run any submission against it. Each execution gets the full enforcement stack — namespaces, zero capabilities, Landlock, selective-denial seccomp, and cgroups v2 — with:
- No guest kernel to boot or maintain (unlike a MicroVM).
- No daemon — one static binary, spawned per execution and discarded.
- cgroups v2 limits so runaway code hits a memory or PID cap, not the host.
The result is a small, fast, hardened boundary you can afford to stand up per submission.
When to reach for something else
Submissions that need to build nested containers, run debuggers, or mount filesystems inside the sandbox
belong on gVisor. For the common case — run this snippet, capture stdout, tear it
down — ZViz keeps the surface small and the cost low. See the quickstart to wire it in.
Frequently Asked Questions
Can ZViz keep per-execution cost low?
ZViz runs on bare kernel primitives with no guest kernel and no daemon, so it avoids the guest-kernel footprint of a MicroVM. For a strict syscall policy that contains the workload, that is a smaller per-execution cost.
How do I stop a snippet from eating all the memory?
cgroups v2 limits cap memory, PIDs, and CPU per container. A fork bomb or memory hog hits the cap instead of the host.
Related
AI agent code execution
Run LLM-generated code inside ZViz so a prompt injection fails at the kernel boundary, not in production.
Use caseCI sandboxing
Run builds on opaque dependency trees with a smaller kernel attack surface than plain runc.
Use casePer-request ephemeral isolation
Spin up a fresh sandbox per request and tear it down, with no daemon in the way.