ARCHIL

How Archil compares

Archil is a disk for agents: it outlives the sandbox, many sandboxes share it, it branches in milliseconds, and it can live in your own S3, GCS or R2 bucket.

Sandbox storage comparedPersistence, sharing, forks and bucket support across 8 providers, with measurements.E2B · Modal · Daytona · Vercel Sandbox · Cloudflare Sandbox · Blaxel · Northflank · Fly.io Sprites

Which storage fits?

Flip what your workload needs. Capabilities come from each vendor's docs.

What the workload needs
StorageFitPersistsShared writesForksYour bucketnpm ci, 10.5k files
Archil diskFitsYesYesYesYes1.85 to 3.32 s
Why
  • A disk is kept until you delete it, whichever sandbox mounted it.
  • Many sandboxes mount one disk read-write, on any provider.
  • Up to 5,000 clients per disk.
  • Measured: npm ci of 10,538 files: 1.85 s in a Modal sandbox (Modal Volume 10.5 s), 3.32 s in a Vercel sandbox (Vercel Drive 2.20 s).
  • Measured: A second sandbox saw a new file in about 70 ms after archil invalidate-cache, or about 28 s with default caching.
Daytona VolumeFitsYesYesNoNoOver 15 min
Why
  • Volume data survives deleting the sandbox.
  • Many sandboxes mount it read-write; the last write to a path wins.
  • Measured: A durable 4 KiB file: 381 ms. npm ci of 10,538 files didn't finish within 15 minutes.
  • Measured: Another sandbox saw a new file in about 360 ms.
Modal VolumeCheckYesReload to seeNoSeparate mount10.5 s
Why
  • Volume data persists past the sandbox.
  • Many sandboxes mount it; readers reload to see others' commits, and the last write to a file wins.
  • Measured: npm ci of 10,538 files: 10.5 s. A 1 GiB file read from a new sandbox at 624 MB/s, against 331 MB/s for an Archil disk about 40 ms away. Other sandboxes' writes appear only after a commit and a reload.
  • Measured: A running sandbox didn't see another sandbox's new file within 60 s without a reload.
E2B VolumeCheckBetaBetaNoNoNot measured
Why
  • Volume data outlives the sandbox; Volumes are in private beta.
  • In private beta; E2B documents locking and stale-handle caveats.
Vercel DriveNo fitYesOne writerYesNo2.20 s
Why
  • Drives persist until deleted.
  • One read-write mount at a time; other sandboxes get read-only snapshots.
  • Measured: npm ci of 10,538 files: 2.20 s on a Drive, 3.32 s on an Archil disk in the same sandbox. A Drive fsync is not durable (snapshots taken up to 30 s later lacked the file), and only one sandbox can write a Drive. A 1 GiB file read from a new sandbox at 315 and 439 MB/s.
  • Measured: A second sandbox's read-only snapshot didn't see a new file within 60 s.
Fly.io Sprite diskNo fitWhile the Sprite existsNoRestore in placeNot documented2.59 s
Why
  • The disk persists while the Sprite exists; destroying the Sprite deletes it.
  • Each Sprite has its own disk.
  • 100 GB per Sprite, fixed.
  • One sandbox per disk.
  • Measured: npm ci of 10,538 files: 2.59 s. 1 GiB writes: 33 to 114 MB/s. Writes reach durable storage only when the Sprite goes idle, and only that Sprite can mount the disk.
Blaxel VolumeNo fitYesOne sandboxNot documentedNoNot measured
Why
  • Volumes survive sandbox deletion.
  • A volume attaches to one sandbox at a time; Agent Drive is in private preview.

Sandboxes

Archil disks mount inside these sandboxes, and Archil runs its own.

File systems

Other ways to give many machines one POSIX file system.

Object storage

Stores your app reaches over the S3 API, and how a disk sits alongside them.