Sandbox storage compared

On Archil, a sandbox's files persist between sessions and can be shared across sandboxes and providers.

Each provider's own storage, from its docs and our measurements. "Not documented" means the docs don't say.

Vercel Drive and Fly.io Sprite writes are not durable when fsync returns

Both write to local NVMe first. Vercel describes Drives as "NVMe-speed writes and cache-hit reads, slower reads on a cache miss"; Fly.io says Sprite data "is backed up to durable object storage" when the Sprite goes idle. Their write results here are local acknowledgements. Archil's are writes already replicated across Availability Zones. A Drive fsync is not durable: in our test, a Drive snapshot or fork taken within 30 s of fsync returning usually didn't contain the file, while an Archil disk mounted in a new sandbox right after fsync had it 20 of 20 times. Run the test yourself.

Where a store beats Archil on npm ci, no other sandbox can share the files

A Vercel Drive takes one writer, and other sandboxes see only read-only snapshots that miss later writes. A Sprite's disk mounts only in that Sprite. An Archil disk mounts read-write in any number of sandboxes, on any provider.

Which storage fits?

Flip what your workload needs.

Storage	Fit	Persists	Shared writes	Forks	Your bucket	npm ci, 10.5k files
Archil disk	Fits	Yes	Yes	Yes	Yes	1.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 Volume	Fits	Yes	Yes	No	No	Over 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 Volume	Check	Yes	Reload to see	No	Separate mount	10.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 Volume	Check	Beta	Beta	No	No	Not measured
Why Volume data outlives the sandbox; Volumes are in private beta. In private beta; E2B documents locking and stale-handle caveats.
Vercel Drive	No fit	Yes	One writer	Yes	No	2.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 disk	No fit	While the Sprite exists	No	Restore in place	Not documented	2.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 Volume	No fit	Yes	One sandbox	Not documented	No	Not measured
Why Volumes survive sandbox deletion. A volume attaches to one sandbox at a time; Agent Drive is in private preview.

Where the data lives

The sandbox's own disk

Lost when the sandbox is deleted.

A provider's volume

Outlives the sandbox; sharing rules differ by provider.

An Archil disk

Mounts read-write on any FUSE-capable provider, outlives all of them, and is also an S3 bucket.

Measured

MethodOne Modal VM sandbox (runtime="vm", 2 CPU, 4 GiB, region us-west) with a Modal Volume (v2) and an Archil disk in aws-us-west-2 mounted side by side; a TCP connection from the sandbox to Archil took about 40 ms. Modal Volumes persist on an explicit commit, so every Modal write below includes sync on the mount point. Medians of 3 runs, except the 4 KiB writes (100 in a row) and provisioning (5). Run it yourself.

Create a 4 KiB file and make it durable

Lower is better

Archil disk in the same Modal sandbox20 ms
open, write, fsync, close
Modal Volume108 ms
open, write, fsync, close, then sync to commit

npm ci, 10,538 files, from a local cache

Lower is better

Archil disk in the same Modal sandbox1.85 s
Modal Volume10.5 s

Delete that node_modules tree

Lower is better

Archil disk in the same Modal sandbox0.46 s
Modal Volume3.87 s

Write 1 GiB sequentially and make it durable

Higher is better

Archil disk in the same Modal sandbox685 MB/s
Modal Volume395 MB/s

Read that 1 GiB from a new sandbox

Higher is better

Archil disk in the same Modal sandbox331 MB/s
about 40 ms from this sandbox, so each cache miss crossed that distance
Modal Volume624 MB/s

MethodDaytona sandboxes (default snapshot, 1 vCPU, 1 GiB) in Daytona's us region, which serves from New York, each with a Daytona Volume mounted. Medians of 3 runs, except the 4 KiB writes (40 in a row per run) and provisioning (10). The account's Archil key only reaches aws-us-west-2, about 80 ms from New York, so an Archil disk wasn't measured side by side here. Run it yourself.

Create a 4 KiB file and make it durable

Lower is better

Daytona Volume381 ms
open, write, fsync, close
Archil diskNot measured
Not measured in Daytona; in a Modal sandbox it took 20 ms

Write 1 GiB sequentially and make it durable

Higher is better

Daytona Volume344 MB/s
Archil diskNot measured

Read that 1 GiB from a new sandbox

Higher is better

Daytona Volume397 MB/s
Archil diskNot measured

MethodOne Vercel sandbox (2 vCPU, 4 GB) in pdx1, which is AWS us-west-2, with a Vercel Drive in pdx1 and an Archil disk in aws-us-west-2 mounted side by side; a TCP connection from the sandbox to Archil took about 10 ms. Medians of 3 runs, except the 4 KiB writes (100 in a row) and provisioning (5). A Drive write is not durable when fsync returns: snapshots and forks taken up to 30 s later were missing the file. A Drive is an ext4 block device in the sandbox; its fsync returned in about 0.2 ms, local NVMe speed, and Vercel describes Drives as "NVMe-speed writes" with "slower reads on a cache miss" without documenting when a write reaches remote storage. An Archil fsync returns once the write is durable on Archil's replicated storage, so the write results below compare a local acknowledgement with a durable write. Run it yourself.

Create a 4 KiB file and fsync it

Lower is better

Archil disk in the same Vercel sandbox4.8 ms
open, write, fsync, close; durable on return
Vercel Drive0.2 ms
open, write, fsync, close; acknowledged by local NVMe, and snapshots taken up to 30 s later lacked the file

npm ci, 10,538 files, from a local cache

Lower is better

Archil disk in the same Vercel sandbox3.32 s
Vercel Drive2.20 s

Delete that node_modules tree

Lower is better

Archil disk in the same Vercel sandbox0.85 s
Vercel Drive0.19 s

Write 1 GiB sequentially and fsync

Higher is better

Archil disk in the same Vercel sandbox425 MB/s
Vercel Drive2,326 MB/s

Read that 1 GiB from a new sandbox

Higher is better

Archil disk in the same Vercel sandbox439 MB/s
Vercel Drive315 MB/s

MethodOne Fly.io Sprite (8 vCPU, memory managed by Fly.io) measuring its own persistent disk, the ext4 filesystem Fly.io backs with NVMe and object storage. A Sprite fsync is not a durable write: Fly.io's docs say data is written to NVMe while the Sprite runs and backed up to durable object storage when it goes idle. Sprites have no separate volume product, so the Sprite's disk is the storage measured. The Sprite reached Archil's nearest region, aws-us-west-2, in about 31 ms per TCP connection, so an Archil disk isn't shown side by side here. A Sprite's disk can't be attached to another Sprite, so the cold read drops the page cache in the same Sprite. Medians of 3 runs, except the 4 KiB writes (100 in a row) and provisioning (5). Run it yourself.

Create a 4 KiB file and fsync it

Lower is better

Sprite disk3.5 ms
open, write, fsync, close; Fly.io writes to NVMe while the Sprite runs and backs it up to object storage when the Sprite goes idle
Archil diskNot measured
Not compared: about 31 ms from this Sprite

npm ci, 10,538 files, from a local cache

Lower is better

Sprite disk2.59 s
Archil diskNot measured

Write 1 GiB sequentially and fsync

Higher is better

Sprite disk64 MB/s
3 runs: 114, 64 and 33 MB/s
Archil diskNot measured

Read that 1 GiB with the page cache dropped

Higher is better

Sprite disk152 MB/s
Archil diskNot measured

MethodFive new E2B sandboxes from the base template (2 vCPU, about 0.5 GB of memory) in E2B's default region, each mounting an Archil disk in aws-us-west-2, about 2 ms away. Install time is the Archil install script; mount time is archil mount; the first read is 4 KiB from a file on a 200,000-file disk. Run it yourself.

Full comparison

Provider	After a sandbox stops	Disk or volume size	Shared read-write volume	Snapshots and forks	Your own bucket	Open format	Archil disk mounts inside
E2B	Paused sandboxes kept with no time limit	Sandbox disk 10 GiB (Hobby), 20+ GiB (Pro)	Volumes, in private beta	Memory and filesystem snapshots; live fork	Via FUSE drivers in a template	Not documented	Yes
Modal	Volumes persist; snapshots expire after 30 days by default	512 GiB sandbox disk; Volumes have no fixed capacity	Yes; readers reload, last write wins	Filesystem, directory and memory snapshots (memory is alpha)	Yes: S3, R2 and GCS mounts	Not documented	VM runtime only
Daytona	Stopped sandboxes kept until deleted	Sandbox disk 3 GiB default, 10 GB max	Yes; last write wins	Snapshots; VM forks with memory	Via FUSE tools	Not documented	Yes
Vercel Sandbox	Filesystem snapshot on stop, 30-day default expiry	64 GB per sandbox; Drives to a 16 TiB quota	One writer; read-only snapshots for others	Filesystem snapshots, fork, Drive forks	Via FUSE drivers	Not documented for Drives	Yes
Cloudflare Sandbox	Disk is ephemeral; snapshots expire after 30 days	2 to 20 GB by instance type	No volume product; shared bucket mounts	Filesystem snapshots, in beta	Yes: any S3-compatible bucket	Yes, for bucket mounts	Yes
Blaxel	Standby keeps memory and files	Memory-backed, about half the RAM	Agent Drive, in private preview	Memory and filesystem, in private preview	Not for volumes	Not documented	Not documented
Northflank	Volumes survive pause and delete	Volumes up to 64 TB	Yes, multi read/write volumes	Volume backups and clones	S3-compatible buckets via FUSE	Not documented	Not documented
Fly.io Sprites	Disk persists; memory dropped when cold	100 GB, fixed	Not documented	Filesystem checkpoints	Not documented	Not documented	Yes
Archil disk	Kept until deleted	Grows with the data	Yes, up to 5,000 clients	Checkpoint 13 ms, branch 33 ms (p50)	Yes: S3, GCS, R2 and S3-compatible	Yes, on disks synced to your bucket	Archil sandboxes mount disks natively

In detail

What persists after a sandbox stops

E2B: pause keeps filesystem and memory indefinitely; the default timeout kills the sandbox and its state.
Modal: sandboxes run up to 24 hours. Volumes commit in the background and on exit. Filesystem snapshots expire after 30 days by default, memory snapshots after 7.
Daytona: stop keeps the filesystem, not memory; VM sandboxes can pause with memory. Stopped sandboxes archive after 7 days and are kept until deleted. Ephemeral and GPU sandboxes are deleted on stop.
Vercel Sandbox: filesystem snapshot on stop, without memory; snapshots expire 30 days after last use by default, or never. Drives persist until deleted; a Drive fsync is not durable: snapshots and forks taken up to 30 s later lacked the file.
Cloudflare Sandbox: the disk is ephemeral. Container snapshots, in beta, expire after 30 days. Mounted bucket files remain.
Blaxel: standby after about 15 s keeps memory and files; no deletion unless you set a policy (lower tiers cap at 7 or 30 days). Volumes outlive the sandbox.
Northflank: pause wipes ephemeral storage; volumes survive until deleted.
Fly.io Sprites: the disk persists; memory is dropped once a Sprite goes cold. Writes land on NVMe and reach durable object storage only when the Sprite goes idle, so fsync isn't durable. Destroying a Sprite deletes its files and checkpoints.
Archil: a disk is kept until deleted, and a write is durable when fsync returns. Archil sandboxes keep root and mounted disks through stop, pause and hardware failure.

Disk and volume size limits

E2B: 10 GiB (Hobby), 20+ GiB (Pro), more on request. Volume limits not documented.
Modal: 512 GiB sandbox disk, fixed. Volumes have no fixed capacity; v2 files under 1 TiB, up to 262,144 files per directory.
Daytona: 3 GiB default, 10 GB max per sandbox. Volume cap not documented.
Vercel Sandbox: 64 GB per sandbox. Drives default to 1 TiB (1 GiB on Hobby), 16 TiB quota, raisable.
Cloudflare Sandbox: 2 to 20 GB by instance type, raisable on request.
Blaxel: in-memory filesystem, about half the RAM. Volumes grow but can't shrink.
Northflank: 1 GB ephemeral by default; volumes up to 64 TB, no shrinking.
Fly.io Sprites: 100 GB per Sprite, fixed.
Archil: disks grow and shrink with the data. Files up to 1 PiB on Archil-managed disks, 5 TiB on bucket-synced disks.

Sharing one volume across sandboxes

E2B: Volumes (private beta) mount in several sandboxes; E2B warns locks can hang, read-only mounts aren't supported, and heavy renames can leave stale handles.
Modal: Volumes and bucket mounts share read-write; v2 handles hundreds of writers. Readers must reload, last write wins, no distributed locks.
Daytona: many sandboxes mount a volume read-write and see writes immediately; last write wins; not for database files.
Vercel Sandbox: one read-write mount per Drive; others mount read-only snapshots that don't see later writes.
Cloudflare Sandbox: no volume; buckets mount in several sandboxes through s3fs, with cached metadata, copy-on-rename and no real locks.
Blaxel: a volume attaches to one sandbox; Agent Drive shares read-write in private preview, one region.
Northflank: multi read/write volumes; writers coordinate in the app.
Fly.io Sprites: each Sprite has its own disk.
Archil: one disk mounts read-write on up to 5,000 clients in shared or conditional mode; a client can check out a path for exclusive local-speed writes.

Snapshots, forks and branching

E2B: memory and filesystem snapshots, live fork; filesystem-only snapshots on request. Volumes have no snapshots.
Modal: filesystem, directory and memory (alpha) snapshots; Volumes not included.
Daytona: sandbox snapshots; VM sandboxes take hot snapshots with memory and fork copy-on-write. Volume snapshots not documented.
Vercel Sandbox: filesystem snapshots, Sandbox.fork, Drive snapshots and forks. No memory snapshots documented.
Cloudflare Sandbox: root filesystem snapshots in beta, without memory or mounts; directory backups to R2.
Blaxel: memory, process and file snapshots and forks, in private preview.
Northflank: manual volume backups and clones.
Fly.io Sprites: filesystem checkpoints, restored in place.
Archil: a checkpoint takes about 13 ms and a writable branch about 33 ms, at any disk size. Archil sandboxes fork by branching their root disk.

Bringing your own bucket

E2B: s3fs, gcsfuse or blobfuse2 in a custom template.
Modal: S3, R2 and GCS mounts built on Mountpoint for Amazon S3: no appends, random writes or renames.
Daytona: FUSE tools for S3, R2, Tigris, GCS or Azure Blob; Volumes stay on Daytona's store.
Vercel Sandbox: a FUSE driver such as Mountpoint for Amazon S3; Drives are Vercel-managed.
Cloudflare Sandbox: S3Mount mounts any S3-compatible bucket or prefix, credentials held by the Worker.
Blaxel: volumes can't be backed by S3; otherwise not documented.
Northflank: S3-compatible buckets via FUSE.
Fly.io Sprites: not documented.
Archil: a disk syncs both ways with S3, GCS, R2 or S3-compatible buckets, with full POSIX on top.

Open data formats

Cloudflare Sandbox: bucket mounts are one object per file; backups are .tar.zst in R2; snapshot format not documented.
Blaxel: Agent Drive has an S3-compatible endpoint; storage format not documented.
Modal: Volumes are readable outside Modal through its CLI and SDK; format not documented.
E2B, Daytona, Vercel Sandbox, Northflank and Fly.io Sprites: format not documented.
Archil: on a bucket-synced disk each file is an ordinary object at its path. Archil-managed disks export over the S3 API. See data ownership.

Mounting an external disk such as Archil

E2B: yes, FUSE in a custom template. Guide.
Modal: yes, in VM sandboxes (runtime="vm"); other runtimes use the Archil SDK. Guide.
Daytona: yes, in a default sandbox. Guide.
Vercel Sandbox: yes, FUSE is supported. Guide.
Cloudflare Sandbox: yes, FUSE is supported. Guide.
Fly.io Sprites: yes, as a Sprite service. Guide.
Blaxel and Northflank: not documented; use the disk's S3 API or SDKs instead.

Where Archil fits

Keep compute where it runs today and put shared, branchable data on an Archil disk. The same disk mounts in several providers' sandboxes, on Kubernetes through the CSI driver, on any Linux server and in Archil's own sandboxes, and your backend reads it over S3.

Sandbox storage compared

Which storage fits?

Where the data lives

Measured

Create a 4 KiB file and make it durable

npm ci, 10,538 files, from a local cache

Delete that node_modules tree

Write 1 GiB sequentially and make it durable

Read that 1 GiB from a new sandbox

Create a 4 KiB file and make it durable

Write 1 GiB sequentially and make it durable

Read that 1 GiB from a new sandbox

Create a 4 KiB file and fsync it

npm ci, 10,538 files, from a local cache

Delete that node_modules tree

Write 1 GiB sequentially and fsync

Read that 1 GiB from a new sandbox

Create a 4 KiB file and fsync it

npm ci, 10,538 files, from a local cache

Write 1 GiB sequentially and fsync

Read that 1 GiB with the page cache dropped

Full comparison

In detail

Where Archil fits

Compare one by one