Yes, on Archil’s Enterprise plan. Archil checkpoints and branches a disk in tens of milliseconds regardless of its size, and for a disk that synchronizes with your own S3, GCS or R2 bucket (bring your own bucket), checkpoints and branching are an Enterprise feature. Disks on Archil-managed storage, the default, branch with no bucket of your own.
Can a file system synced to your own S3 bucket be branched?
Archil’s current Data sources page says checkpoints and branching for bring your own bucket (BYOB) are available on Enterprise. Older text in Archil’s docs said disks that synchronize with a backing data source did not support those operations. That restriction is out of date.
Archil has BYOB on every paid plan: Developer, Team and Enterprise. Branching a BYOB disk, however, needs Enterprise. Owning the bucket is only half the question. A team can have a paid plan that supports synchronization to its own bucket without having the feature needed to fork that disk into independent experiments.
That distinction separates two decisions that can otherwise get tangled together. One is whether files should synchronize to a bucket the team owns. The other is whether the disk needs checkpoints and writable branches. For a workflow that requires both, Enterprise is the relevant plan. The old wording explains why a search result might still say otherwise.
What checkpoints and branches are
A checkpoint is a named, point-in-time snapshot of a disk, and the state it references never changes. A branch is an independent, writable fork that starts from a checkpoint. The checkpoint preserves the starting point. The branch is a place to make changes without changing the source or sibling branches.
This lets experiments start from the same state and end with different results. Each branch can be mounted on a different machine, and two branches of one disk can be mounted on separate VMs at the same time. Each experiment gets its own writable copy. Writes in one experiment do not affect its sibling, so the branches can diverge without rewriting each other’s files.
Archil’s limits page lists 13 ms to checkpoint and 33 ms to branch at p50, independent of disk size. Those figures describe the checkpoint and branch operations. They are not timings for the whole experiment, nor does p50 promise that every invocation takes exactly that long.
Branches also form a tree, like Git branches and commits. A branch can be checkpointed, and another branch can start from that checkpoint using --from-branch. The first fork need not be the last. This allows a later experiment to start from a checkpoint on an existing branch rather than always returning to the original starting state. Archil’s branches and checkpoints are generally available in all AWS regions.
Archil-managed storage or your own bucket
Archil-managed storage is the default and requires no bucket of your own. Data can still be exported with any S3 client through Archil’s S3 API. Managed storage does not mean giving up that export path. Its relevance here is that a team can use branches without connecting the disk to a bucket it owns. Which plan a team needs for branching therefore depends on where it keeps its data.
With BYOB, Archil writes each file to your bucket as an ordinary object at its path, and any S3 tool can read it. That makes the backing bucket a direct access point for those objects. Timing is the important qualification. Writes are durable on Archil when fsync returns, but they reach the bucket asynchronously.
That separation explains why two reading paths can show different states. Reads through Archil’s own S3 API see committed writes immediately, while reads directly from the backing bucket can show an older version until synchronization catches up. The routes are not interchangeable for freshness. An S3 tool reading the bucket sees only the writes that have reached it. “S3 access” alone is therefore too vague to describe which state a reader will see.
For teams that are not on Enterprise and need branches, one option is to keep the experiment’s working data on an Archil-managed disk. That changes where the working data lives, rather than treating BYOB as a branching feature on every paid plan. The trade-off is straightforward. A workflow that specifically requires both a disk synchronized to its own bucket and branches of that disk needs Enterprise.
Example: checkpoint, branch and mount an experiment
The example below mounts a disk, creates a checkpoint named pre-experiment, and forks a branch named experiment-1 from it. It then mounts that branch at /mnt/experiment. pre-experiment names the fixed starting state, while experiment-1 names the writable fork. For a disk synchronized to your own bucket, this workflow requires Enterprise.
# Mount the disk and take a checkpoint
sudo archil mount myorg/mydisk /mnt/archil --region aws-us-east-1
archil checkpoints create /mnt/archil pre-experiment
# Fork a branch from that checkpoint
archil branches --region aws-us-east-1 create dsk-0123456789abcdef experiment-1 \
--from-checkpoint pre-experiment
# Mount the branch, on this machine or another one
sudo archil mount myorg/mydisk /mnt/experiment --region aws-us-east-1 --branch experiment-1The first mount makes the disk available at /mnt/archil, which the checkpoint command uses to name its point-in-time state. The branch creation command then selects that checkpoint with --from-checkpoint pre-experiment. The final mount selects the branch with --branch experiment-1.
The branch mount can run on the same machine or another one. A second VM is optional for the fork shown here. The independence belongs to the branches themselves. Once mounted, the branch gives the experiment its own writable copy, and its writes leave the source and sibling branches unchanged.
The example also stops short of a full experiment-management workflow. It shows one checkpoint, one branch and a mount, with cleanup and access-control setup left as separate concerns. In particular, the ability to create an independent writable fork should not be read as a promise that the fork is independently secured or individually deletable. Those limits affect how the workflow can be used.
How other file systems on S3 handle snapshots
AWS’s S3 Files docs require S3 Versioning on the bucket linked to Amazon S3 Files. Versioning keeps the history of each object, but the system has no native whole-file-system branch. Object history and a writable filesystem fork serve different purposes. A history of individual objects is not, by itself, an independent working copy of the whole file system starting from one checkpoint.
A native branch can accept its own writes without changing the source. The S3 Files documentation describes no such whole-file-system branch. Its use of S3 Versioning should therefore be understood on its own terms rather than treated as another label for Archil’s branching model.
JuiceFS offers juicefs clone, which copies metadata only and is fast regardless of size. According to the JuiceFS clone documentation, a clone is atomic for files but not for directories: if a source directory changes during cloning, the target can differ from it.
The directory qualification is especially relevant when the intended copy is a reference for an experiment. A fast operation does not, on its own, establish what happens when the source changes during that operation. The docs make that condition explicit. JuiceFS’s clone behavior, S3 Versioning’s object history and Archil’s immutable checkpoints provide different ways to copy or preserve data. Side-by-side details are on Archil’s comparisons with Amazon S3 Files and JuiceFS.
Limits to know before relying on branches
A branch is not a security boundary. Archil credentials are scoped to the whole disk, including every branch and checkpoint. A workload’s changes can stay on its own branch while the credential scope still covers the rest of the disk. For that reason, the recommendation for untrusted workloads is to give them separate disks.
This is a distinction between data isolation and access isolation. Branching provides the former in the sense that writes do not affect the source or sibling branches. It does not provide the latter. Two branches mounted on separate VMs still share the same disk-level credential scope, so they have no separate security boundaries. The machine arrangement and the authorization boundary are different parts of the design.
Deleting individual branches and checkpoints isn’t supported yet, which limits the lifecycle of experimental forks even though creating them is fast. A workflow built around making a branch for each experiment cannot assume there is a matching operation to delete each branch afterward. The feature’s speed and its deletion support need to be considered separately.
Checkpoint names must also be unique within the branch where they are taken. The naming scope is the branch, rather than an unspecified global namespace. That becomes relevant as branches acquire their own checkpoints and the tree grows.