Capabilities

mountOS includes these capabilities by default.

Forks

A fork is a layered view of an entire volume. It does not copy file data or duplicate the existing tree. A fork starts from the same underlying history. It diverges from that history only when a client writes new changes to it.

• 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. mountOS copies nothing, so the drop is instant.
• Use forks for build isolation, experimentation, dataset branches, and CI workspaces.

Temporary forks

A temporary fork exists only for the duration of a mount session. The client stores its writes on local disk, not in the object backend. As a result, a temporary fork sends no file data to S3 or any other configured backend. Metadata for a temporary fork still flows through the metadata node, the metadata backbone, like metadata for any other fork. When a client unmounts the volume, mountOS removes the fork's metadata shortly after.

Time travel

Time travel is a fluid snapshot view of a volume. Pick any earlier point in time, down to the minute. The volume opens in the state it was in 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's window.
• Time travel needs no periodic snapshots, side copies, or separate subsystem.

Version history

Every file keeps a rolling history. The window defaults to one minute. An operator can configure a shorter, sub-minute window per volume. If a client saves a file more than once within that window, mountOS collects the intermediate versions automatically. The history stays useful. It does not become noise.

• List versions for any file. Open any version.
• Open any version and copy it out to any destination.

Recently deleted

Deleted files and folders stay available in a recently-deleted view for a configurable window. Open any of them. Copy it out. mountOS needs no backup to do this.

• Access is instant. It needs 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. It also sets how long deleted files stay available. It sets when old versions and deleted entries finally age out of the database and the object backend. The default is 30 days. An operator sets it 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 object backend.
• An active fork keeps the history it can reach available until that fork ages out. Then the fork ages out with the rest.
• Temporary forks are ephemeral. The client stores their writes on its local disk. mountOS clears the writes shortly after a client unmounts the volume.
• 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.
• Use change events for indexers, sync tools, and AI agents that follow a volume without walking the tree.
• See Change events for the full contract.