diaspora*: self-hosting a federated social network in Ruby

What diaspora* solves, and who the repository is written for

diaspora* is a social network you can run on your own server. The README describes it as "A privacy-aware, distributed, open source social network", and the network is made of independent servers, called pods, that connect to each other. The point is that no single operator holds every account. If you sign up on one pod, you can follow people on another.

There are two audiences, and the README separates them clearly. The first is people who just want an account: the README says you do not have to install diaspora* to use the network, and points to a list of open servers plus a wiki page on choosing a pod. The second is people who want to own their data, try the software, run it on a server, or contribute code. That second group is who the repository is for, and it is the group this review addresses.

The codebase is a Ruby on Rails application. The top-level layout is a conventional Rails one: app/, config/, db/, lib/, spec/, plus a Gemfile, a Procfile for process management, and a docker/ directory. The front end is not a separate single-page application. package.json lists jQuery 4.0.0, Backbone 1.6.1 and a set of markdown-it plugins, which tells you the interface is server-rendered with a Backbone layer on top.

How a pod talks to the rest of the network

The federation model is the part worth understanding before you commit to running a pod, because it drives most of the operational cost.

A pod is a full copy of the application: Rails serves the web interface and the API, and the database stores the accounts, posts and relationships that pod knows about. When a user on your pod follows someone on another pod, your instance needs to receive that person's posts. The repository layout reflects this: there is a lib/ directory for library code, a db/ directory for schema and migrations, and a docker/ directory for containerised deployment. The README does not describe the wire protocol between pods, so the exact transport is something you would confirm from the wiki or the source, not from this page.

The practical consequence is that a pod is not a thin client. It stores data, it serves requests, and it exchanges traffic with other servers. That is a different operational shape from a static site or a single-user tool. The repository's topics list includes decentralized, distributed and federated, which matches the README's framing, but the README itself gives no sizing guidance, no traffic estimates and no description of what happens when a remote pod goes offline. Those are gaps you should expect to fill from the wiki or from the issue tracker.

Installing diaspora*: what the README says and where the commands are

The README does not contain installation commands. It states that installation guides live on the wiki, at the Installation page, and that those guides cover trying it out, installing on a server, and setting up a development environment. Because the repository does not ship the steps, this section describes what the repository does give you and where to look, rather than inventing commands.

The repository pins its Ruby version in a dotfile at the top level:

cat .ruby-version

That file is the authoritative statement of which Ruby the application expects. Read it before you follow any guide, because a wiki page written for an older release may name a different version.

Dependencies are split between Ruby and JavaScript. The Ruby side is declared in the Gemfile, and the JavaScript side in package.json. The repository uses Yarn, indicated by yarn.lock at the top level:

yarn install

Running that installs the front-end packages listed in package.json, including jQuery, Backbone and the markdown-it plugins. You should see a node_modules directory appear and yarn.lock left unchanged if the install resolves cleanly.

For running the application, the repository includes a Procfile, which is the format used by Foreman. A .foreman file at the top level suggests Foreman is the intended process runner for development:

foreman start

The README does not document what processes the Procfile defines, so treat this as a pointer to the repository's own tooling rather than a complete startup recipe. For a real deployment, follow the wiki installation guide for your platform; the README's contribution section links to a getting-started-with-contributing page for development setups.

Where diaspora* is the wrong tool

The clearest limitation is documentation placement. The README is a signpost, not a manual. It links to a project site, a wiki, a bug tracker, a Discourse forum, a licence file and a contributors list, and then stops. Installation, pod administration, upgrades and troubleshooting all live on the wiki. If your evaluation process depends on a repository that documents its own deployment, diaspora* will not satisfy it, and reading the README alone will not tell you whether a given release is safe to upgrade to.

A second limitation is the stack itself. This is a Rails application with a Backbone front end and a Yarn-managed asset pipeline. Running it means running Ruby, a database, a JavaScript build step and a process manager. That is a reasonable amount of surface area for a team that already operates Rails applications, and a poor fit for someone who wants a single binary or a container they can start and forget. The docker/ directory exists, but the README does not describe it, so container users should verify the image's expectations against the wiki rather than assuming the directory is a supported deployment path.

A third point is federation itself. Because pods are independent, the experience of your users depends partly on servers you do not control. The README does not describe how the network handles a pod that disappears, how content is moderated across pods, or what a pod administrator is responsible for. Those questions are real, and the repository does not answer them.

How diaspora* differs from Mastodon and from a hosted social platform

The obvious comparison is Mastodon, since both are federated social networks with independent servers. The difference visible in this repository is the technology and the shape of the application. diaspora* is Ruby on Rails with a server-rendered interface and a Backbone layer, while Mastodon is a different stack entirely. For an operator, that matters more than any feature list: choosing between them is partly a question of which language and framework your team can maintain, patch and debug at three in the morning.

The second comparison is against a hosted platform, where you create an account and someone else runs the servers. diaspora* does not require that. The README explicitly offers both paths: join an existing pod, or install your own. That is the real distinction. A hosted platform gives you no operational work and no control. A diaspora* pod gives you control and hands you the operational work, including upgrades, backups and moderation.

A third comparison, within the same family, is running an account on someone else's diaspora* pod rather than your own. The README treats this as a first-class option, pointing to a list of open servers. For most people who simply want to use the network, that is the lower-cost choice, and the README says so before it says anything about installing.

Licence, maintenance and the cost of staying current

diaspora* is licensed under AGPL-3.0, stated in the repository metadata and in package.json. The practical implication of the AGPL for a network service is that if you run a modified version and let users interact with it over a network, the licence's source-availability condition applies to your modified version. That is a summary of the licence's intent, not legal advice; if you plan to modify and host diaspora*, have a lawyer read the actual terms in the LICENSE and COPYRIGHT files at the top level.

On maintenance, the release history is uneven. v0.9.0.0 was published on 2024-06-16, and v0.9.1.0 followed on 2026-04-07, roughly 22 months later. The release before that, v0.7.18.2, is dated 2023-07-10. The pattern is long gaps punctuated by point releases, so planning an upgrade cadence around a predictable schedule is not realistic. The repository's last push was on 2026-07-28, which is recent, but commits between releases do not tell you whether a given release is stable for your pod.

The upgrade cost is where the missing documentation bites hardest. The README does not document rollback, database migration reversibility, or what happens to federated content when you skip a release. The Changelog.md file at the top level is the place to look for what changed between versions, and the wiki is where upgrade instructions would live. Budget time to read both before touching a production pod.

Editorial conclusion

Adopt diaspora* if you want a Ruby on Rails social server you can host yourself and connect to the wider diaspora* network, and if you accept that the README defers installation to the wiki rather than shipping a one-command setup. Do not adopt it if you need a single-binary, low-maintenance deployment, or if you expect the repository itself to document upgrades, rollback or pod sizing; those pages live on the wiki and are outside this review. Before committing, read the wiki installation guide for your target platform, confirm the Ruby version pinned in .ruby-version matches the guide, and check whether a maintenance or upgrade path is documented for the release you plan to run.

Frequently asked questions

Official sources

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