Borealis Docs

Sandbox lifecycle

Treat lifecycle operations as requests whose progress you observe, rather than assuming a successful response means the host has finished.

Configure an environment

Creation combines a name, image, startup command, resources, and placement. Optional settings include environment variables, exposed ports, workspace configuration, and a source snapshot.

Choose a command that stays alive when you want a persistent development session. A container whose main process exits will not remain available for interactive work.

Follow the state

After creating a sandbox, keep its ID and inspect the detail view or sandbox get response. Wait for running status before opening terminals or starting executions. A sandbox may need to download an image or wait for host capacity.

Start and stop can also take time. Refresh the resource after requesting a transition. Avoid issuing conflicting lifecycle actions while a transition is in progress.

Stop and start

Stopping ends the container’s processes and releases running compute according to the billing model. Starting an existing sandbox is different from creating a new one.

Do not rely on process memory surviving a stop. Services need to start again, and host-local data alone is not a disaster recovery strategy. Use snapshots and workspace transfers for the state you need to preserve.

The idle timeout controls inactivity handling. Review it when setting up long jobs, and monitor the actual execution and sandbox state rather than assuming an idle policy guarantees a particular job duration.

Delete deliberately

Deleting is destructive. Export important files first, check the sandbox ID and organisation, then confirm the operation. Cleanup can remain pending after the request is accepted.

A timeout does not prove that deletion failed. Query the resource again before retrying. For creation retries, keep the original idempotency key so that an uncertain response does not produce an extra sandbox. See API reliability.

Recover from a host problem

Inspect the reported status, host health, and any pending operation. Do not assume a running workload can migrate without interruption. If you need a replacement, restore supported environment state from a snapshot and import the workspace separately.