One filesystem. Many workloads.
A cross-platform, forkable, time-traveling distributed filesystem over object storage. Use what ships with mountOS, or build on top of it.
Elastic volume
No fixed capacity to provision or resize.
A mountOS volume is backed by object storage, so its capacity is not tied to the size of a disk or SSD. It grows with the data stored, without resizing the volume as storage needs change.
The volume presents as a complete, POSIX-compliant filesystem on macOS, Windows, Linux, and Kubernetes, so applications read and write it like a local drive.
Low-latency file access
Serve hot data with low latency.
Some workloads need faster file access than a direct object-storage path can provide. They include databases, build caches, media processing, and services with a hot working set.
An elastic SSD-backed cache keeps hot data close to the service while it is being served. The data then syncs to the S3-compatible backend for durable retention.
- An elastic SSD-backed cache for hot data
- Replicated block storage for active data
- Durable S3-compatible object storage
- Databases and build caches
- Latency-sensitive services
- Media and data-processing workloads
Cross-platform file access
One volume for Windows clients and Linux servers.
A team runs Windows workstations alongside Linux application servers. Shared files usually require an SMB or NFS server, separate mounts, and protocol-specific configuration.
With mountOS, both Windows and Linux access the same POSIX-compliant volume through native mounts. Applications read and write files with their normal filesystem tools. The data remains backed by the team’s own object storage.
The team can use the same data on Windows and Linux while keeping storage under its own control.
- Windows workstations
- Linux application servers
- The team’s object storage
Observability
Logs become a queryable Iceberg table the moment the writer commits them.
A service writes structured logs as Parquet files, using Apache Arrow, and commits them through the Iceberg REST catalog. The Iceberg Catalog volume presents the result as an Apache Iceberg catalog, so analytical engines query it directly.
DuckDB, Spark, Trino, or PyIceberg read the catalog straight from object storage and power a dashboard on top.
- An Iceberg REST catalog: tables, namespaces, commits
- Compaction that keeps the table queryable as it grows
- An Arrow-based log writer
- A query engine (DuckDB, Spark, Trino, PyIceberg)
- A dashboard
Event-driven preprocessing
A pipeline starts the moment a file lands, not on the next poll.
Every general volume keeps an ordered feed of creates, deletes, modifies, and renames, live on stdout or served over a local REST API.
A pipeline watches the feed and reacts as files land, for example generating subtitles, transcoding media, or running an AI model over new data.
- An ordered, per-volume change-event feed
- A stream and a local REST API to read it
- The pipeline that subscribes and acts on each event
Bulk transfer jobs
Move data in and out of a volume as a managed, resumable job.
Upload moves data into a volume, from local disk or from object storage. Download moves data out of a volume, to local disk or to object storage.
Both jobs run in the background, resume after an interruption, and support bandwidth limits and file filters.
The CLI runs a job directly. The open-source desktop app wraps the same commands with a GUI, live progress, and job history.
Live media ingest
A camera feed becomes a durable, growing file.
A live HLS stream lands in a volume as one continuously growing file, playable in any standard media tool.
The ingest job resumes after an interruption and reports lag, bitrate, and delivery health as it runs.
The CLI runs the ingest directly. The desktop app wraps the same command with a GUI and live health telemetry.
- The camera or stream source
- Anything downstream that plays, archives, or processes the recording
Persistent storage for agent sandboxes
The compute can disappear. The agent’s workspace does not.
Agent sandboxes are intentionally disposable, but the files they create often need to outlive a single run. Mount the same mountOS volume into each new sandbox so source trees, generated artifacts, caches, and checkpoints remain available when an agent resumes.
Give each agent or task a named fork for an isolated, writable workspace. The fork starts from a shared base without copying it, keeps its own history, and can be mounted again by the next sandbox. Keep successful work for review or discard the entire fork when the task is done.
- A durable POSIX workspace backed by object storage
- Copy-on-write forks for isolated agents and tasks
- Version history and time travel for recovery
- The agent runtime and disposable compute sandbox
- Lifecycle policy for keeping or discarding task forks
CI workspaces
A build or test job forks a volume in one call, nothing copied.
A fork is a read-write branch of an entire volume, created in one call with nothing copied. A CI job or a local build mounts the fork and works against the full dataset, with every write staying on the fork.
A fork can pin to the live volume or to any point in its history, and can itself be forked, so parallel jobs branch off the same base, each isolated from the others. Unmounting a temporary fork discards its changes; a named fork keeps them.
- A fork, created in one call, with nothing copied
- Forks pinned to the live volume or any point in history
- Nesting: a fork can itself be forked
Start with mountOS. Build the rest around it.
The free tier supports up to 10 TiB. Infrastructure stays owned and self-hosted.