Skip to main content
The storage numbers on our compare pages for Modal, Vercel Sandbox, Daytona, and sandbox providers, including Fly.io Sprites, come from the script on this page. In each provider’s sandbox, we mounted the provider’s own storage and an Archil disk side by side and ran the same script against both, so the compute is identical and only the storage differs. You can run it on your own accounts with the recipes below.

What it measures

The recipes run the visibility, provisioning, and fork steps once; we repeated them for the counts above. Daytona visibility and provisioning used 10 rounds. Everything except provisioning, the branch call, and the branch mount is timed inside the sandbox, so the provider’s API round trips aren’t counted. Setup is untimed: the script writes a 1 GiB random source file to local disk, resolves the lockfile, and fills the npm cache, which is its only network use. Pinned to a registry date, npm resolves the same 501 packages every time. Some stores acknowledge fsync before data leaves the host. An Archil fsync returns once the write is durable on Archil’s replicated storage. Our compare pages mark the rows where the other store’s write was not durable when fsync returned, and Vercel Drive fsync durability tests it directly.

The script

Save it as bench.mjs. It needs Node 18 or later and npm, and nothing else.
bench.mjs
It writes under <dir>/archil-bench/ and prints one JSON object per run:
If a store persists only on an explicit commit, pass the commit command with --commit; it runs inside every timed write. A Modal Volume needs --commit 'sync /vol'.

Mount an Archil disk

Create the disk from your own machine, so your API key stays there. The sandbox only gets the disk’s mount token, which grants access to that disk alone:
Then, in the sandbox, as root:
Put the disk in the Archil region closest to the sandbox. We publish Archil side by side only where a TCP connection from the sandbox to Archil took about 20 ms or less; Daytona’s us region and Fly.io Sprites were farther away, so those pages show the provider’s storage alone.

Recipes

Each recipe creates the stores, runs the script, and deletes everything it created.

Vercel Sandbox and Vercel Drive

Reproduces every row on archil.com/compare/vercel-sandbox: one sandbox with 2 vCPUs in pdx1 (AWS us-west-2), a Vercel Drive in pdx1, and an Archil disk in aws-us-west-2.
vercel.ts
A Drive takes one read-write mount at a time. The visibility sandbox mounts a read-only snapshot of it, which is fixed when the sandbox starts, so it doesn’t see the new file. It mounts the Archil disk with --shared. Reproduces archil.com/compare/modal: a VM sandbox (runtime="vm") with 2 CPUs and 4 GiB in us-west, a Modal Volume (v2), and an Archil disk in aws-us-west-2. For the fork row, add the fork step from the Vercel recipe.
modal_bench.py
A running Modal sandbox sees another sandbox’s Volume commit only after a reload, so the Volume visibility round is expected to reach its 60 s limit.

Daytona Volume

Reproduces archil.com/compare/daytona: sandboxes from the default snapshot (1 vCPU, 1 GiB) in Daytona’s us region, each with a Daytona Volume at /vol. To add an Archil disk, mount it as in the Daytona guide and run the script against /mnt/archil too.
daytona_bench.py
In our runs, npm ci on a Daytona Volume didn’t finish within 15 minutes. The script stops it after 15 minutes (NPM_TIMEOUT_S changes the limit) and reports timed_out.

Fly.io Sprites

Reproduces the Fly.io Sprites results on archil.com/compare/sandbox-providers: one Sprite measuring its own persistent disk. A Sprite’s disk can’t attach to another Sprite, so the cold read drops the page cache in the same Sprite, and the visibility row doesn’t apply. To add an Archil disk, mount it as in the Sprites guide.

If your results differ

Email support@archil.com with the script output, the provider, and the regions of the sandbox and the disk.