Introduction
LoonFS is an open-source cloud filesystem built on object storage. LoonFS namespaces are transactional and globally consistent, using object storage as both durable storage and the coordinating authority.
LoonFS supports most integration interfaces, including API, CLI, SDK (coming soon), and MCP (coming soon). Most common filesystem CRUD operations are supported for files and folders — create, move, copy, and delete — as well as metadata operations like stat, list, and grep (coming soon).
Changes to files and folders in a namespace are recorded as atomic commits in an append-only write-ahead log, and clients can batch operations within a commit for atomic transactions in advanced use cases. Commits are acknowledged only once durable, and filesystem operations support flexible preconditions for greater consistency.
LoonFS is not, and does not attempt to be, POSIX compliant. LoonFS is focused on exceptional performance and scalability as a cloud filesystem.
LoonFS stores both content and metadata on object storage. Metadata is indexed for scalable performance of all filesystem operations, even as a namespace grows to millions of files and revisions.
LoonFS can be embedded or hosted on a server. This makes LoonFS particularly well suited for developers who need to embed a native cloud filesystem as part of their platform.
Additional features like advanced permissions (ACLs), open sharing, and advanced search are on the roadmap.
Features
Section titled “Features”- Embedded or server hosting – LoonFS can run in-process against object storage, even among concurrent readers, or a single host can serve many readers and concurrent writers.
- Object-store durability – object storage is the only durable dependency, and LoonFS namespaces inherit the same durability SLAs as the S3-compatible host.
- Transactions – all operations are serialized as commits to a WAL with optional preconditions, supporting flexible transactions and replay.
- Read acceleration – the write and read paths leverage caching to accelerate operations without correctness risk.
- Many more – the documentation covers a number of other features, and our roadmap includes many future enhancements.
Use cases
Section titled “Use cases”Cloud file drives as a category are not inherently new, and common use cases are well known. LoonFS should be a compelling new option for many of them:
- Local drive with native cloud syncing
- Shared team drive
- Embedded drive for platform builders
We also understand that the way data is being generated and consumed is changing, and we’re excited to introduce a platform that can excel in existing use cases while serving emerging ones. Some of these newer use cases include:
- Headless document drive for agentic use cases
- RL environment filesystem with snapshotting and forking
- Durable document storage for homegrown or managed agentic tools
- And presumably others we haven’t encountered yet
Feel free to reach out if you’d like to discuss whether LoonFS is a good fit for your use case.
Questions and answers
Section titled “Questions and answers”How is LoonFS different from S3?
LoonFS is an abstraction on top of S3, creating an indexed, transactional filesystem out of S3 primitives.
- S3 uses paths as the object identity; LoonFS uses inodes.
- S3 is isolated at the object level, but not as a filesystem. LoonFS leverages this S3 object property to create isolated transactions within a namespace.
How is LoonFS different from Dropbox, Box, or Google Drive?
- LoonFS is open source and embeddable. Data can be stored on any S3-compatible object store, and it’s designed for best-in-class developer ergonomics.
- LoonFS inherits the durability of S3-class storage at the cost of S3-class storage, which can be more expensive depending on storage utilization.
How fast is LoonFS?
- LoonFS is faster than most cloud drives for the majority of use cases.
- LoonFS is slower than a local (SSD) filesystem.