Skip to content
Home

Sandbox Lifecycle

A sandbox moves through creation, readiness, runtime operation, and cleanup. Use the SDK object returned by create/connect as the boundary for all runtime work.

create -> starting -> running -> pause/connect or refresh -> delete
ActionUse it when
createAllocate a runtime. If no template is specified, the default is base.
waitReadyThe next line needs files, commands, or ports to be available immediately.
connectRecover runtime URL/token for an existing sandbox ID.
pauseStop runtime resources while keeping metadata for a later connect flow.
refreshExtend TTL for active work.
setTimeoutChange lifecycle timeout in seconds.
deletePermanently clean up disposable work.

API responses expose a small set of public states. Intermediate creation and cleanup phases are collapsed before they reach public clients.

State/statusMeaning
startingRuntime is creating or waiting for a healthy heartbeat.
runningRuntime APIs are usable.
pausedRuntime is stopped, but durable metadata remains for connect/resume.
deletedSandbox has been removed.
failed / errorRuntime failed to become usable or a lifecycle operation failed.

Sandbox detail, list, and create responses may include timeline and diagnostic. Use those fields for user-facing progress and troubleshooting instead of parsing log text.

Readiness is based on the runtime health heartbeat. A sandbox should be treated as usable after the API reports running or the SDK waitReady call resolves.

Create, detail, and list responses use the same public field meanings. Resource fields such as memoryMB, lifecycle timestamps such as startedAt, and expiration fields such as endAt should be displayed from the API response without substituting unrelated update timestamps.

OptionUnitPurpose
templateIDstringOptional template reference; omitted or empty uses base.
timeoutsecondsSandbox lifecycle TTL.
waitReadybooleanWait for usable runtime state.
envVarsmapRuntime environment overrides.
metadatamapUser metadata for search and debugging.
autoPausebooleanWhen supported, timeout maps to pause instead of kill.
autoResumebooleanAllow router-triggered resume for paused sandboxes when supported.
networkobjectPublic preview and egress policy, including allowPublicTraffic, allowInternetAccess, allowOut, and denyOut.
volumeMountsarrayOptional request-level mounts using camelCase only.

Do not send removed create/lifecycle compatibility fields such as timeoutMs, secure, mcp, or snake_case volume_mounts. They are rejected instead of silently ignored. Sandbox lifecycle timeout is seconds; runtime command timeoutMs remains supported and is milliseconds.

const sandbox = await Sandbox.create("base", {
timeout: 1800,
waitReady: true,
envVars: { FOO: "bar" },
metadata: { purpose: "demo" },
});
const sandboxId = sandbox.sandboxId;
await sandbox.connect({ timeout: 1800 });
// Or from a different process:
const reconnected = await Sandbox.connect(sandboxId, { timeout: 1800 });
await sandbox.setTimeout(3600);
await sandbox.refresh();
await sandbox.pause();
await sandbox.delete();
MethodPathPurpose
POST/sandboxesCreate a sandbox.
GET/sandboxes/:sandboxIDFetch detail and runtime connection data.
POST/sandboxes/:sandboxID/connectReconnect and refresh runtime access.
POST/sandboxes/:sandboxID/pausePause runtime.
POST/sandboxes/:sandboxID/refreshesRefresh TTL.
POST/sandboxes/:sandboxID/timeoutChange timeout in seconds.
DELETE/sandboxes/:sandboxIDDelete sandbox.
SignalRouteUse it for
Sandbox detailGET /sandboxes/:sandboxIDState, runtime access fields, lifecycle timestamps, timeline, and diagnostic.
Sandbox logsGET /sandboxes/:sandboxID/logsStartup output, readiness failures, application logs, and image pull issues.
Sandbox metricsGET /sandboxes/:sandboxID/metricsCurrent CPU, memory, disk, network, and task counters.
Observability summaryGET /observability/summaryUser/project usage, quota checks, endpoint availability, and suggested next actions.