> ## Documentation Index
> Fetch the complete documentation index at: https://docs.archil.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Limits

> Current hard limits for Archil disks, files, sandboxes, and the S3 API, and the highest load observed in production.

These are Archil's current limits. Most can be raised. If a limit or the performance below is in your way, tell us
at [support@archil.com](mailto:support@archil.com) and we'll prioritize it.

Every latency row can be rerun on your own account with the script in [Reproduce these numbers](#reproduce-these-numbers).

See [Verify Archil yourself](https://docs.archil.com/details/verify) for other checks.

The Seen column isn't a cap. It's the highest value Archil production has recorded from July 2025 to October 2026.
Rates are averaged over one minute.

## Disks and files

| Limit | Current | Seen |
| - | - | - |
| Max file size | 1 PiB | |
| Max files in one directory | Unlimited | 80K+ |
| Max connected clients per disk | 5,000 | |
| Max connected clients, all disks | Unlimited | 32K+ |
| Max data sources per disk | 1 | |
| Max disk name length | 100 characters | |
| Max branch name length | 100 characters | |

Disk and branch names can use letters, digits, `-`, and `_`.

### Disks per plan

| Plan | Max disks per region | Seen |
| - | - | - |
| Free | 5 | |
| Developer | 1,000 | |
| Team | 25,000 | |
| Enterprise | Unlimited | 100K+ |

### Disks synchronized with a data source

A disk synchronized with a [data source](https://docs.archil.com/concepts/data-sources.md) keeps each file as a normal object in your bucket,
so these limits apply instead.

| Limit | Current |
| - | - |
| Max file size | 5 TiB |
| Max path or S3 key length | 1,024 bytes |
| Max entries in one directory listed over S3 | 100,000 |

The path length includes the bucket prefix, if the disk uses one.

## Throughput and requests

| Limit | Current | Seen |
| - | - | - |
| Max write throughput per disk | 1 GB/s | 620 MB/s |
| Max read throughput per disk | Unlimited | 5.9 GB/s |
| Max control-plane API request body | 512 KiB | |

## Latency

| Operation | p50 | p95 |
| - | - | - |
| Create a disk | 9.3 ms | 11 ms |
| Checkpoint a disk | 13 ms | 19 ms |
| Branch from a checkpoint | 33 ms | 36 ms |
| Delete a disk | 8.1 ms | 10 ms |
| Mount a disk | 50 ms | 58 ms |
| 4 KiB read, client cache miss | 0.50 ms | 0.75 ms |
| 4 KiB write, `O_SYNC` | 2.0 ms | 8.2 ms |

Checkpoint and branch times don't depend on disk size. A client cache miss is served from the file server's
[cache](https://docs.archil.com/details/caching.md). Data that has to come from the data source takes longer, typically 10 to 30 ms for Amazon S3.
An `O_SYNC` write returns once the file server has made it durable. We measured these on October 27, 2026 from a c7gn.2xlarge in AWS `us-east-1`, using the script in
[Reproduce these numbers](#reproduce-these-numbers).

## Sandboxes

| Limit | Current |
| - | - |
| Max vCPU per sandbox | 32 |
| Max memory per sandbox | 64 GiB |
| Max session length | 24 hours |
| Default idle timeout | 30 minutes |
| Max idle timeout | 24 hours |
| Default concurrent commands per sandbox | 32 |
| Max concurrent commands per sandbox | 256 |

A sandbox pauses when its session reaches 24 hours or its idle timeout.

## Serverless execution

| Limit | Current |
| - | - |
| vCPU per command | 2 |
| Memory per command | 4 GiB |
| Max command duration | 5 minutes |
| Max command length | 100 KiB |

## S3 API

| Limit | Current |
| - | - |
| Max `PutObject` size | 5 GiB |
| Max object size with multipart upload | 5 TiB |
| Max parts per upload | 10,000 |
| Min part size | 5 MiB |
| Max part size | 5 GiB |
| Max `CopyObject` source size | 5 GiB |
| Max keys per `ListObjectsV2` page | 1,000 |
| Max keys per `DeleteObjects` request | 1,000 |
| Default share URL lifetime | 24 hours |
| Max share URL lifetime | 7 days |

The last part of a multipart upload can be smaller than 5 MiB.

## Reproduce these numbers

You can measure every latency row yourself with one script that uses the public API, the `archil` CLI, and `fio`.
Run it in the same cloud region as the disk, since a cross-region round trip is larger than most of these figures.

> **Script and our results**
>
> It needs `curl`, `jq`, `fio`, `journalctl`, the `archil` CLI, and an [API key](https://docs.archil.com/api-reference/introduction.md#authentication)
> in `ARCHIL_API_KEY`. Set `API` to your region's [control plane endpoint](https://docs.archil.com/api-reference/introduction.md#base-url) and
> `REGION` to match, then run it as root with `sudo -E bash latency.sh`. It takes about two minutes, creates disks named
> `latency-test-*`, and deletes them when it finishes.
>
> ```bash latency.sh theme={null}
> #!/usr/bin/env bash
> set -euo pipefail
> API="https://<control-plane-endpoint>"
> REGION=aws-us-east-1
> MNT=/mnt/latency-test
> N=40
> T=$(date +%s)
> cd "$(mktemp -d)"
>
> pct() { sort -n | awk -v p=$1 '{ a[NR] = $1 } END { print a[int((NR * p + 99) / 100)] }'; }
> stats() { local v=$(cat); echo "p50 $(pct 50 <<< "$v"), p95 $(pct 95 <<< "$v")"; }
> ms() { local s=$(date +%s%N); "$@" > /dev/null; echo $(( ($(date +%s%N) - s) / 1000000 )); }
> api() { curl -sf -H "Authorization: Bearer $ARCHIL_API_KEY" -H 'Content-Type: application/json' "$@"; }
> fiostat() { jq -r ".jobs[0].$1.clat_ns.percentile | \"p50 \(.[\"50.000000\"] / 1e6), p95 \(.[\"95.000000\"] / 1e6)\""; }
>
> # Create and delete: request time after the TLS handshake
> for i in $(seq $N); do
>   api -o create.json -w '%{time_appconnect} %{time_total}\n' -X POST "$API/api/disks" \
>     -d "{\"name\":\"latency-test-$T-$i\"}" >> create.txt
>   api -o /dev/null -w '%{time_appconnect} %{time_total}\n' -X DELETE \
>     "$API/api/disks/$(jq -r .data.diskId create.json)" >> delete.txt
> done
> echo "create ms: $(awk '{ print ($2 - $1) * 1000 }' create.txt | stats)"
> echo "delete ms: $(awk '{ print ($2 - $1) * 1000 }' delete.txt | stats)"
>
> api -o disk.json -X POST "$API/api/disks" -d "{\"name\":\"latency-test-$T\"}"
> DISK=$(jq -r .data.diskId disk.json)
> export ARCHIL_MOUNT_TOKEN=$(jq -r '.data.authorizedUsers[0].token' disk.json)
> mkdir -p $MNT
>
> # Mount: wall time of `archil mount`, and the time the client logs for itself
> START=$(date '+%F %T')
> for i in $(seq $N); do
>   ms archil mount -q $DISK $MNT --region $REGION >> mount.txt
>   archil unmount $MNT > /dev/null
> done
> echo "mount ms, wall: $(stats < mount.txt)"
> echo "mount ms, client log: $(journalctl -t "archil-$DISK" --since "$START" \
>   | grep -o 'Mounted disk in [0-9]*' | awk '{ print $4 }' | stats)"
>
> # Checkpoint and branch: wall time of the CLI
> archil mount -q $DISK $MNT --region $REGION > /dev/null
> for i in $(seq $N); do ms archil checkpoints create $MNT cp-$i >> checkpoint.txt; done
> for i in $(seq $N); do
>   ms archil branches create $DISK br-$i --from-checkpoint cp-$i --region $REGION >> branch.txt
> done
> echo "checkpoint ms: $(stats < checkpoint.txt)"
> echo "branch ms: $(stats < branch.txt)"
>
> # Durable 4 KiB writes, one at a time
> FIO="fio --name=t --bs=4k --iodepth=1 --direct=1 --time_based --runtime=30 --output-format=json"
> echo "O_SYNC write ms: $($FIO --filename=$MNT/w --size=1G --rw=randwrite --sync=1 | fiostat write)"
>
> # 4 KiB reads that miss the client cache: a fresh mount has a cold client cache, and the server
> # still holds the file it just received. Read-ahead off so no read hits locally.
> fio --name=fill --filename=$MNT/r --size=4G --rw=write --bs=1M --end_fsync=1 > /dev/null
> archil unmount $MNT > /dev/null
> archil mount -q $DISK $MNT --region $REGION --read-ahead 0 > /dev/null
> echo "cache-miss read ms: $($FIO --filename=$MNT/r --size=4G --rw=randread | fiostat read)"
>
> archil unmount $MNT > /dev/null
> api -o /dev/null -X DELETE "$API/api/disks/$DISK"
> ```
>
> Our run, from a c7gn.2xlarge in AWS `us-east-1` on October 27, 2026:
>
> | Script line | p50 | p95 |
> | - | - | - |
> | `create ms` | 9.3 ms | 11 ms |
> | `delete ms` | 8.1 ms | 10 ms |
> | `mount ms, client log` | 41 ms | 49 ms |
> | `mount ms, wall` | 50 ms | 58 ms |
> | `checkpoint ms` | 13 ms | 19 ms |
> | `branch ms` | 33 ms | 36 ms |
> | `O_SYNC write ms` | 2.0 ms | 8.2 ms |
> | `cache-miss read ms` | 0.50 ms | 0.75 ms |
>
> * Create and delete leave out the TLS handshake, about 10 ms on a new connection.
> * `mount ms, wall` includes starting the CLI. The client log line doesn't.
> * Checkpoint and branch are CLI wall times, so they include starting the CLI, and branch also opens a new TLS
>   connection.
> * The read test mounts with `--read-ahead 0`. With the default, random reads also pull in neighboring blocks, so about
>   a third of them hit the client cache.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.