ARCHIL
All comparisons

Archil vs E2B

Pick E2B for hosted sandboxes that pause with memory intact, fork a live sandbox in one call, and self-host from open source. Pick Archil when the data must outlive the sandbox, be shared by many sandboxes, branch in milliseconds or live in your own bucket; an Archil disk mounts inside an E2B sandbox, and E2B's docs list it.

Where Archil stands out

  • A disk that outlives the sandbox

    Files survive stop, pause, timeout and hardware failure; an E2B sandbox killed at its timeout loses its state.

  • Shared by many sandboxes at once

    One disk mounts read-write on up to 5,000 clients; E2B's Volumes are in private beta.

  • Branches in milliseconds, at any size

    Checkpoint in about 13 ms, branch in about 33 ms, one writable copy per attempt.

Archil and E2B, side by side

What it is
Archil: Persistent disks (POSIX and S3 API) plus Firecracker sandboxes on a disk
E2B: Firecracker sandboxes for agent code
Isolation
Archil: Firecracker microVM
E2B: Firecracker microVM
When compute stops
Archil: Root and mounted disks kept; pause keeps memory
E2B: Pause keeps memory and files indefinitely; default timeout kills the sandbox and its state
One store shared by many sandboxes
Archil: Yes, read-write
E2B: Volumes, private beta, with locking and stale-handle caveats
Snapshots and forks
Archil: Checkpoint 13 ms, branch 33 ms (p50), any size
E2B: Memory and filesystem snapshots, live fork, filesystem-only on request
Your own bucket
Archil: Two-way sync with S3, GCS, R2 or S3-compatible
E2B: s3fs, gcsfuse or blobfuse2 in a custom template
Read data without a sandbox
Archil: S3-compatible API and SDKs
E2B: Download Volume files through the SDK
Billing model
Archil: Active storage per GiB-month; sandbox CPU and memory per hour
E2B: Per second for provisioned vCPU and RAM while running

Where the data lives

Sandbox filesystem
E2BSandbox filesystemkept while the sandbox is pausedDeleted with the sandbox

Kept while paused. Lost when the sandbox is killed at timeout, the default. Volumes are in private beta.

Archil disk
E2BsandboxArchilsandboxAny 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 an E2B sandbox

E2B Volumes are in private beta and weren't enabled on the account used for these tests, so they aren't measured. The numbers below are for an Archil disk mounted in an E2B sandbox.

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.
Install the Archil client
Archil5.2 s (median of 5)
E2B VolumeNot measured: E2B Volumes are in private beta
Mount the disk
Archil131 ms (median of 5)
E2B VolumeNot measured
First 4 KiB read after mounting
Archil0.17 s (median of 5)
E2B VolumeNot measured

How they differ

Architecture

E2B sandboxes are built from templates and driven from the JavaScript or Python SDK. Storage is the sandbox disk plus Volumes, in private beta.

An Archil disk is an elastic POSIX file system, mounted over FUSE on any Linux machine and reachable over S3. Archil sandboxes boot from a disk, so the same files can follow an agent from an Archil sandbox to E2B to a laptop.

Data durability and persistence

E2B keeps a paused sandbox indefinitely; a killed one can't resume. You can set the timeout action to pause. Sessions run up to 1 hour on Hobby and 24 hours on Pro, and pausing resets the clock.

An Archil write is durable when fsync returns, designed for 99.999% durability and replicated across Availability Zones. Deleting a sandbox leaves its disks untouched, and disks grow and shrink with the data.

Sharing and branching

E2B's strength is forking compute: a snapshot of memory and files starts many sandboxes, and a fork copies a live one with its processes. Its Volume docs warn that locking can hang, read-only mounts aren't supported and heavy renames can leave stale handles.

Archil shares and forks data: shared or conditional mode for many writers, and checkpoints and branches that mount anywhere as independent disks.

Bucket access and data format

E2B documents FUSE drivers in a custom template: s3fs for S3 and R2, gcsfuse for GCS, blobfuse2 for Azure Blob.

On a disk synced to your bucket, each file is an ordinary object at its path, readable by aws s3, Spark or Athena. Active data is cached on Archil's SSDs; bucket sync is asynchronous, and the disk's own S3 API is strongly consistent.

Pricing model

E2B: per second while running, on plans with a monthly base fee; paused sandboxes aren't billed. See E2B 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 an E2B template and mount a disk at /mnt/archil. It survives the sandbox, other sandboxes can mount it at once, and your backend reads it over S3. See the E2B guide and E2B's Archil page.

Which one should you use?

Use E2B when

  • short sessions of untrusted code, where pausing with memory matters most
  • forking a running sandbox, processes included
  • self-hosting the open-source runtime

Use Archil when

  • the workspace must outlive the sandbox, timeouts included
  • many sandboxes or servers write the same files
  • each attempt needs its own branch, in milliseconds
  • data must live in your own bucket

Use both: E2B for compute, Archil for shared, branchable data.

Questions people ask

More comparisons

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