Questions and answers

A hosted service that gives each AI coding agent a Sandbox, a Linux VM it keeps. Ortam saves the whole disk while the VM runs. The next job starts with the repository, dependencies and Docker images in place. Test suites and dev environments use Sandboxes the same way. How it works

A system that assigns tasks to coding agents, checks their changes and opens pull requests. Ortam runs the machines the agents work on. The factory keeps its own users, repositories, agents and task queue. Machines for a software factory

It’s in private beta. We’re letting teams in a few at a time. Email access@ortam.dev with what your agents run and roughly how many Sandboxes you need.

No. Your backend holds an organization key and decides which Sandbox serves which user, project or task. Your users sign in to your product, not to Ortam.

Anything that runs on Linux. Node.js, Python, git, Claude Code and Codex CLI come preinstalled, and Connections let Claude Code and Codex use a Claude or ChatGPT account. Claude Code and Codex in the cloud

The whole disk: the repository, installed packages, system changes, Docker images and volumes. Memory, running processes, temporary mounts such as /tmp, and the credentials Ortam delivers aren’t saved. Saves and recovery

Ortam saves on a schedule while a Sandbox runs, without your code asking. Stop attempts a final save. The interval isn’t published yet. A Sandbox’s status shows when saving is delayed or failing. When saves happen

The next start or command brings the Sandbox back on new hardware from its last completed save. Ortam reports how old that save is and which commands were running. It reruns nothing on its own. Host failures

Yes. The developer user has sudo in the Sandbox’s VM and can run Docker. Docker isn’t preinstalled. Install it once, and every save keeps it with its images and volumes.

Yes. Reading or exporting files from a stopped Sandbox uses its saved disk. The VM doesn’t start, so no compute is used. The API routes for files are to be published.

Yes, while it’s stopped, if its disk fits the new size. The next start uses the new size and the same disk.

Yes, with a Sandbox each. Take a Snapshot of a Sandbox that’s already set up and start one copy per task. Each copy writes to its own disk. Snapshots

Through a Connection. The account holder signs in once. Ortam keeps and renews the login outside the VM. Each Sandbox with access to the account gets short-lived credentials that are never saved. For an account that uses an API key, the Sandbox gets the key. Connections

The credentials Ortam delivers don’t. A credential an agent writes to an ordinary file is saved and copied like any other file. Rotate any credential that ends up there.

$20 a month, and all of it goes toward your usage. A running Sandbox is billed by the second, from $0.018 an hour for Small. Its running time never costs more than its size’s monthly cap. A stopped one pays only for its saved disk, at 1¢ per GB‑month. Prices are planned for launch. Pricing and limits

No. Billing starts when a Sandbox is ready. Waiting for capacity and starts that fail aren’t charged.

Yes. Each save is encrypted with its own key before it leaves the machine, and those keys never enter the VM.

In Germany and Finland. A Sandbox’s saved data stays in the location where it was stored.

Each Sandbox is its own VM, not a container on a shared kernel. The agent has sudo inside it but can’t change the kernel, boot, network or storage, or read Ortam’s credentials.

E2B keeps a sandbox’s disk and memory when you pause it. Vercel Sandbox saves the disk when it stops and keeps it 30 days after last use by default. Ortam saves the whole disk on a schedule while the agent works, not only when it stops. It keeps the disk while your plan is active. What each provider keeps, compared

When work must resume with its memory and running processes intact, when each job runs untrusted code for seconds and nothing should carry over, or when you need GPUs. Why Ortam