What "persistent" means in agent sandboxes, and how ten providers answer it

Eight questions to ask

• What survives when the sandbox is off: the disk, the memory and processes, or both?
• When is the state saved: continuously while it runs, when it stops, or only when you ask?
• How long is saved state kept by default?
• What happens to work since the last save if the host fails?
• Is there a cap on how long a sandbox can run?
• How long does it take to come back?
• What does keeping it cost?
• Is it a VM or a container, and can the agent run Docker inside it?

Runloop is leaving. Its docs say it “is winding down its services”, with support for existing customers through 13 November 2026. Its answers stay listed for teams moving off it.

Each provider has its own word for the off state, and the words mean different things. Vercel and Daytona’s container sandboxes stop. E2B, Daytona’s VM sandboxes and Northflank pause. Fly.io’s Sprites pause too, first warm and then cold. Runloop suspends, Blaxel goes to standby, and Modal and Cloudflare sandboxes end. The answers below use each provider’s own word.

The answers, provider by provider

What survives: disk, memory, or both

Memory survives on E2B and Blaxel by default, on Daytona’s VM sandboxes when paused, and on Sprites while they are warm. A paused process picks up where it was. That suits work that is expensive to rebuild in memory, such as a loaded dataset or a long interactive session.

On Runloop, Daytona’s container sandboxes, Sprites once they are cold, and Ortam, the disk survives and the processes don’t. Vercel restores the filesystem, and its docs don’t describe keeping memory or processes. The next run boots from the saved disk and starts its services again. For coding agents, the disk holds most of the setup cost. The clone, the installed packages, the Docker images and the build caches are all files. Runloop’s docs state the consequence: “Daemons or other processes running at suspend time must be manually restarted after resuming.” On Ortam, services you enable with systemd start again at boot.

Northflank keeps only what is on an attached volume: “Anything written only to ephemeral storage is lost when the sandbox pauses.” Modal and Cloudflare keep nothing unless your code takes a snapshot. In that model the sandbox is disposable, and you build persistence from volumes or snapshots.

When the state is saved

This question decides what a crash can cost. If a sandbox saves only when it stops, nothing is saved while an agent works for hours. Vercel snapshots on stop or timeout. Calling snapshot() while it runs takes a snapshot and stops the session. E2B saves on pause. Runloop saves on suspend.

Sprites sync the disk continuously: “The filesystem syncs to it continuously, not as a snapshot taken at hibernation.” Ortam saves a running Sandbox on a schedule, and Stop attempts a final save. Its docs don’t publish the interval yet. They also say a save can lag, so the schedule doesn’t promise how much a failure can lose. If the final save fails, Ortam says so and recovers from the previous save.

How long saved state is kept

Expiry defaults vary more than anything else in the table. Vercel’s snapshots “expire 30 days after their last use by default”, and you can remove the expiry. Cloudflare’s snapshots expire “30 days after it is created or last restored”. Modal keeps filesystem snapshots 30 days by default and memory snapshots 7 days, which can’t be extended.

E2B keeps a paused sandbox “indefinitely”, and Runloop’s snapshots “persist indefinitely and continue to incur storage costs”. Daytona doesn’t delete by default. Unless you change its timers, it stops a container sandbox after 15 minutes without activity and archives it after 7 days stopped. It pauses a VM sandbox after 60 idle minutes. On Ortam, saved data “is kept until you delete it while your plan is active.”

If an agent’s environment sits unused for a month between jobs, check this default first.

If the host fails

Save timing tells you what the last save holds. It doesn’t tell you what a hardware failure loses. That also depends on where the disk lives while the sandbox runs. A disk only on the failed machine loses everything since the last save. A disk replicated elsewhere may lose nothing. The other providers’ pages don’t settle this, so ask them directly:

• Where does a running sandbox’s disk live, and does it survive the loss of its host?
• What is the most recent work a host failure can lose, and is that a promise?
• After a failure, does the sandbox come back on its own, and does anything rerun?

Ortam’s docs answer the first two only in part, because its save interval isn’t published yet. Changes after the last completed save can be lost, and “Ortam reports which save it recovered from and which commands were running.” Nothing reruns on its own, so your system decides what to run again. Saves and recovery covers the details.

How long it can run

Session caps matter for agents that run for hours. Vercel caps a session at 45 minutes on Hobby and 24 hours on Pro, but the limit “resets every time a sandbox stops and resumes”. E2B allows 1 hour of continuous runtime on Hobby and 24 hours on Pro, also reset by a pause. Modal sandboxes can run up to 24 hours. Runloop’s default lifetime is 1 hour and can be configured. Cloudflare states an inactivity timeout of up to 6 hours and “does not guarantee that an instance runs for a set time.”

Daytona has no cap by default, but its idle timer can stop an agent’s work. Its docs say “the process itself doesn’t count as ‘activity’”. A container sandbox whose job runs for more than 15 minutes without outside interaction can be stopped partway. For those, set the auto-stop interval to 0. Ortam’s docs say: “A Sandbox runs until you stop it or a published limit applies.” Sprites, Northflank and Blaxel don’t state a cap.

How long it takes to come back

A kept environment saves time only if starting it again is quicker than setting it up. Few providers publish a number, and those that do measure different things. Waking a paused sandbox with its memory is a different operation from booting one from a saved disk.

Restore time usually grows with disk size, and none of these pages give a number for a large disk. Measure it with a disk the size of yours before you rely on it.

What keeping it costs

Saved state is billed by the GB, and the rates differ by more than ten times. Prices are as each provider states them. Hourly rates are converted at 30.4 days a month.

For a few environments, none of these amounts matter. For hundreds of kept environments, or one per task, they add up. So does the difference between “kept by default” and “kept until it expires”.

VM or container, and Docker

Almost every provider here runs each sandbox in a VM or a microVM, a lightweight VM. Daytona runs containers by default, with VM sandboxes as an option, and Modal offers gVisor (a container runtime with an extra isolation layer) or a VM runtime. On Northflank’s cloud, CPU sandboxes run in microVMs and GPU sandboxes under gVisor.

Docker inside the sandbox works on most of them, often as Docker-in-Docker from a provided image or template. Vercel supports it as a process with system privileges, and Modal on its VM runtime. Ortam runs each Sandbox in its own VM, where the developer user has sudo and can run Docker. A save keeps Docker images and volumes with the rest of the disk.

Which kind fits your agents

• The environment is expensive to set up and jobs repeat. Look for a disk that is kept by default and saved while it runs, with an expiry longer than the gaps between jobs.
• The agent holds valuable state in memory. Look for memory snapshots or pause with memory, and check how long that state is kept.
• Each job must start clean, or runs untrusted code. A sandbox that keeps nothing, with snapshots you take on purpose, is the simpler model.
• Jobs run for many hours. Check the session or runtime cap, and whether a pause resets it.

Providers change these behaviors often. Several features above are marked beta or alpha in their docs, and some depend on the plan. Check the linked pages before you decide.

Sources

Checked on 26 October 2026. Quotes are from these pages.

Vercel

Persistent sandboxes, Snapshots, Pricing and limits, Overview

Fly.io

Sprites lifecycle, Checkpoints, Sprites, Keeping Sprites running

E2B

Sandbox persistence, Snapshots, Billing, Sandbox price, Docker template

Daytona

Sandboxes, Linux sandboxes, Snapshots, Billing, Pricing

Modal

Sandbox snapshots, Sandboxes

Cloudflare

Sandbox lifetime, Containers limits, Containers FAQ, Containers architecture

Runloop

Devbox lifecycle, Start and stop, Snapshots, Docker-in-Docker, Pricing, OpenAI Agents SDK tutorial

Northflank

Configure and manage sandboxes, Sandboxes, Sandboxes on Northflank cloud, Pricing

Blaxel

Sandboxes overview, Expiration, Docker, Pricing

Ortam

Saves and recovery, Sandboxes, Pricing and limits