Runtime Selection

Choosing between WebAssembly, gVisor, and Kata — what each isolation boundary costs and when to pay for it.

Runtime Selection

The sandbox offers three isolation runtimes. They trade the same three things against each other: how strong the boundary is, how fast a sandbox starts, and how much of Linux the workload gets.

If you don’t choose, you get gVisor. It is the right default for agentic workloads — real Linux compatibility with a syscall boundary, at low startup cost. Read on only if your workload is unusually short, unusually hostile, or unusually compliance-bound.

At a glance

	WebAssembly	gVisor	Kata Containers
Boundary	Wasm VM (no OS)	User-space kernel intercepts syscalls	Hardware VM
Shares host kernel	No kernel at all	Yes, via interception	No
Startup	Milliseconds	Fast	Slowest
Density per node	Thousands	High	Lowest
Linux compatibility	WASI subset only	Feels like Linux	Full
Cost	Lowest	Low	Highest
Runtime name	wasmedge, spin	runsc	kata-qemu, kata-fc

Choosing

Untrusted third-party binary, needs root, or VM isolation required for compliance?
  └── yes ──▶ Kata Containers

Pure compute, sub-second, already compiles to .wasm?
  └── yes ──▶ WebAssembly

Otherwise ─────▶ gVisor   (default)

WebAssembly

Code runs in a lightweight stack-based virtual machine rather than a container — there is no OS to boot, which is where the millisecond startup comes from.

Use it for ultra-short tasks (under a second), pure logic and compute — validating a JSON schema, evaluating an expression, a numeric transform — and for scale where startup time dominates total execution time.

The cost: WASI only. No full Linux syscall surface, no arbitrary processes, no git or npm. Your workload must be compiled to .wasm, or run inside a Wasm-compiled interpreter (Python or JS in Wasm), which is a real build-pipeline commitment.

gVisor

A user-space kernel — the “Sentry” — intercepts syscalls, so the container never talks directly to the host kernel. Startup is fast and memory overhead is low, while bash, the filesystem, and compilers all behave normally.

Use it for standard CLI coding agents, workloads that need ordinary Linux tooling (git, curl, grep, npm), MCP-connected toolchains, and any “do work → write files → exit” flow.

gVisor is a strong sandbox but it still shares the host kernel, reached through interception rather than directly. Kata’s VM boundary is a categorically different guarantee. If your threat model includes a determined attacker with a kernel exploit, gVisor is not the answer.

The cost: some syscalls are emulated or restricted. Workloads that probe unusual kernel interfaces can behave differently than on bare Linux.

Kata Containers

Each container runs inside its own lightweight VM using hardware virtualization. No shared kernel — the strongest boundary available.

Use it for high-risk untrusted customer binaries, workloads that need root and might attempt to escape a container, and compliance regimes that specifically require VM-level isolation.

The cost: higher startup latency, more memory and CPU per sandbox, lower density. You are trading velocity and money for a boundary you may not need.

The tiered model

Rather than standardising on one runtime, route by workload class:

Class	Runtime	Rationale
Ultra-fast compute	WebAssembly (WasmEdge / Spin)	Startup dominates; massive scale for simple tasks
General-purpose agentic	gVisor (runsc)	Developer-friendly compatibility, low overhead
High-security zone	Kata (kata-qemu / kata-fc)	Hardened isolation for hostile code

Pick per workload, not per platform. A single deployment can run all three: Wasm for a validation function, gVisor for the coding agent that calls it, Kata for the one customer whose contract requires VM isolation.

Related

• Sandboxes — what the sandbox is for
• Architecture — how the runtimes are wired in
• Security Guide — the full threat model
• Production Guide