Archil vs Tigris

Pick Tigris for one global S3-compatible object store with no egress fees and zero-copy bucket forks. Pick Archil when agents need a real file system (git, installs, SQLite, in-place edits) shared by many sandboxes, with millisecond branches; it can sync to a Tigris bucket.

Where Archil stands out

A real file system
Random writes, appends, directory renames and links, so git, package managers and SQLite just work.
Many sandboxes on one workspace
One disk mounts read-write on up to 5,000 clients.
Works with Tigris
Tigris is a tested S3-compatible store a disk can sync to.

Archil and Tigris, side by side

	Archil	Tigris
What it is	Managed POSIX file system with an S3 API, plus Firecracker sandboxes	Managed, globally distributed S3-compatible object store
Primary interface	FUSE mount, S3 API, SDKs	S3 API; TigrisFS for FUSE mounts
File system semantics	Random writes, appends, atomic renames including directories, symbolic and hard links	TigrisFS documents POSIX permissions, special files and symbolic links
Many writers on one tree	Yes, up to 5,000 clients, via delegations or conditional mode	Objects via S3 API; TigrisFS documents no multi-client consistency model
Snapshots and branches	Whole-disk checkpoint p50 13 ms, branch p50 33 ms	Bucket snapshots and zero-copy forks, with merge and rebase in the CLI
Where data lives	Your S3, GCS, R2 or S3-compatible bucket (including Tigris), or Archil-managed	Tigris regions: global, multi-region, dual-region or single-region buckets
Consistency	Strong for committed writes, file system and S3 API	Strong within a region; eventual across regions for global and dual-region buckets
Run code next to the data	Sandboxes and serverless execution on the disk	Not included; documents pairing forks with sandbox providers
Billing model	Active storage per GiB-month; sandbox CPU and memory per hour	Storage per GB-month by tier plus requests; no egress fees

What it is: Archil: Managed POSIX file system with an S3 API, plus Firecracker sandboxes; Tigris: Managed, globally distributed S3-compatible object store
Primary interface: Archil: FUSE mount, S3 API, SDKs; Tigris: S3 API; TigrisFS for FUSE mounts
File system semantics: Archil: Random writes, appends, atomic renames including directories, symbolic and hard links; Tigris: TigrisFS documents POSIX permissions, special files and symbolic links
Many writers on one tree: Archil: Yes, up to 5,000 clients, via delegations or conditional mode; Tigris: Objects via S3 API; TigrisFS documents no multi-client consistency model
Snapshots and branches: Archil: Whole-disk checkpoint p50 13 ms, branch p50 33 ms; Tigris: Bucket snapshots and zero-copy forks, with merge and rebase in the CLI
Where data lives: Archil: Your S3, GCS, R2 or S3-compatible bucket (including Tigris), or Archil-managed; Tigris: Tigris regions: global, multi-region, dual-region or single-region buckets
Consistency: Archil: Strong for committed writes, file system and S3 API; Tigris: Strong within a region; eventual across regions for global and dual-region buckets
Run code next to the data: Archil: Sandboxes and serverless execution on the disk; Tigris: Not included; documents pairing forks with sandbox providers
Billing model: Archil: Active storage per GiB-month; sandbox CPU and memory per hour; Tigris: Storage per GB-month by tier plus requests; no egress fees

How they differ

Architecture

Tigris uses a global cache, replication, and FoundationDB metadata behind one global S3 endpoint, moving data toward where it's read. TigrisFS keeps each file as a plain object; Cloud Disk, a block device in a bucket, is in beta.

Archil serves disks from SSD replicated across Availability Zones, with a bucket behind. An app can write over S3 and an agent read the same file through a path.

File access for agents

Over an object API, agent file work becomes whole-object uploads and downloads. Tigris documents a TigrisFS mount per sandbox, with write-back and metadata caches.

Archil supports standard POSIX operations, and delegations acknowledge writes locally, which keeps npm install fast.

Data durability and consistency

On Tigris, multi-region and single-region buckets are strongly consistent; a cross-region read of a global or dual-region bucket can briefly return an older version. Conditional operations always see the latest state.

On Archil, a write is durable when fsync returns, designed for 99.999% durability across Availability Zones; synced disks reach the bucket in the background.

Sharing and branching

Tigris snapshots a bucket in constant time, bills forks only for new data, and has guides for one fork per agent. Snapshot-enabled buckets can't use lifecycle or expiration rules.

Each Archil branch mounts as a normal file system, and one disk can also be shared read-write instead of copied.

Pricing model

Tigris bills storage by tier, Class A and B requests, cold-tier retrieval and notifications; transfer is free and pricing is the same everywhere. See Tigris pricing.

Archil bills active data per GiB-month (lower archive rate on Archil-managed disks) and sandboxes per vCPU-hour and GiB-hour; synced disks also pay the bucket's provider. See Archil pricing.

Using them together

A Tigris bucket can back an Archil disk (data sources). Agents mount POSIX with caching, sharing and branches, while apps and CDNs read the same objects from Tigris.

Which one should you use?

Use Tigris when

apps and agents use the S3 API and write objects whole
users or compute span regions and clouds
egress cost matters
you want bucket forks you can merge back

Use Archil when

agents need full POSIX for git, package managers, SQLite and edits
many sandboxes share one workspace
each attempt needs a mountable branch in milliseconds
agents need a sandbox next to the data

Choose both when Tigris holds the data and agents need a file system in front of it.

Questions people ask

More comparisons

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