Amulet vs Daytona storage
Daytona's persistence model is sandbox-shaped: stop a sandbox and its filesystem is snapshotted for resume, within per-sandbox disk allocations on the order of a few gigabytes, while stopped sandboxes quietly keep billing for the storage they hold. That's convenient for resuming one agent's session and limiting for everything else — sharing, forking, history, and datasets bigger than a sandbox disk. Amulet decouples the data from the sandbox: one durable, versioned workspace that any number of sandboxes mount, fork, and publish to conflict-safely, billed only on actively used data. Run agents on Daytona; give their work a filesystem that outlives the sandbox.
Amulet
Amulet is a storage-first file system for agent workloads: durable, versioned workspaces that mount into any sandbox in under 100 ms and outlive all of them.
Daytona storage
Daytona provides fast sandboxes for AI agents; persistence comes from snapshotting a sandbox's filesystem when it stops, plus volumes for mounting shared data into sandboxes.
Capability by capability
Capability
Amulet
Daytona storage
Storage decoupled from sandbox lifecycle
Amulet
Yes
Workspaces are durable objects independent of any sandbox; delete every sandbox and nothing is lost.
Daytona storage
No
Persistence is a property of a stopped sandbox's snapshot; the data's home is the sandbox.
Data scale
Amulet
Yes
Gigabytes to a full data estate behind one mount; mount time doesn't grow with size.
Daytona storage
No
Per-sandbox disk allocations default to a few GiB with caps around 10 GB — sized for code, not datasets.
Sharing data between sandboxes
Amulet
Yes
Many sandboxes mount isolated sessions of one workspace concurrently; publishes merge conflict-safely.
Daytona storage
Partial
Volumes can mount shared data into sandboxes, but without isolation, versioning, or conflict handling for writers.
Instant copy-on-write forks
Amulet
Yes
Fork a workspace per agent or per attempt in milliseconds; zero bytes copied until writes diverge.
Daytona storage
Partial
Sandbox snapshots clone an environment for resume; forking the data itself isn't a storage primitive.
Version history
Amulet
Yes
Content-addressed commits; browse history and restore any revision exactly.
Daytona storage
No
A snapshot is one implicit moment of one sandbox; there is no browsable history of the data.
Conflict-safe concurrent writers
Amulet
Yes
Isolated sessions publish compare-and-swap; stale writers get explicit conflicts, never silent overwrites.
Daytona storage
No
Concurrent writers to a shared volume coordinate themselves.
Provenance
Amulet
Yes
Every commit records the actor, session, and run that produced it.
Daytona storage
No
No per-change attribution on sandbox files.
Storage pricing
Amulet
Yes
$0.20/GiB-month for actively used data, time-weighted; API and transfers free; 10 GB free tier.
Daytona storage
Partial
Stopped sandboxes keep consuming billed storage (filesystem + memory snapshots) until explicitly deleted — fleets accumulate this cost silently.
Works with any compute provider
Amulet
Yes
Mount from Daytona, E2B, Modal, your own VMs — the workspace is portable.
Daytona storage
No
Snapshots and volumes exist inside Daytona.
Code execution
Amulet
No
Amulet is storage — bring your own compute, Daytona included.
Daytona storage
Yes
Sub-100 ms sandbox creation with a strong developer experience; this is Daytona's product.
When to choose Daytona storage
- You need fast, isolated compute for agent code — that's Daytona's product, and Amulet doesn't compete with it.
- Stop-and-resume of a single agent's sandbox covers your persistence needs.
- Your working set fits comfortably inside a sandbox disk.
When to choose Amulet
- Agent work must outlive sandboxes and be reachable from the next one — on Daytona or anywhere else.
- Fan-out workloads need many sandboxes on the same data with isolation and conflict-safe merges.
- Datasets exceed sandbox disk allocations.
- You want history and attribution for agent output, and storage billing that doesn't depend on remembering to delete stopped sandboxes.
Frequently asked questions
Does Amulet replace Daytona?
No — they compose. Daytona is compute: fast sandboxes where agent code runs. Amulet is storage: durable, versioned workspaces those sandboxes mount in under 100 ms. Using both, sandboxes stay disposable while the work accumulates safely in one place.
How is Amulet different from Daytona volumes?
Daytona volumes mount shared data into sandboxes, which solves distribution but not coordination: writers get no isolation, no versioning, and no conflict handling. Amulet gives every sandbox an isolated session of the workspace, records each publish as an attributable commit, and rejects stale publishes with an explicit conflict instead of letting agents overwrite each other.
What are Daytona's storage limits for agent data?
Sandboxes come with disk allocations sized for code execution — defaults around 3 GiB and caps on the order of 10 GB per sandbox — and stopped sandboxes keep billing for the storage their snapshots hold until deleted. Amulet workspaces scale from gigabytes to a full data estate, mount without copying, and bill only for actively used data.
Can agents on Daytona keep context between sessions?
Daytona can resume a stopped sandbox from its snapshot, which restores that one sandbox. With Amulet, context isn't tied to any sandbox at all: a fresh sandbox mounts the workspace and finds every prior session's published work, with the full history of who produced what.