Skip to content
sandbox-workers
Esc
↑↓navigate↵open⌘Jpreview
On this page

Concepts

How sandbox-workers is structured, why it's designed this way, and what you need to understand to use it safely.

These pages explain how sandbox-workers works under the hood: the split between the gateway, the runtime Workers, and the Wasm engines; how sandboxes and code contexts persist state; how each language is isolated; and what security responsibilities stay with the caller.

  • Architecture - How the caller Worker, runtime Workers, and Wasm engines fit together
  • Sandbox lifecycle - Creation, persistence, idle expiry, and destruction
  • Code contexts - Durable REPLs and the memory-snapshot mechanism behind them
  • Runtime engines - How each language’s Wasm engine is instrumented, capped, and isolated
  • Security model - Isolation guarantees and what the caller must still implement
  • Stateless mode - Task-oriented instructions for one-shot execution
  • Stateful mode - Task-oriented instructions for code contexts and the shared workspace
  • API reference - Method signatures and the HTTP contract
  • Configuration - wrangler.jsonc bindings and environment variables