> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stateset.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 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**.

<Note>
  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.
</Note>

## 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.

<Warning>
  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.
</Warning>

**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               |

<Tip>
  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.
</Tip>

## Related

* [Sandboxes](/stateset-sandbox/stateset-sandboxes) — what the sandbox is for
* [Architecture](/stateset-sandbox/stateset-sandbox-architecture) — how the runtimes are wired in
* [Security Guide](/stateset-sandbox/stateset-sandbox-security-guide) — the full threat model
* [Production Guide](/stateset-sandbox/stateset-sandbox-production-guide)