Persistent storage for AI sandboxes (E2B, Daytona, Modal)

Sandboxes are disposable by design — that's the point of them — which makes agent state the awkward part. The platform answers are pausing the sandbox (E2B, Daytona) or attaching platform volumes (Modal, Daytona); the portable answer is mounting a durable external workspace into each sandbox, so state outlives every sandbox and moves between providers. Here's how the options actually behave, and where each one runs out.

What happens to files when a sandbox dies?

By default, they die with it. A sandbox filesystem is the sandbox's disk: when the sandbox is killed, times out, or errors, everything the agent wrote is gone. Every persistence strategy is some way of getting the data out of that blast radius before it's needed again — the strategies just differ in how much they couple your data to one sandbox, one provider, and one lifecycle.

Does pause-and-resume solve persistence?

It solves resumption, which is narrower. Pausing snapshots the whole sandbox — filesystem and memory — so that one sandbox can continue later. But the snapshot isn't data you can work with: you can't mount it from another sandbox, share it between concurrent workers, fork it per attempt, or restore last Tuesday's version. And paused sandboxes keep consuming billed storage until someone remembers to delete them — a cost that accumulates silently across a fleet. Pause is a fine feature; as a storage strategy it's a sandbox-shaped box around your data.

Are platform volumes the answer?

They loosen the coupling to one sandbox but keep it to one platform, and their semantics are built for distribution rather than collaboration. Modal Volumes are tuned for write-once-read-many with explicit commit/reload steps, are documented as unsupported for concurrent writes to the same files, and cap at 500,000 inodes per volume — repository-shaped data hits that ceiling fast. Daytona volumes mount shared data into sandboxes but give writers no isolation, no versioning, and no conflict handling. Both live entirely inside their platform. Full breakdowns: Amulet vs Modal Volumes and Amulet vs Daytona storage.

What does workspace-based persistence look like?

Invert the relationship: instead of data living inside compute, the workspace is durable and sandboxes are disposable views onto it. Each sandbox mounts an isolated session of the workspace at boot — on Amulet that takes under 100 ms regardless of size, with nothing downloaded up front — works with ordinary file tools, and publishes results as attributable commits. Kill the sandbox mid-run and everything published is safe; the next sandbox mounts the same workspace and continues with full context.

Concurrency stops being forbidden and starts being managed: parallel sandboxes fork the same base in milliseconds at zero copy cost, and merges are conflict-checked rather than last-writer-wins. History and provenance come along free — every commit knows which agent, session, and run produced it.

Which approach should you use?

• One agent resuming its own session: platform pause/resume is the low-effort fit.
• Static read-mostly assets inside one platform: platform volumes work, within their write and size limits.
• Work that must outlive sandboxes, be shared by concurrent workers, carry history, or move between providers: a mounted durable workspace — this is what Amulet alongside E2B, Daytona, or Modal is for.

The compute platforms are good at compute. The failure mode is asking their storage appendages to be a data layer — and the fix is a storage layer that treats every sandbox as what it is: disposable.