Skip to main content
Follow sandbox lifecycle states as you create a machine, wait for readiness, run work, then pause or delete it. Inspect durable state when a request is pending or its response is uncertain.

​
Create and inspect

Use the returned machine ID in place of ID. Creation reserves admission and funding before dispatch. A successful ready response means the guest acknowledged readiness; an application’s own HTTP server can still be initializing. Lists include running and paused machines. For another page, pass the returned cursor to bead list --cursor CURSOR.

​
Connect and run

Use exec, file transfer, or application forwarding. Funded persistent machines can resume on access. For explicit control:
A lifecycle request and its final state are separate. Wait for the expected running or paused state before relying on it. See machine lifetime.

​
Recover uncertain operations

Retain an idempotency UUID before a lifecycle mutation. Use --idempotency-key UUID to preserve the request’s identity when retrying the same request. If a capture failed, inspect preservation: its message, operation ID, recovery state, and next action describe whether to wait or resume/delete the source. Repeated mutation attempts do not replace this inspection.

​
Delete

If deletion returns an operation ID, inspect it through GET /operations/{id} until cleanup is acknowledged. Save required files or a snapshot before deleting. Deleting a volume-mounted machine releases the attachment after lifecycle cleanup; the volume has its own retention. Read snapshots, volumes, and limits.