Tahoe-LAFS

Tahoe-LAFS is a free, open-source system for storing files across multiple servers. It is best suited to people willing to run a gateway and connect it to a storage grid. Its strongest appeal is protecting file contents from storage operators while allowing recovery after server failures; the trade-off is running and maintaining the infrastructure yourself.

Overview

Tahoe-LAFS encrypts each file with a unique key before sending it to storage, then erasure-codes it into shares distributed across servers. Its documented defaults produce 10 shares across at least 7 storage nodes, with recovery from any 3 shares. That can keep files recoverable despite multiple server failures, but the default shares.happy setting means uploads will not succeed on a grid with fewer than 7 nodes unless adjusted.

Encryption and integrity checks happen at the gateway, so storage servers cannot read or modify file contents. That protection depends on the gateway: an operator of a remote gateway can view and change the data. Tahoe-LAFS does not attempt to provide anonymity, and it does not protect file size. Tor and I2P integrations are documented, but do not change those stated security limits.

Key features

Recovery and integrity

Erasure coding allows recovery from a subset of shares rather than requiring every storage server to remain available. The gateway checks integrity and ignores corrupted shares, which strengthens resilience in a grid where individual servers may fail. The defaults are substantial for a small installation, however: a user must provide enough nodes or change the configuration before uploads will work.

Gateway access and control

A gateway exposes the storage grid through HTTP(S) and SFTP, and Tahoe-LAFS documents a REST-style Web API for programmatic operations. Files and directories can be immutable or mutable; mutable items support read-write or read-only access. Users can run a gateway against storage servers on other computers, or operate a complete grid with storage nodes and an introducer. The former keeps the setup focused, while the latter gives users responsibility for the whole deployment.

Storage servers can delete shares after leases expire when garbage collection is enabled; garbage collection is disabled by default. That default avoids automatic removal, but operators who enable collection need to account for lease expiry in their retention practices.

Pricing

Tahoe-LAFS is free and open source: the Free and open-source software plan costs nothing and supports a self-hosted storage grid. There is no hosted plan or paid tier stated, so users supply and operate the gateway and storage infrastructure rather than paying for managed capacity. It is offered under GNU GPL version 2 or later, or the Transitive Grace Period Public Licence version 1.0 or later.

Platforms

The project documents installation on Windows, macOS, Linux, and BSD systems, and lists API, web, and self-hosted access. The README requires Python 3.9 or later; Python 2.7 users are directed to version 1.17.1. A client gateway can run on a user's own machine, while a complete deployment adds storage nodes and an introducer.

Who it's for

This is a strong fit for technically capable users who want decentralized storage, control their gateway, and can arrange enough storage nodes to meet their chosen settings. It is less suitable for anyone seeking a ready-made hosted service, a small grid that works with defaults, or anonymity and file-size privacy. The public test grid is for experimentation, not dependable or large-scale storage. Deployment help is available through the tahoe-dev mailing list and Libera.Chat.

Pros and cons

Recoverable storage: Files can be reconstructed from any 3 of the default 10 shares, so every server need not remain available.

Storage-provider separation: Gateway encryption and integrity checks prevent storage servers from reading or modifying file contents.

Flexible access: HTTP(S), SFTP, a REST-style API, and read-only or read-write mutable files and directories support different usage patterns.

Operational threshold: Default uploads require at least 7 storage nodes, a demanding starting point for a small deployment.

Gateway trust remains important: A remote gateway operator can view and change data, so users must control or trust that gateway.

Not an anonymity system: File size is not protected, and the architecture does not attempt anonymity.

Alternatives

SeaweedFS is worth considering for a self-hosted deployment when its community support and cluster-size flexibility suit the operator; its free Community support plan includes any cluster size, GitHub issues and discussions, and public documentation, without a guaranteed response time.

JuiceFS offers a self-hosted Community Edition with community support through GitHub and Discord, making it another option for users who prefer that support model.

LucidLink is a paid alternative for readers seeking a service with a Starter plan at $7 a month, billed member/month, with 10 members and 100 GB included per member, shared; annual billing saves 15%.

MooseFS offers a free Community edition with a single active master and single-parity erasure coding, a different fit for users whose needs align with those constraints.

BeeGFS is another self-hosted option for Linux and API environments.

Hadoop Distributed File System is a free, self-hosted cluster option for readers who want software under the Apache License 2.0.

LizardFS is an alternative for readers considering paid support and maintenance packages.

OrangeFS offers open-source software as well as support and services.

Browse more in Distributed File System Software and Secure Cloud Storage.

Verdict

Choose Tahoe-LAFS if you want free, self-hosted storage that encrypts files at the gateway and can recover them from a subset of distributed shares. Its key cost is operational: you must run a trusted gateway and provide enough storage nodes for your configuration. Look elsewhere for managed hosting, a small default-ready grid, or anonymity and file-size privacy.