Amulet vs Modal Volumes
Modal Volumes are a good answer to "my Modal function needs its files back," and if all your compute is Modal functions they're the native choice. They're also confined to that world: usable only from Modal, tuned for write-once-read-many with explicit commit/reload, capped at 500,000 inodes per volume, and billed on daily snapshots of everything stored. Amulet is the storage layer rather than a platform feature — a live filesystem any provider can mount, with real version history, instant forks, conflict-safe publishing, and billing that only counts actively used data. Modal is a compute platform; bring Amulet to it, and your data outlives any one platform.
Amulet
Amulet is a storage-first file system for parallel AI workloads: a live mounted workspace with instant zero-copy forks and versioned history, mountable from any Linux environment — including Modal.
Modal Volumes
Modal Volumes are Modal's persistent storage primitive: a distributed volume attached to Modal functions and sandboxes, optimized for write-once-read-many data with explicit commit and reload steps.
Capability by capability
Capability
Amulet
Modal Volumes
Works with any compute provider
Amulet
Yes
Mount from any Linux environment — Modal, E2B, Daytona, your own VMs, any cloud.
Modal Volumes
No
Attachable only to Modal functions and sandboxes.
Live filesystem semantics
Amulet
Yes
A mounted filesystem — writes are ordinary file writes; no commit/reload dance to see changes.
Modal Volumes
Partial
Changes must be committed to persist and reloaded to be seen elsewhere; volumes are explicitly not designed for concurrent writes to the same files.
Scale limits
Amulet
Yes
Workspaces scale from gigabytes to a full data estate; mounts stay size-independent.
Modal Volumes
No
Hard limit of 500,000 inodes per volume — further file creation fails with ENOSPC.
Instant copy-on-write forks
Amulet
Yes
Fork a workspace in milliseconds; zero bytes copied until writes diverge.
Modal Volumes
No
No fork primitive; a second independent copy means copying the data.
Version history
Amulet
Yes
Content-addressed commits with restore to any revision.
Modal Volumes
No
A volume holds current state; commits persist changes but don't create restorable history.
Conflict-safe concurrent writers
Amulet
Yes
Isolated sessions publish compare-and-swap; stale writers get explicit conflicts.
Modal Volumes
No
Concurrent writes to the same files are documented as unsupported; last commit wins.
Provenance
Amulet
Yes
Every commit records the actor, session, and run that produced it.
Modal Volumes
No
No per-change attribution.
Storage pricing
Amulet
Yes
$0.20/GiB-month for actively used data (time-weighted); inactive data isn't billed at the active rate; 10 GB free.
Modal Volumes
Partial
$0.09/GiB-month on total stored bytes, snapshotted daily — deleted data can keep billing for days, and cold data bills like hot data.
Storage decoupled from compute lifecycle
Amulet
Yes
Workspaces exist independently of any sandbox or function; mount them from the next job, anywhere.
Modal Volumes
Partial
Volumes persist beyond individual functions but live and die inside your Modal account.
When to choose Modal Volumes
- All of your compute runs on Modal and you want the platform-native path with no extra service.
- Your data is write-once-read-many — model weights, cached artifacts — well under the inode cap.
- Commit/reload semantics fit your job structure.
When to choose Amulet
- Your agents or jobs span providers — or you want the freedom to move — and storage shouldn't be the thing that locks you in.
- Many writers work in parallel from a shared base and need isolation, forks, and conflict-safe merges rather than 'don't write concurrently.'
- Repository-shaped data with lots of files would blow through a 500,000-inode cap.
- You want history and attribution, not just persistence.
Frequently asked questions
Can I use Amulet with Modal?
Yes. Amulet mounts from any Linux environment, including Modal containers, so Modal remains your compute layer while Amulet holds the workspace — with versioned history and forks that Modal Volumes don't provide, and with the same data reachable from outside Modal.
How is Amulet different from a Modal Volume?
A Modal Volume is platform storage: attachable only to Modal compute, tuned for write-once-read-many, with explicit commit/reload semantics and a 500,000-inode ceiling. Amulet is a live filesystem with workspace semantics — instant zero-copy forks, content-addressed commits, conflict-safe publishing, provenance — that any compute provider can mount.
Modal Volumes cost $0.09/GiB-month — isn't that cheaper?
Per stored byte, yes. But Modal bills a daily snapshot of everything in the volume — cold data bills like hot data, and deleted data can keep billing for several days — while Amulet bills $0.20 per GiB-month only on actively used data, time-weighted, with API calls and transfers free. A large, mostly cold workspace is routinely cheaper on Amulet, and forks cost nothing until they diverge.
What happens if two Modal functions write the same volume?
Modal's documentation is direct: volumes aren't designed for concurrent writes to the same files, and the last commit wins. Amulet is designed for exactly that case — each writer gets an isolated session, and publishing is compare-and-swap, so a stale writer receives an explicit conflict instead of silently losing work.