ARCHIL
All comparisons

Archil vs Modal

Pick Modal for serverless Python compute, especially GPUs, with Volumes for data written in batches and reloaded between steps. Pick Archil when many sandboxes share files live, each attempt needs a millisecond branch, or agents need renames and in-place edits on your own bucket; an Archil disk mounts in Modal's VM sandboxes and is reachable from Modal functions through the SDK.

Where Archil stands out

  • Shared without reloads

    Clients see others' changes as caches refresh; a Modal Volume needs a reload with no files open.

  • Full POSIX on your bucket

    Renames, appends and random writes work on a synced bucket; Modal's Mountpoint-based bucket mounts don't support them.

  • Branches in milliseconds

    Checkpoint and branch a whole disk in tens of milliseconds; Modal's sandbox snapshots skip mounted Volumes.

Archil and Modal, side by side

What it is
Archil: Persistent disks (POSIX and S3 API) plus Firecracker sandboxes on a disk
Modal: Serverless functions, GPUs and sandboxes
Sandbox isolation
Archil: Firecracker microVM
Modal: gVisor by default, or a VM runtime
When a sandbox ends
Archil: Disks kept; pause keeps memory; sessions pause after 24 hours
Modal: Up to 24 hours; state kept in Volumes or snapshots (30-day default expiry)
One store shared by many sandboxes
Archil: Yes, read-write; changes appear as caches refresh
Modal: Yes; readers reload, last write wins
Snapshots and forks
Archil: Checkpoint 13 ms, branch 33 ms (p50), any size; sandbox fork
Modal: Filesystem, directory and memory snapshots (memory is alpha); Volumes excluded
Your own bucket
Archil: Two-way sync with S3, GCS or R2, full POSIX
Modal: S3, R2 and GCS mounts on Mountpoint: no appends, random writes or renames
Read data from outside
Archil: S3-compatible API and SDKs
Modal: Modal CLI and Python SDK
Billing model
Archil: Active storage per GiB-month; sandbox CPU and memory per hour
Modal: Per second for CPU, memory and GPU; Volumes per GiB-month

Where the data lives

Modal Volume
ModalsandboxModalsandboxModalsandboxModal Volumecommits with sync or on exitread-writereload to see

Many sandboxes mount one Volume. Readers reload to see commits; last write wins.

Archil disk
ModalsandboxArchilsandboxAny 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 Modal sandbox

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
Another sandbox sees a new file
ArchilAfter about 28 s with default client caching, or about 70 ms when the reader runs archil invalidate-cache before looking
Modal VolumeNot within 60 s: a running sandbox needs a reload to see another sandbox's commit
Data survives deleting the sandbox
ArchilYes: the 1 GiB file read back intact in 3 new sandboxes
Modal VolumeYes: the 1 GiB file read back intact in 3 new sandboxes
Fork the stored data
ArchilCheckpoint, branch and mount the branch in about 1 s, with the 1 GiB file intact
Modal VolumeNot supported: sandbox snapshots don't include Volumes
Create the storage
Archil0.14 s (median of 5, API call from San Francisco)
Modal Volume0.24 s (median of 5, API call from San Francisco)
Attach it to a running sandbox
ArchilInstall the client in 6.4 s, then mount in 111 ms (medians of 5 new sandboxes)
Modal VolumeVolumes are attached when the sandbox is created

How they differ

Architecture

Modal runs functions, images and sandboxes defined in Python (JavaScript and Go SDKs for sandboxes), with GPUs. It recommends the VM runtime for FUSE and Docker. Volumes are a distributed file system, not a block device.

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 Archil, Modal VM sandboxes and backend services.

Data durability and persistence

Modal sandboxes default to 5 minutes. Memory snapshots expire after 7 days; filesystem snapshot expiry is configurable. Volume writes commit every few seconds and when the sandbox ends.

An Archil write is durable when fsync returns, designed for 99.999% durability across Availability Zones. A session pauses after 24 hours with its processes intact.

Sharing and branching

Volumes v2 handles hundreds of concurrent writers, read-write or read-only. Reload works only with no open files, and there's no distributed locking.

Archil uses shared or conditional mode for up to 5,000 clients; changes appear within seconds, or at once with archil invalidate-cache. A client can check out a path for exclusive writes. See checkpoints and branches.

Bucket access and data format

Modal's bucket mounts inherit Mountpoint's limits: no appends, offset writes or renames.

A disk synced to your bucket supports standard POSIX operations, keeps each file as an ordinary object at its path, and caches active data on Archil's SSDs.

Pricing model

Modal: CPU and memory per second at the greater of request and use, GPUs per second, Volumes per GiB-month after a free allowance, egress per GiB. See Modal 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

In a VM sandbox (runtime="vm"), install the Archil client, keep the mount token in a Modal Secret and mount at /mnt/archil. Default-runtime functions and sandboxes can't mount FUSE and use the Archil Python SDK. See the Modal guide.

Which one should you use?

Use Modal when

  • GPUs for training, inference or evaluation
  • Python-defined compute that scales without infrastructure
  • batch-written files that readers reload between steps

Use Archil when

  • agents build on each other's files while they work
  • each attempt needs its own branch, in milliseconds
  • renames, appends and in-place edits on your own bucket
  • files and processes kept past a 24-hour session

Use both: Modal for GPUs and functions, Archil for a shared, branchable disk.

Questions people ask

More comparisons

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