ARCHIL
All comparisons

Archil vs Vercel Sandbox

Pick Vercel Sandbox when your app runs on Vercel and you want Firecracker sandboxes in many regions that save files on stop, with Drives one sandbox writes at a time. Pick Archil when many sandboxes write the same files, each agent needs a millisecond branch, or data must live in your own bucket; an Archil disk mounts inside a Vercel sandbox over FUSE.

Where Archil stands out

  • Many writers at once

    One disk mounts read-write in many sandboxes; a Drive takes one writer.

  • Data in your own bucket

    Synced disks keep files as ordinary objects in S3, GCS or R2; Drives are Vercel-managed.

  • Memory kept on pause

    Archil sandboxes pause with memory and processes; Vercel snapshots cover files.

Archil and Vercel Sandbox, side by side

What it is
Archil: Persistent disks (POSIX and S3 API) plus Firecracker sandboxes on a disk
Vercel Sandbox: Firecracker sandboxes on the Vercel platform
Isolation
Archil: Firecracker microVM
Vercel Sandbox: Firecracker microVM
When compute stops
Archil: Disks kept; pause keeps memory
Vercel Sandbox: Filesystem snapshot on stop; expires 30 days after last use by default
One store shared by many sandboxes
Archil: Yes, read-write
Vercel Sandbox: One Drive writer; read-only point-in-time snapshots for others
Durable when fsync returns
Archil: Yes, replicated across Availability Zones (4.8 ms for a 4 KiB file)
Vercel Sandbox: No: snapshots and forks taken up to 30 s after fsync returned were missing the file
Size
Archil: Grows and shrinks with the data
Vercel Sandbox: 64 GB per sandbox; Drives 1 TiB default, 16 TiB quota, raisable
Snapshots and forks
Archil: Checkpoint 13 ms, branch 33 ms (p50), any size
Vercel Sandbox: Filesystem snapshots, Sandbox.fork, Drive snapshots and forks
Your own bucket
Archil: Two-way sync with S3, GCS, R2 or S3-compatible
Vercel Sandbox: FUSE driver such as Mountpoint for Amazon S3
Read data without a sandbox
Archil: S3-compatible API and SDKs
Vercel Sandbox: Through a mount in a sandbox
Billing model
Archil: Active storage per GiB-month; sandbox CPU and memory per hour
Vercel Sandbox: Active CPU, memory, creations, transfer, snapshots, Drive storage and I/O

Where the data lives

Vercel Drive
Vercel SandboxsandboxVercel SandboxsandboxVercel SandboxsandboxVercel Driveone region, Vercel-managedread-writeread-only snapshot

One sandbox mounts a Drive read-write. Others get read-only snapshots that miss later writes.

Archil disk
Vercel SandboxsandboxArchilsandboxAny LinuxserverArchil diskyour bucket or Archil-managedS3APIread-write from any provider · syncs to your bucket

Mounts read-write anywhere, outlives every sandbox, and is also an S3 bucket.

Measured inside a Vercel sandbox

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
Another sandbox sees a new file
ArchilAfter about 28 s with default client caching (a second sandbox mounted the same disk read-write)
Vercel DriveNot within 60 s: the second sandbox can only mount a read-only snapshot, fixed at mount time
Data survives deleting the sandbox
ArchilYes: the 1 GiB file read back intact in 3 new sandboxes
Vercel DriveYes: the 1 GiB file read back intact in 3 new sandboxes
A new reader right after fsync returns
ArchilIntact in 20 of 20 trials: an Archil disk mounted in a new sandbox
Vercel DriveMissing in 10 of 10 Drive snapshots and 11 of 11 forks taken at once; still missing in 7 of 10 snapshots and 9 of 10 forks 30 s later; intact from 60 s
Fork the stored data
ArchilCheckpoint, branch and mount the branch in about 0.9 s, with the 1 GiB file intact
Vercel DriveA fork taken within 30 s of fsync usually lacked the newest file (above)
Create the storage
Archil0.09 s (median of 5, API call from San Francisco)
Vercel Drive0.14 s (median of 5, API call from San Francisco)
Attach it to a running sandbox
ArchilMount in 51 ms (median of 5)
Vercel DriveDrives are attached when the sandbox session starts

How they differ

Architecture

Vercel Sandbox is driven from @vercel/sandbox, the Python SDK or the sandbox CLI, in Vercel's regions next to your app.

An Archil disk is an elastic POSIX file system, mounted over FUSE anywhere and reachable over S3. Archil sandboxes boot from a disk, so files move between Vercel, Archil and your backend.

Data durability and persistence

A Drive write is not durable when fsync returns: the sandbox's local NVMe acknowledges it in 0.18 ms, and in our test snapshots and forks taken up to 30 s later didn't contain it. Snapshot expiry can be set to unlimited, and sandboxes that can't resume are removed after 14 days idle. Sessions run up to 45 minutes on Hobby and 24 hours on Pro and Enterprise, reset on each resume. Drives persist until deleted.

An Archil write is durable when fsync returns, designed for 99.999% durability across Availability Zones. Disks survive stop, pause and hardware failure.

Sharing and branching

A Drive fork copies its data into a new Drive.

Archil uses shared or conditional mode for up to 5,000 clients on the same live disk. See checkpoints and branches.

Bucket access and data format

Vercel recommends a FUSE mount when data must live with an external provider.

On a disk synced to your bucket, each file is an ordinary object at its path, with renames, random writes, appends and symlinks on top and active data cached on Archil's SSDs. A Vercel Function can read a disk over S3 without a sandbox.

Pricing model

Vercel bills Active CPU (time in use), and Hobby includes a free allotment. See Vercel Sandbox pricing.

Archil: active data per GiB-month with a lower archive rate, sandboxes per vCPU-hour and GiB-hour; synced disks also pay your cloud for the bucket. See Archil pricing.

Using them together

Install the Archil client in the sandbox and mount at /mnt/archil. The Vercel Sandbox guide maps Archil regions to Vercel regions.

Which one should you use?

Use Vercel Sandbox when

  • your app runs on Vercel, on one bill
  • sandboxes in many regions near users
  • one writer, with read-only views for others
  • one sandbox's writes at local NVMe speed, acknowledged before they're durable: npm ci took 2.2 s on a Drive, 3.3 s on Archil

Use Archil when

  • many sandboxes or servers write the same files
  • each attempt needs its own branch, in milliseconds
  • data in your own bucket, or read over S3
  • paused sandboxes keep memory and processes

Use both: Vercel Sandbox for agents, Archil for shared, branchable data.

Questions people ask

More comparisons

Or see every comparison, grouped by sandboxes, file systems and object storage.