Archil vs Daytona

Pick Daytona for sandboxes with storage built in: stopped sandboxes kept until deleted, VM sandboxes that pause and fork with memory, and shared Volumes at no extra charge. Pick Archil when shared storage must run git, installs or SQLite at local-disk speed, branch in milliseconds, live in your own bucket or move between providers; an Archil disk mounts in a default Daytona sandbox, and Daytona's docs cover it.

Where Archil stands out

Local-disk speed on shared storage
Checked-out paths acknowledge writes locally, so git, npm and SQLite run fast; Daytona says Volumes are slower than local disk.
Branches in milliseconds
Checkpoint in about 13 ms and branch in about 33 ms, at any size.
Portable across providers
One disk mounts in Daytona, E2B, Modal, Vercel and Archil sandboxes, and reads over S3.

Archil and Daytona, side by side

	Archil	Daytona
What it is	Persistent disks (POSIX and S3 API) plus Firecracker sandboxes on a disk	Container or VM sandboxes with Volumes and snapshots
Isolation	Firecracker microVM	Containers by default; Linux VM and Windows sandboxes
When compute stops	Disks kept; pause keeps memory	Files kept; VMs pause with memory; archived after 7 days, kept until deleted
One store shared by many sandboxes	Yes, read-write, with exclusive checkouts	Yes, read-write; last write wins
Write performance on shared storage	Local-disk speed on checked-out paths	Slower than local disk; not for database files
Snapshots and forks	Checkpoint 13 ms, branch 33 ms (p50), any size; sandbox fork	Sandbox snapshots; VM hot snapshots and forks with memory
Your own bucket	Two-way sync with S3, GCS, R2 or S3-compatible	FUSE tools: mount-s3, gcsfuse, blobfuse2
Works outside the provider	Any sandbox, any Linux machine, and S3	Daytona sandboxes
Billing model	Active storage per GiB-month; sandbox CPU and memory per hour	Per second for vCPU, memory and storage; Volumes included

What it is: Archil: Persistent disks (POSIX and S3 API) plus Firecracker sandboxes on a disk; Daytona: Container or VM sandboxes with Volumes and snapshots
Isolation: Archil: Firecracker microVM; Daytona: Containers by default; Linux VM and Windows sandboxes
When compute stops: Archil: Disks kept; pause keeps memory; Daytona: Files kept; VMs pause with memory; archived after 7 days, kept until deleted
One store shared by many sandboxes: Archil: Yes, read-write, with exclusive checkouts; Daytona: Yes, read-write; last write wins
Write performance on shared storage: Archil: Local-disk speed on checked-out paths; Daytona: Slower than local disk; not for database files
Snapshots and forks: Archil: Checkpoint 13 ms, branch 33 ms (p50), any size; sandbox fork; Daytona: Sandbox snapshots; VM hot snapshots and forks with memory
Your own bucket: Archil: Two-way sync with S3, GCS, R2 or S3-compatible; Daytona: FUSE tools: mount-s3, gcsfuse, blobfuse2
Works outside the provider: Archil: Any sandbox, any Linux machine, and S3; Daytona: Daytona sandboxes
Billing model: Archil: Active storage per GiB-month; sandbox CPU and memory per hour; Daytona: Per second for vCPU, memory and storage; Volumes included

Where the data lives

Daytona Volume

Many sandboxes mount one Volume read-write and see writes at once. Last write wins; not for database files.

Archil disk

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

Measured inside a Daytona sandbox

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

npm ci, 10,538 files: Archil1.85 s on an Archil disk in a Modal sandbox; Daytona VolumeDidn't finish within 15 minutes in 2 attempts
Another sandbox sees a new file: ArchilAbout 70 ms when the reader runs archil invalidate-cache (measured in Modal); Daytona VolumeAbout 360 ms (median of 10)
Data survives deleting the sandbox: ArchilYes; Daytona VolumeYes: the 1 GiB file read back intact in 3 new sandboxes
Fork the stored data: ArchilCheckpoint and branch the disk; Daytona VolumeNot supported: volume snapshots aren't documented
Create the storage: Archil0.10 s (median of 10, API call from San Francisco); Daytona Volume4.2 s until ready (median of 10, API call from San Francisco)

How they differ

Architecture

Daytona has SDKs for TypeScript, Python, Ruby, Go and Java. Container sandboxes share the host kernel, each sandbox disk is 3 GiB by default, and Volumes are a FUSE mount of Daytona's S3-compatible object store.

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 Daytona, Archil and your backend.

Data durability and persistence

Container sandboxes auto-stop after 15 minutes idle by default. Volume data and snapshots survive deleting the sandbox; ephemeral sandboxes, including all GPU sandboxes, are deleted when they stop.

An Archil write is durable when fsync returns, designed for 99.999% durability across Availability Zones. Disks grow and shrink with the data.

Sharing and branching

A Daytona sandbox can mount a Volume subpath. Volumes aren't transactional and don't suit block-storage workloads such as database tables.

Archil uses shared or conditional mode for up to 5,000 clients. See checkpoints and branches.

Bucket access and data format

Daytona documents FUSE mounts for S3, R2, Tigris, GCS and Azure Blob, plus file systems including Archil.

On a disk synced to your bucket, each file is an ordinary object at its path, readable by aws s3, Spark or Athena, with standard POSIX operations on top.

Pricing model

Daytona: per second for vCPU, memory and storage, storage per GiB after a free allotment, GPUs priced separately. See Daytona 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 a default sandbox, no privileged mode needed, and mount at /mnt/archil. See the Daytona guide and Daytona's external storage docs.

Which one should you use?

Use Daytona when

all your sandboxes run on Daytona
agents pass files, and last-write-wins is acceptable
no databases on the shared volume
included storage matters more than branching or bucket access

Use Archil when

shared storage at local-disk speed for git, installs or SQLite
each attempt needs its own branch, in milliseconds
data in your own bucket, or read over S3
the workspace moves between providers

Use both: Daytona for sandboxes, Archil for the shared workspace.

Questions people ask

More comparisons

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