How Ortam works
Updated 27 October 2026
Your system creates a Sandbox, sends it commands and stops it. Ortam runs the Linux VM, saves its disk while it works and records every command. Below, one Sandbox goes from creation to its next start.
The life of one Sandbox
1. Create it
Your backend creates a Sandbox through the API with your organization key. It starts from Ortam’s base, Ubuntu 24.04 with Node.js, Python, git, Claude Code and Codex CLI. A new Sandbox is stopped and uses no compute until it runs.
2. Send it a command
A command starts a stopped Sandbox first. Ortam accepts each command once, gives it an ID and runs it in the background. Your system can disconnect, and the command keeps running. Later, it can read the output from where it left off. Commands has the details.
3. It saves while it works
While the Sandbox runs, Ortam saves its whole disk on a schedule, without your code asking. The disk holds the repository, installed packages, system changes, Docker images and volumes. A save counts only once it is complete and stored off the host, so a half-written save never replaces a good one. Saves and recovery says what a save keeps.
4. Stop it
Stop ends the work in the VM, attempts a final save and releases the VM. Ortam reports the outcome of ending the work and of the final save separately. If the final save fails, the next start uses the save before it. Ortam then reports the time from which changes weren’t saved. A stopped Sandbox is billed only for its saved disk. You can still read and export its files without starting it.
5. Start it again
The next start or command boots a new VM from the latest completed save. The repository, dependencies and images are as they were in that save. Services you enabled start at boot. Commands from before the stop don’t run again.
6. Branch it
When a Sandbox is set up, take a Snapshot. A Snapshot is a saved copy of its files that new Sandboxes can start from, one per task. Each copy writes to its own disk and keeps working after you delete the original. A copy gets the files but not the original’s Connection grants or settings. Set those on each new Sandbox.
How agents sign in
Agents use a Claude or ChatGPT account through a Connection. The account holder signs in once, or you give Ortam an API key. Ortam keeps the login outside every Sandbox and renews it there. It delivers credentials only to Sandboxes you grant the Connection to. For a subscription they’re short-lived, and for an API-key account they’re the key itself. Both go into storage that is never saved. When the provider needs the holder to sign in again, the Connection’s status says so.
When hardware fails
If the host under a running Sandbox fails, Ortam marks the Sandbox lost. The next start or command brings it back on new hardware from its last completed save. Ortam reports how old that save is and which commands were running. Nothing reruns on its own. Your system decides what to rerun, because only it knows which commands are safe to repeat. Host failures covers what a failure can lose and how to limit it.
Under the hood
| Part | What it is |
|---|---|
| Machine | A Linux VM per Sandbox, not a container that shares the host’s kernel, with sudo and systemd, able to run Docker |
| Sizes | CPU sizes, listed in Pricing and limits |
| Saves | Whole-disk, each encrypted with its own key before it leaves the host; the keys never enter the VM |
| Storage | Separate from the host, so a save outlives the machine it came from |
| Locations | Germany and Finland |
| API | HTTPS with an organization key; every change carries an idempotency key, so a retry never acts twice |
What Ortam doesn't keep
- Memory and running processes. A start boots from the saved disk; it doesn’t resume a process where it was.
- Temporary mounts such as /tmp and /run.
- The credentials Ortam delivers for Connections. A copy an agent writes to an ordinary file is saved like any other file.
- Data in external services, such as a hosted database or a Git remote.
Where next
Why Ortam compares a kept disk with fresh and prebuilt machines, Use cases shows how teams build on it, and the docs start with your first command.