Lemmy: a federated link aggregator you can self-host

What Lemmy replaces, and for whom

The README describes Lemmy as "a link aggregator and forum for the fediverse", and compares the user experience to Reddit, Lobste.rs and Hacker News: you subscribe to forums, post links and discussions, then vote and comment. The difference is in who runs the server. Anyone can run one, and the servers are federated, which the README compares to email. A user registered on one server can subscribe to forums on another and hold discussions with users registered elsewhere.

The audience is therefore narrower than Reddit's. It is the person or group willing to operate a server, or to join one whose moderation policy they accept. The README notes that each Lemmy server can set its own moderation policy, appoint site-wide admins and community moderators, and that the goal is a non-toxic environment. That is a governance feature, not a technical one, and it is the part most likely to decide whether a community works. If your group cannot agree on who moderates, Lemmy will not settle the argument; it will just move it to a config screen.

ActivityPub, Rust and the workspace layout

Lemmy is written in Rust and built on Actix and Diesel, with Inferno and TypeScript on the frontend side according to the README. The repository is a Cargo workspace. The members list in Cargo.toml shows the shape of the codebase: crates/utils, crates/db_schema, crates/db_schema_file, crates/diesel_utils, crates/email, a long list of crates under crates/db_views (post, comment, community, vote, person, notification, modlog, report_combined and others), and crates/api/api. The workspace version is 1.0.0-beta.3, the edition is 2024, and the declared rust-version is 1.92.

The db_views split is the interesting design choice. Read models such as post, comment and community each get their own crate rather than living in one shared module. That keeps compile units smaller and makes the view layer explicit, but it also means a change to how a post is assembled can touch several crates. The release profile sets lto = "fat", opt-level = 3 and codegen-units = 1, which the Cargo.toml comments describe as optimising for speed rather than size. The dev profile sets debug = 0, with a comment that this significantly speeds up build time. Expect release builds of a Rust workspace like this to be slow, and expect the toolchain pin in rust-toolchain.toml to matter when you build from source.

Federation itself is not documented in the README beyond the email comparison. The README does not describe how instance discovery, retries or defederation are configured; that is left to the administration documentation.

Installing Lemmy with Docker, and the first thing to check

The README's Installation section does not contain commands. It points to the Lemmy Administration Docs at join-lemmy.org/docs/administration/administration.html, and the features list says the project comes with Docker and Ansible deployment paths, linking to join-lemmy.org/docs/administration/install_docker.html and install_ansible.html. So the honest answer to "how do I install Lemmy" is: follow those two guides, not the README.

What the repository does tell you is how to build the server from source. The workspace declares rust-version = "1.92", and rust-toolchain.toml at the top level pins the toolchain. The repository ships docker/ and .woodpecker.yml, and the README's badge links to a Docker Hub image under the name dessalines/lemmy. The administration docs are the source for the compose file, the database and the reverse proxy; the README does not reproduce them, and I would not guess at port numbers or environment variable names from the README alone. After the instance is up, the first thing to verify is not the web UI but federation: whether a post from another instance appears in your All feed.

Where Lemmy is the wrong tool

The most concrete limitation is the release state. The Cargo.toml workspace version is 1.0.0-beta.3, and the recent releases list includes 1.0.0-beta.3, 0.19.21 and 1.0.0-beta.2. The stable line in that list is 0.19.21; the 1.0 line is still beta. If you are building a client or an integration against the API, that matters more than any feature list, because beta releases can change shape between beta.2 and beta.3. Pin your dependency and read the release notes rather than tracking main.

Federation is the second limitation, and it is structural. The README's email comparison is accurate but incomplete: email works because the protocol and the address space are stable and universal. A Lemmy instance depends on other instances being reachable, on their software being compatible, and on their administrators choosing to federate with you. None of that is in your control, and the README does not document rollback, defederation tooling or what happens to mirrored content when a remote instance disappears. If your requirement is a single source of truth with a predictable uptime story, a federated aggregator is the wrong architecture.

The moderation features are real (public moderation logs, sticky posts, locking and removing content, banning, transferring communities) but they are per-instance powers. They do not give you authority over a community hosted elsewhere, which is the point and also the complaint.

Lemmy compared with running a plain forum

The closest alternative is not Reddit, which you cannot self-host, but a conventional self-hosted forum or link board that speaks only HTTP. The difference is architectural rather than cosmetic. A conventional forum has one database and one authority: the server owner decides who exists, what is visible and what is deleted. Lemmy splits that authority across instances and synchronises state between them over ActivityPub. You gain reach, because your users can follow communities on servers you do not run, and you lose the ability to guarantee what any given user sees.

That trade-off shows up in operations. A single-database forum has one backup target and one schema migration path; Lemmy has migrations/ at the top level plus remote peers that may be running different versions of the same software. It also shows up in client work: because Lemmy's API is public and the frontend is separable, third-party apps exist, which the awesome-lemmy list linked from the README collects. A conventional forum usually gives you one official client and calls it done. If you do not want the federation property, the federation machinery is pure overhead.

Licence, maintenance and what an upgrade costs

Lemmy is AGPL-3.0, stated in both the README features list and the Cargo.toml workspace package metadata. The practical consequence for a self-hoster is the network clause: if you run a modified Lemmy and let other people interact with it over a network, the AGPL's source-availability obligation is the thing to read, and this is a question for a lawyer rather than an article. Running the software unmodified is the common case and the one the project is built around. The README also states there is no advertising, monetising or venture capital, and lists Liberapay, Ko-fi, OpenCollective and Patreon as funding routes, with an NLnet foundation grant named.

On maintenance, the repository is not archived and the last push was on 2026-11-02, so the project is being worked on. The upgrade cost is where I would push back on the "easy to deploy" framing. Upgrading a federated instance is not just pulling a new image: the workspace carries migrations/, the project runs a 1.0.0 beta line alongside the 0.19 line (0.19.21), and any client built against the 0.19 API may not survive that jump. The release notes in RELEASES.md are the place to check before moving an instance that other people depend on.

Editorial conclusion

Adopt Lemmy if you want a Reddit-shaped community whose data lives on infrastructure you control, and you accept that federation means synchronising with other people's servers. Do not adopt it if you need a single canonical instance, a stable 1.0 API, or a hosting story you can hand to someone who will not read logs. Before committing, check whether the 1.0.0-beta.3 API surface matches the client you intend to use, and read the administration docs at join-lemmy.org for the Docker and Ansible paths.

Frequently asked questions

Official sources

1. LemmyNet/lemmy on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases