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

# Sandbox Runtime Selection

> Choosing a sandbox runtime and how selection behaves.

# Runtime Selection Guide: Kata vs gVisor vs WebAssembly

## Context

We run ephemeral, agentic workloads (CLI coding agents, MCP servers, short-lived containers that produce artifacts and exit). We care about isolation, startup latency, and cost.

## WebAssembly (Wasm)

* Runs code in a lightweight, stack-based virtual machine, not a full OS container.
* **Fastest startup** (milliseconds).
* **Highest density** (thousands of sandboxes per node).
* Requires applications to be compiled to `.wasm` (WASI) or use a Wasm-compiled interpreter (e.g., Python/JS in Wasm).
* Best for: Pure compute tasks, language-specific snippets, serverless-style functions.
* Tradeoff: Limited system access (WASI only, no full Linux kernel/syscalls), requires specialized build artifacts.

## gVisor

* User-space kernel ("Sentry") intercepts syscalls.
* Containers do not talk directly to the host kernel.
* Fast startup, low memory overhead.
* **Feels like Linux** (bash, FS, compilers work well).
* Some syscalls are emulated or restricted.
* Tradeoff: Strong sandbox, but technically shares the host kernel (via interception). Optimized for general-purpose compatibility.

## Kata Containers

* Containers run inside lightweight VMs (hardware virtualization).
* **Strongest isolation** (VM boundary, no shared kernel).
* Higher startup latency and resource overhead.
* Best for untrusted customer code, regulated workloads, or strict multi-tenancy.
* Tradeoff: Maximum security, lower velocity, and higher cost.

## Recommendation

**1. Use WebAssembly (Wasm) for:**

* Ultra-short-lived tasks (\< 1s execution).
* Pure logic/compute functions (e.g., "Verify this JSON schema", "Calculate this fibonacci").
* Massive scale where startup time dominates total duration.

**2. Use gVisor (Default) for:**

* Standard CLI coding agents (Claude Code, Codex).
* Workloads needing standard Linux tools (git, curl, grep, npm).
* MCP-connected toolchains.
* "Do work -> write files -> exit" workflows.

**3. Use Kata Containers for:**

* High-risk, untrusted customer-supplied binaries.
* Workloads requiring root privileges that might escape a container.
* Compliance-heavy environments requiring VM isolation.

## Proposed Model

* **Ultra-Fast / Compute:** WebAssembly (WasmEdge/Spin)
* **General Purpose / Agentic:** gVisor (runsc)
* **High Security:** Kata Containers (kata-qemu/kata-fc)

## Outcome

* Tiered runtime strategy balancing speed, compatibility, and security.
* massive scale for simple tasks (Wasm).
* Developer-friendly compatibility for agents (gVisor).
* Hardened security for high-risk zones (Kata).