Sandboxes
A Sandbox is a mutable Firecracker microVM that boots warm in ~150 ms from a versioned template snapshot. Your agent writes files into it, executes commands, exposes ports as live preview URLs, and snapshots state for branching or rollback. When the work is done you destroy it — or publish it to a production deployment.
What a Sandbox is — concretely
- A Firecracker microVM (not a container, not a VM in the usual cloud sense)
- 1 vCPU, 1 GiB RAM, 3 GiB disk by default — configurable up to 8 vCPU, 8 GiB RAM, 10 GiB disk
/workspaceis the editable filesystem root- Boots from a versioned template (
miosa-sandboxby default; see Templates) - Auto-destroyed after
timeout_secof wall-clock time (default 300 s; setalways_on=Trueto disable) - Network-isolated by default; preview URLs open specific ports to the internet
Lifecycle
| State | Meaning |
|---|---|
provisioning | VM is booting from the template snapshot |
running | Ready — exec, files, previews all work |
paused | Snapshotted; resume() restores full state in ~200 ms |
destroyed | Terminal — resources freed, ID unusable |
error | Boot or runtime failure; check sbx.data["metadata"] for last_error |
Activity that resets the idle clock: exec calls, file writes, preview HTTP traffic, terminal stdin. Once timeout_sec elapses with no activity the sandbox transitions directly to destroyed.
Create a sandbox
The response body contains id, state, template_id, cpu_count, memory_mb, boot_ms, boot_path, and created_at. Save the id — every subsequent call needs it.
Context manager (auto-destroy)
The Python SDK supports with / async with — the sandbox is destroyed on exit even if an exception is raised:
Connect to an existing sandbox
Run a command — exec
exec.run blocks until the process exits and returns stdout, stderr, exit_code, and duration_ms.
Stream stdout/stderr in real time
exec.stream returns an iterator of SSE events. Use this for long commands (builds, test runs, installs) where you want to surface output progressively.
Files — write, read, list, stat
All file paths are absolute. Parent directories are created automatically on write. File content is base64-encoded over the wire.
Filesystem layout
| Path | Purpose |
|---|---|
/workspace | Agent working directory — write all app code here |
/home/sandbox | User home |
/tmp | Scratch space — cleared on destroy |
/opt/venv | Pre-installed Python virtualenv (miosa-sandbox, python templates) |
/usr/local/bin | System binaries |
Previews — expose a port
previews.create maps a sandbox port to a public HTTPS URL managed by MIOSA. The URL is live as long as the sandbox is running.
See Previews for visibility controls, custom domains, and embedding.
Snapshots — save and fork state
A snapshot freezes the entire VM state (memory + disk). You can restore the same sandbox to an earlier state, or create a branch by restoring into a new sandbox.
Pause and resume
pause() and resume() give you explicit control over the running ↔ paused transition without destroying state.
Environment variables
Env vars set at create time are injected into the VM at boot and visible to all processes. They are read-only once the sandbox is running; env.list() returns the live set.
Subscribe to sandbox events
The events.stream() endpoint emits lifecycle and activity SSE events for a sandbox — useful for monitoring agent runs.
List and filter sandboxes
Sizing reference
| Field | Default | Validation range |
|---|---|---|
cpu_count | 1 | 1–8 |
memory_mb | 1024 | 1–8192 |
disk_size_mb | 3072 | 1–10240 |
timeout_sec | 300 | 1–86400 |
idle_timeout_sec | 0 (disabled) | 0–86400 |
always_on | false | — |
Set always_on=True to disable timeout_sec enforcement entirely. Useful for long-lived development environments or hosted IDEs. Set idle_timeout_sec to auto-destroy after a period of inactivity rather than a fixed wall-clock limit.
Custom templates
Build a custom template when you need a reproducible base image with dependencies pre-installed — reduces every sandbox cold-start by eliminating the install step.
See Templates for the full BuildSpec reference, available base images, and template versioning.
Production checklist
Before relying on sandboxes in production:
- Set an explicit
timeout_sec. The default is 300 s. An agent loop that hangs without one will keep billing until the plan-max (up to 86400 s). - Set
idle_timeout_secfor user-facing dev environments so abandoned sessions clean themselves up. - Pass
idempotency_keyonsandboxes.createcalls in agent retry loops. The platform deduplicates creates with the same key within a 24-hour window. - Use templates instead of installing dependencies inside every sandbox. A
pnpm installthat takes 45 s becomes a 150 ms warm boot. - Snapshot before destructive operations. Restore is ~200 ms; re-running an install is not.
- Subscribe to
sbx.events.stream()to detect unexpected exits and trigger retries. - Never store long-lived secrets in
env— pass them per-exec or use the Secrets API. - Filter by
external_workspace_idin your list calls to avoid scanning your entire tenant’s sandbox set.
Billing notes
Billing accrues from state = "running" until state = "destroyed" or state = "paused".
- Running: billed at the vCPU-second + GiB-second rate for your plan
- Paused: billed at storage rate only (disk GiB-second)
- Destroyed: billing stops immediately
Templates cached on every region — picking a built-in template incurs no boot-delay penalty.
See also
Full filesystem and process API — recursive operations, watch, detached jobs.
Live HTTPS URLs proxied to a sandbox port with share tokens and visibility controls.
Built-in images and custom BuildSpec reference.
Raw REST reference for snapshot create, list, restore, delete.