Capabilities

These capabilities come out of the box.

Forks

A fork is a layered view of an entire volume. Creating one does not copy file data or duplicate the existing tree. It starts from the same underlying history, and the fork diverges only as new changes are written.

• Fork a volume in one call. Mount the fork on any client.
• A fork can itself be forked, so branches can nest.
• Writes on a fork stay on that fork. Shared blocks diverge only when they change.
• Forks do not merge back. A fork is a fresh line of history. Pick the one to keep.
• Drop a fork in one call. Nothing is copied, so dropping is instant.
• Good for build isolation, experimentation, dataset branches, and CI workspaces.

Temporary forks

A temporary fork exists only for the duration of a mount session. Writes are stored on the client's local disk and bypass the object backend, so no file data is written to S3 or any other configured backend. Metadata still flows through dataserv (the metadata backbone) like any other fork. When the volume is unmounted, the fork's metadata is cleaned up shortly after.

Time travel

Time travel is a fluid snapshot view of a volume. Pick any earlier point in time, down to the minute, and the volume opens as it looked at that moment.

• Browse the volume as of a minute ago, an hour ago, or last Tuesday.
• Read any file from that moment, or copy it out.
• Granularity matches the version history, down to one minute.
• No periodic snapshots, side copies, or separate subsystem to operate.

Version history

Every file keeps a rolling history at one-minute granularity. If a file is saved more than once in the same minute, the intermediate versions are collected automatically, so the history stays useful rather than becoming noise.

• List versions for any file, and open any version.
• Open any version and copy it out wherever you want.

Recently deleted

Deleted files and folders stay available in a recently-deleted view for a configurable window. Open any of them and copy it out, with no backup to pull from.

• Access is instant, with no copy from a backup.
• Works the same for a single file, a folder, or a subtree.
• After the window closes, entries age out.

Retention

Retention is one knob per volume. It sets how far back time travel reaches, how long deleted files stay available, and when old versions and deleted entries finally age out of the database and the object backend. The default is 30 days, set per volume in the admin dashboard.

• One setting covers version history, recently-deleted, and final cleanup.
• The trade-off is space. A longer window holds more versions and deleted entries in the database and the backend.
• An active fork keeps the history it can reach available until that fork ages out, then it ages out with the rest.
• Temporary forks are ephemeral. Their writes live on the client's local disk and are cleared shortly after the volume is unmounted.
• Volume deactivation has its own grace period, independent of day-to-day retention.

Change events

Every general volume can keep an ordered feed of its changes. The feed records creates, deletes, modifies, and renames, with full paths and ordered sequence numbers. The mountos event command reads it as a stream on stdout or serves it as a local REST API.

• Off by default. Its own per-volume knob, separate from retention, turns it on.
• Tail live, replay a time window, or filter to a subtree.
• Good for indexers, sync tools, and AI agents that follow a volume without walking the tree.
• See Change events for the full contract.