RedundaNet 2, the legacy product

The grid that came before RedundaNet 3. It still runs, and its members are moving over at their own pace.

Still live. RedundaNet 2 stays up until a stop date the maintainer announces, because its Tahoe shares still hold members' data. The wind-down is manual: no countdown and no automatic deletion exist. New members join RedundaNet 3; existing members follow the migration guide.

What it was

RedundaNet 2 was a Python command line tool and a Docker Compose stack. Nodes joined a tinc mesh VPN; GPG keys were the node identities and doubled as the tinc keys; a YAML manifest on GitHub was the source of truth for membership; files were stored with Tahoe-LAFS, erasure coded 2-of-4 across the storage nodes; a hub on fly.io relayed peers behind NAT, ran the Tahoe introducer and served the public status page.

Six members and eight storage nodes are on it today; one member and two nodes also run RedundaNet 3. The Python package redundanet on PyPI (version 2.7.x) is its command line tool. Its operational rules stay valid for the old grid: in particular the tinc container is never restarted alone, and every compose call includes the override file.

RedundaNet 2 status page → The Python package on PyPI →

Documentation

All RedundaNet 2 documentation moved under docs/legacy/ unchanged, each file with a one-line banner saying it describes the legacy product.

What the RedundaNet 2 stack sends and to whom is in the privacy policy, under "RedundaNet 2, the Docker stack".

Why RedundaNet 3

RedundaNet 3 replaces the Docker stack, the VPN and Tahoe with one static binary: identity from a phrase instead of GPG keys on keyservers, a signed manifest, a hub for rendezvous and relay, QUIC with TLS 1.3 between devices, erasure coding across members, weekly restore tests, repair without the owner and self-update with rollback. The home page says what it does; the architecture page says how.