Sandboxes
Each Sandbox runs in its own Linux VM, not a container. Its ID and files outlive the VM: Stop releases the VM, and the next start boots a new one from the Sandbox’s last completed save.
What runs inside
Each Sandbox starts from Ubuntu 24.04, with Node.js, Python, git, Claude Code and Codex CLI preinstalled.
The developer user has sudo inside the VM, with installed packages, services and supported containers such as Docker. Ortam controls the kernel, boot, network and storage; sudo inside can’t change those or read Ortam’s credentials.
Each size states its resources. See Pricing and limits for what each size gets.
You can open a terminal through a private link that names the Sandbox and expires. [How revoked links and open sessions behave] is to be published.
States
A Sandbox’s phase is one of these:
stopped- No VM. Its files are saved: you can read and export them without booting anything, so reading uses no compute, and each read says which save it comes from. You can also change settings, grants and its size (if its disk fits the new size), and take Snapshots.
starting- Ortam is finding capacity and booting from the latest completed save. If the start fails, its operation ends
failed, and you can start the Sandbox again when you need it. ready- Commands and file access work. Billing runs from here.
stopping- Work is ending and a final save is being made. New starts, commands, terminals, uploads and Snapshots are refused, not queued; reading files, results and settings still works.
lost- Its host failed. If a host fails covers what was kept and how the Sandbox comes back.
deleted- Ortam accepted its Delete, so it isn’t listed. Stopping and deleting covers what Delete ends.
Starting
A start, a command or opening a terminal starts a stopped Sandbox. Requests that arrive together share one start. Reading saved files, settings, grants or past results never starts it, and neither does traffic to an application inside it.
When Ortam accepts a start, it fixes which save to boot from: the latest completed save, or the base or Snapshot the Sandbox was created from if it has never been saved. It never reruns old commands; services you enabled start as usual. Ortam doesn’t move running work to other machines.
If no capacity is available in the permitted locations, the start fails and isn’t charged. You don’t need to retry in another location yourself.
Stopping and deleting
Stop ends all work in the VM, attempts a final save and releases the VM, within a deadline of [Stop deadline]. Ending the work and saving each report their own outcome: completed, failed or unknown. A passed deadline alone doesn’t prove the work ended. If the final save fails, the previous completed save stays the recovery point, and Ortam reports since when changes weren’t saved.
Stop and Delete also work while a Sandbox is starting, and replace that start; commands still waiting for it are not launched, one already being launched reports its own outcome, and none carry over to a later start. Repeating a Stop doesn’t extend its deadline. Delete is permanent: no new work is accepted. Starting a Sandbox from a Snapshot says what deleting the source leaves in place.
Nothing needs a heartbeat to keep running. A Sandbox runs until you stop it or a published limit applies.