The sandbox lifecycle: from image to resumed work

A Borealis sandbox outlives the command that started it. Define the environment once, work in it, pause it with its state intact, and pick it up when the work resumes.

Define the environment, then place it

A sandbox starts from an image and the resources its workload needs: CPU and memory, the ports it will expose, environment variables, and any trusted runtime capabilities. Those choices describe the machine the agent will work on, and they are worth getting right early, because everything after this point accumulates inside them.

Borealis then schedules the workload on managed capacity or an eligible private host pool. The Borealis overview describes the capacity model and which private host options your plan reaches.

Work with real tools

Inside the sandbox there are terminals, files, services, browsers, logs and ports. Commands run there and services start there, whether you drive them yourself or an agent does, and you watch the same environment from the Borealis app.

That shared view matters when something fails. The output, the filesystem and the running processes are all still in front of you, rather than summarised in a message you have to take on trust.

Pause without losing the work

Stopping a sandbox and snapshotting it preserves the environment between sessions. Keeping those transitions explicit means an actively running workload and an environment saved for later stay easy to tell apart, both in the app and in anything you build against it.

When the work resumes, continue from the snapshot. The same lifecycle operations are available through the public API, CLI, and MCP tools, so a sequence you have run by hand can become one your application or an agent runs for you. The documentation covers setup and usage for all three.

Open the Borealis app to work with your sandboxes, or return to the blog for more updates and guides.