Sandbox runtime selection

Choose an admitted container, gVisor, MicroVM, or Kata runtime using actual controller mappings and verified cluster capabilities.

The reviewed Node controller accepts container, gvisor, microvm, and kata. A runtime label alone does not prove that its node runtime works or that a workload received hardware isolation. Inspect the actual pod and perform the deployment’s isolation tests.

Runtime mapping

Request	Source mapping	Boundary to qualify
container	No additional request-specific RuntimeClass; deployment fallback still applies	Namespaces/cgroups and the effective pod runtime
gvisor	gvisor	gVisor application-kernel boundary on compatible nodes
microvm	firecracker, overridable with MICROVM_RUNTIME_CLASS	Working hardware-virtualized runtime and placement
kata	kata-qemu, overridable with KATA_RUNTIME_CLASS	Working Kata VM runtime and placement

The default comes from SANDBOX_RUNTIME_CLASS or RUNTIME_CLASS. With neither set, production defaults to gvisor; development has no RuntimeClass default. Explicit none disables that default. Requests resolve their supported mapping and deployment fallback; ALLOWED_ISOLATION_LEVELS can refuse an otherwise recognized tier.

Earlier docs described isolation as only a warm-pool label and claimed WebAssembly was available. The current create path resolves the requested runtime before allocating the pod. The policy explicitly rejects Wasm because no WASI runtime is wired into this controller.

Request and verify

{
  "isolation": "gvisor",
  "cpus": "1",
  "memory": "1Gi",
  "timeout_seconds": 600
}

Send this only to a deployment that admits the selected tier. Startup can fail if the RuntimeClass or its underlying node support is unavailable. ISOLATION_ENFORCEMENT=required checks configured RuntimeClass existence before serving traffic; warn/off modes have weaker startup enforcement. Existence is a precondition, not a running-workload attestation.

Warm-pool eligibility includes isolation and resource profile. Persistent/durable workspaces cold-start instead of claiming ephemeral warm pods. GPU requests have additional runtime, resource, and placement restrictions; a generic model/image choice does not establish GPU fit.

Choose by workload requirements

For ordinary code and tools, qualify an admitted Linux runtime and its syscall/tooling compatibility. For workloads requiring a VM boundary, qualify Kata/MicroVM nodes and a negative isolation test before use. Keep network policy, credentials, pod privileges, and resource limits in scope whichever runtime is selected.

No startup latency, density, exploit-resistance certification, or regulatory compliance follows from the runtime name. Local Docker workbench execution is a separate developer backend and does not provide the hosted Kubernetes/VM boundary.

Source: controller/src/isolation-policy.ts, config/loader.ts, and sandbox-manager/create.ts, checked October 20, 2026. Continue with security controls or self-host setup.