WASM Architecture
WASM sandboxes use a host-mediated model: the API server stays in sandboxd, while each sandbox runs inside a dedicated worker subprocess speaking IPC over a Unix socket.
Components
Section titled “Components”sandboxd (service layer) └─ internal/runtime/wasm.Driver ├─ pkg/wasmmod resolver (module cache) ├─ pkg/wasm/worker supervisor └─ toolbox reverse proxy (files / exec)Checkpoint format
Section titled “Checkpoint format”Passivation writes a mem.snap directory:
config.json— engine metadata, clone generation, module digestmemory.zstd,globals.cbor,wasi-state.cbor— guest state
Durable sandboxes push the directory to AOCR at:
cluster/<cluster-id>/wasm-checkpoints/<sandbox-id>:latest
Lifecycle
Section titled “Lifecycle”- Create — resolve module, start or acquire warm worker, instantiate, invoke entrypoint.
- Passivate — checkpoint live guest, stop worker, release admission.
- Rehydrate — restore from local
mem.snap(pull from AOCR first when durable and missing). - Failover — cluster owner calls
RecreateSandbox; durable WASM pulls checkpoint then rehydrates.
Configuration
Section titled “Configuration”| Variable | Purpose |
|---|---|
SB_ENABLE_WASM | Master gate |
SB_WASM_MODULES_DIR | Module + checkpoint cache root |
SB_WASM_CHECKPOINT_INTERVAL | Optional periodic boundary checkpoint |
SB_WASM_DURABLE_PUSH_INTERVAL | Retry AOCR push for durable rows |
SB_SNAPSHOT_PUSH_ENABLED | Enables AOCR push/pull credentials |
Operations
Section titled “Operations”See the WASM runtime health runbook for failure modes and log signatures.