Tahoe-LAFS

Tahoe-LAFS is free, open-source software for decentralized file storage across multiple servers. The client encrypts each file with its own key before it is uploaded. Erasure coding splits files into shares so they can be recovered if some storage servers fail; the documented defaults use 10 shares across at least 7 servers, with recovery possible from any 3. A gateway checks integrity and detects and ignores corrupted shares.

Files can be immutable or mutable, and mutable files and directories can have read-write or read-only access. The gateway provides HTTP(S) and SFTP access, while a REST-style Web API supports programmatic operations. Users can run a client gateway or set up a complete grid of storage nodes and an introducer. Installation is documented for Windows, macOS, Linux, and BSD, and the project describes use with Tor and I2P. The public test grid is for experimentation, not reliable or large-scale storage. The default shares.happy setting is 7, so uploads will not succeed on grids with fewer than 7 storage nodes unless that setting is adjusted. Deployment help is available through the tahoe-dev mailing list and Libera.chat.

Tahoe-LAFS provides client-side encryption and redundant storage across a grid users operate. Its deployment requirements and the distinction between test-grid and dependable storage are important to consider.

Tahoe-LAFS suits users who want to operate a decentralized storage grid and manage their own gateway or storage nodes. It may also fit people who need programmatic access through its Web API.

Tahoe-LAFS is a free, open-source system for distributing encrypted files across servers you arrange. It suits technically capable users who can run a gateway and maintain a storage grid. Its standout benefit is provider-independent confidentiality with recovery from failed nodes, while its infrastructure requirements rule it out as a turnkey cloud drive.

Overview

Tahoe-LAFS breaks each file into erasure-coded shares and places them on multiple storage servers. The documented defaults create 10 shares across at least 7 servers and reconstruct a file from any 3 shares. That gives a deployment substantial tolerance for outages and failed machines, but the default shares.happy value of 7 means uploads fail on grids with fewer than seven storage nodes unless an administrator changes the setting.

Each file is encrypted at the client gateway with its own key before upload. Storage servers therefore cannot read or alter plaintext, and the gateway verifies share integrity while ignoring corrupted pieces. This is a meaningful advantage when storage is spread among operators you do not fully trust. The gateway remains a critical trust boundary: an operator of a remote gateway can view and modify data. Tahoe-LAFS does not promise anonymity, and it does not conceal file size.

Key features

Resilience and integrity

Subset-based recovery keeps files accessible when some servers disappear, rather than requiring every node to respond. Integrity checking helps the gateway reject damaged shares, making the design appropriate for failure-prone or geographically distributed infrastructure.

Access and automation

Files and directories may be immutable or mutable. Mutable objects support read-write or read-only access, allowing controlled collaboration while preserving immutable content when changes should be impossible. A gateway exposes HTTP(S) and SFTP, and the documented REST-style Web API supports programmatic operations.

Deployment and networking

You can run a client gateway or operate a complete grid containing storage nodes and an introducer. Documentation covers Tor and I2P integration, plus HTTP(S) or Foolscap communication with storage servers. Those options help privacy-conscious network architects, but they do not turn Tahoe-LAFS into an anonymity system.

Python 3.9 or later is required; users on Python 2.7 are directed to version 1.17.1. Storage servers may remove shares after lease expiration when garbage collection is enabled, although garbage collection is disabled by default.

Pricing

Free and open-source software — free. The plan is self-hosted storage-grid software under the GNU GPL version 2 or later, or the Transitive Grace Period Public Licence version 1.0 or later. There is no hosted plan or paid tier. The zero price covers the software, not the machines, administration, networking, or operational work needed to provide a dependable grid.

This is the right arrangement for individuals, teams, and organizations able to supply their own nodes and gateway. It is a poor substitute for a subscription service if you want someone else to provision capacity, monitor nodes, or absorb infrastructure costs.

Platforms

Installation documentation covers Windows, macOS, Linux, and BSD. The software offers API and web access, supports self-hosted deployments, and provides desktop client coverage across the listed operating systems. A gateway can be reached through HTTP(S) or SFTP, making it usable from varied client environments.

Who it's for

Tahoe-LAFS fits administrators who want encrypted, redundant storage without handing plaintext to storage providers, and users comfortable operating a gateway connected to servers on other computers. It also suits developers automating storage through the Web API or integrating a grid into custom infrastructure.

It is not a good fit for anyone seeking a managed drive, a tiny one- or two-node setup under the default redundancy policy, or anonymity guarantees. The public test grid is intended for experimentation, not reliable or large-scale storage. Deployment help is directed through the tahoe-dev mailing list and Libera.chat, so ongoing operation requires a willingness to engage with technical community support.

Pros and cons

Pros

• Client-side, zero-knowledge encryption: storage servers cannot read or modify file contents.
• Strong node-failure tolerance: defaults recover files from any 3 of 10 shares spread across at least 7 servers.
• Corruption detection: gateway integrity checks discard bad shares instead of silently serving damaged data.
• Flexible interfaces: HTTP(S), SFTP, and a REST-style API support applications as well as interactive access.
• No software fee: the open-source license permits self-hosted use without a paid tier.

Cons

• Substantial operating burden: dependable use requires a gateway and a suitably populated storage grid.
• Small-grid friction: uploads fail below seven storage nodes unless shares.happy is reconfigured.
• Gateway trust remains: a remote gateway operator can view and change data.
• Not anonymous: the architecture leaves file size exposed and does not attempt anonymity.
• Retention depends on leases: enabled garbage collection can delete shares after leases expire.

Alternatives

Choose LucidLink when you want a paid service with a free trial, Android and iOS clients, and a Starter plan at $7 a month per member with 100 GB per member and 10 members.

Choose Ceph for free, open-source distributed storage centered on a running Ceph cluster for block storage.

Choose SeaweedFS if a freemium project with a free community-support tier, any cluster size, and no guaranteed response time is preferable.

Choose BeeGFS for its freemium, self-hosted parallel file-system approach and Community Edition.

Choose Google Cloud Managed Lustre when managed cloud deployment and provisioned-capacity billing are more suitable.

Choose Hadoop Distributed File System for a free Apache-licensed, self-hosted cluster.

Choose JuiceFS for a freemium option offering a self-hosted Community Edition and a separate cloud service.

Choose MooseFS for a freemium system with a free Community edition, single active master, and single-parity erasure coding.

For broader comparisons, see Distributed File System Software and Secure Cloud Storage.

Verdict

Tahoe-LAFS is a strong choice for technically skilled users who can run a gateway and assemble enough storage nodes to benefit from erasure-coded recovery. Choose it primarily for encrypted content that remains unreadable to storage servers and for resilience when individual nodes fail. Look elsewhere if you need managed capacity, a minimal-node deployment, or anonymity rather than a self-operated security boundary.