The Fediverse Explained

What Is the Fediverse?

The Fediverse is a network of independently operated servers that communicate with each other using open protocols. Each server runs its own social platform — microblogging, photo sharing, link aggregation, video hosting — but users on any server can follow, reply to, and interact with users on any other server. Think of it like email: you can send a message from Gmail to Outlook because both speak SMTP. The Fediverse works the same way, except the protocol is called ActivityPub and the “messages” are social media posts.

No single company controls the Fediverse. There is no central algorithm deciding what you see, no ad-targeting system harvesting your data, and no corporate policy team making moderation decisions for the entire network. Each server (called an “instance”) sets its own rules, runs its own moderation, and decides which other servers it federates with — or blocks. The result is a social web that is decentralized by design and resilient by consequence.

The term “Fediverse” combines “federation” and “universe.” As of 2026, the network spans tens of thousands of instances running dozens of different platforms, from Mastodon (the most well-known) to Lemmy, Pixelfed, Misskey, and many others. Because they all speak the same protocol, a Mastodon user can follow a Pixelfed photographer, comment on a Lemmy thread, and share a PeerTube video — all from one account.

How ActivityPub Works

ActivityPub is the W3C standard protocol that makes federation possible. It was published as a recommendation in 2018 and has since become the dominant federation protocol, replacing older alternatives like OStatus and Diaspora’s protocol. Here is a simplified overview of how it works.

Actors, Inboxes, and Outboxes

Every user account on a Fediverse server is an Actor with a unique address, formatted like @[email protected]. Each Actor has two endpoints:

• Inbox — receives activities (posts, follows, likes) from other servers
• Outbox — publishes activities to followers and federated servers

When you post something, your server places the activity in your outbox and delivers it to the inbox of every follower — including followers on remote servers. This is server-to-server communication, authenticated with HTTP Signatures.

Federation Flow

1. Alice on social.example follows Bob on photos.example. Alice’s server sends a Follow activity to Bob’s inbox.
2. Bob’s server accepts the follow and sends back an Accept activity.
3. When Bob posts a new photo, his server delivers a Create activity containing the post to Alice’s inbox.
4. Alice sees Bob’s photo in her timeline, despite being on a completely different server running different software.
5. If Alice replies, her server sends a Create activity with the reply to Bob’s inbox. Bob’s server displays it as a comment.

WebFinger and Discovery

How does social.example find photos.example? Through WebFinger, a simple lookup protocol. When Alice types @[email protected], her server queries https://photos.example/.well-known/webfinger?resource=acct:[email protected] and gets back Bob’s ActivityPub profile URL. From there, it can find his inbox, outbox, followers list, and public key for signature verification.

What Federates

ActivityPub defines a vocabulary of activities: Create, Follow, Like, Announce (boost/reblog), Delete, Update, Block, and more. Different platforms support different subsets. Mastodon posts federate cleanly with Pleroma and GoToSocial. Lemmy communities federate with other Lemmy instances and partially with Mastodon (comments appear as replies). Pixelfed photos appear as image posts on Mastodon. The protocol is flexible enough for all these use cases, though cross-platform federation is not always seamless.

Key Fediverse Platforms

Platform	Replaces	ActivityPub	Self-Hosting Difficulty	Docker Support	Resource Usage	License
Mastodon	Twitter/X	Yes	Medium-High	Yes	High (2GB+ RAM)	AGPL-3.0
Pleroma	Twitter/X	Yes	Medium	Yes	Low (512MB RAM)	AGPL-3.0
GoToSocial	Twitter/X	Yes	Low	Yes	Very Low (128MB RAM)	AGPL-3.0
Misskey	Twitter/X	Yes	Medium-High	Yes	High (2GB+ RAM)	AGPL-3.0
Lemmy	Reddit	Yes	Medium	Yes	Medium (512MB RAM)	AGPL-3.0
Pixelfed	Instagram	Yes	Medium	Yes	Medium (1GB+ RAM)	AGPL-3.0
PeerTube	YouTube	Yes	High	Yes	High (varies with transcoding)	AGPL-3.0
Funkwhale	Spotify/SoundCloud	Yes	Medium	Yes	Medium (512MB RAM)	AGPL-3.0
WriteFreely	Medium	Yes	Low	Yes	Low (256MB RAM)	AGPL-3.0
Bookwyrm	Goodreads	Yes	Medium	Yes	Medium (512MB RAM)	Anti-Capitalist License
Discourse	Forums	Plugin only	High	Yes	High (2GB+ RAM)	GPL-2.0
Flarum	Forums	No	Medium	Community	Medium (512MB RAM)	MIT

All ActivityPub platforms in this table can federate with each other to varying degrees. Mastodon, Pleroma, GoToSocial, and Misskey have the most complete interoperability since they all implement microblogging. Cross-platform federation (e.g., Lemmy threads appearing on Mastodon) works but with limitations — Mastodon does not natively understand Lemmy’s upvote/downvote system, for example.

Why Self-Host a Fediverse Server

You can join any public Fediverse instance for free. So why run your own?

Data ownership. On someone else’s instance, your posts, followers list, DMs, and media are stored on their server. If they shut down — and instances shut down regularly — your data may disappear. On your own instance, you control the database, the backups, and the retention policy.

Custom moderation rules. Every instance sets its own content policy and blocklist. Running your own means you decide exactly what content is allowed, which instances you federate with, and how aggressively you filter spam. No one else’s moderation decisions affect your experience.

Identity permanence. Your Fediverse identity is tied to your instance’s domain. If mastodon.social decides to purge inactive accounts or your instance admin disappears, you lose @[email protected]. Running your own instance on your own domain means @[email protected] stays yours as long as you keep the domain.

Community building. Many organizations, interest groups, and friend circles run private or semi-private instances. You can create a space for your team, your hobby group, or your local community with tailored rules and culture — something a megaserver cannot offer.

Learning and experimentation. Running a Fediverse server is an excellent exercise in managing real-world infrastructure: databases, background job queues, media storage, email delivery, TLS, reverse proxies, and federation debugging. You will learn more from one Mastodon deployment than from a dozen toy Docker projects.

Choosing a Platform

Pick based on what you want to run, how much server you have, and who your audience is.

For a personal microblog (just you, maybe a few friends): GoToSocial is the best choice. It uses minimal resources (runs comfortably on 128MB RAM), has a simple Docker setup, and implements enough of ActivityPub for full federation. It does not have its own web frontend — you use any Mastodon-compatible client app. If you want something even more feature-rich for a single user, Pleroma is lightweight and includes a built-in web UI. See the full comparison: Mastodon vs GoToSocial.

For a community instance (dozens to thousands of users): Mastodon is the most mature and widely adopted option. It has the best moderation tools, the largest ecosystem of client apps, and the most complete ActivityPub implementation. The trade-off is resource usage — expect 2GB+ RAM and a PostgreSQL database. If your users want a more feature-rich experience (reactions, custom emoji, pages, antennas), consider Misskey or one of its forks (Firefish, Sharkey, Iceshrimp). For a comparison of lighter alternatives, see Mastodon vs Pleroma.

For a link aggregator (Reddit-style communities): Lemmy is the only mature ActivityPub-enabled option. It supports communities, voting, moderation, and federation with other Lemmy instances. Discourse is more feature-rich as a forum platform but its ActivityPub support is limited to a plugin. See Lemmy vs Discourse for a detailed comparison, or Discourse vs Flarum if forums are your focus.

For photo sharing: Pixelfed directly replicates the Instagram experience with federation. It supports albums, stories, collections, and hashtag discovery across instances.

Getting Started

Every Fediverse server you self-host needs the same baseline infrastructure:

Prerequisites:

• A Linux server (VPS or home server) with at least 1GB RAM for lightweight platforms, 2GB+ for Mastodon or Misskey
• Docker and Docker Compose installed — see Docker Compose Basics
• A domain name pointed at your server’s IP address
• A reverse proxy handling TLS termination — see Reverse Proxy Explained
• An SMTP email service for sending notifications (user registration, password resets, follow notifications)

General setup flow:

1. Pick your platform from the table above.
2. Set up your domain and DNS records.
3. Deploy the platform using Docker Compose — each app guide linked above walks through the complete configuration.
4. Configure your reverse proxy to route traffic from your domain to the container.
5. Set up email delivery (most platforms need outbound SMTP).
6. Create your admin account and configure instance settings (name, description, rules, registration policy).
7. Start posting. Federation happens automatically as you follow users on other instances.

Harden your server before opening it to the internet. TLS is mandatory for federation (ActivityPub requires HTTPS), and you should configure firewalls and fail2ban at minimum. See Security Hardening for a complete checklist.

Federation Gotchas

Running a Fediverse server is not like running a private web app. Federation introduces a set of challenges you will not encounter with most self-hosted software.

Discovery Takes Time

When you start a new instance, nobody knows it exists. Your posts will not appear in search results or on other instances’ federated timelines until someone on those instances follows you. Building a presence takes days to weeks. You can accelerate this by following active accounts on popular instances, joining relay servers (which automatically distribute posts across subscribing instances), and sharing your profile on existing social media.

Relays

A relay is a server that redistributes ActivityPub activities to all subscribing instances. Joining a relay means your instance’s public posts are broadcast to potentially thousands of other instances, and you receive their public posts in return. This fills your federated timeline and makes your instance more discoverable. The trade-off is increased storage usage and network traffic. Popular relays include relay.fedi.buzz and relay.intahnet.co.uk. Configure them in your instance’s admin panel.

Moderation Is Your Responsibility

When you run a public instance, you are responsible for moderating all content posted by your users. Other instance admins may defederate (block) your entire instance if your users post spam, harassment, or illegal content and you do not act. This is a real operational burden. Tools to manage it:

• Domain blocks — block entire instances known for abuse
• Blocklists — community-maintained lists of known-bad instances (e.g., thebad.space, Oliphant blocklist)
• Automated moderation — some platforms support keyword filters, link blockers, and automated reporting
• Registration approval — require manual approval for new signups to prevent bot accounts

If you are running a single-user instance, moderation is trivial. For community instances, budget real time for this.

Media Storage Grows Fast

Federated content includes avatars, headers, and media attachments from every account your users follow — across all instances. Mastodon instances routinely accumulate tens of gigabytes of cached remote media. Configure media retention policies (Mastodon’s tootctl media remove command, for example) and plan your storage accordingly. Object storage (S3-compatible) is recommended for any instance expecting more than a handful of users.

Domain Changes Break Federation

Your domain is your identity. ActivityPub actors are addressed by domain, and federation history is tied to it. If you change your domain, your followers on other instances will not automatically update — you effectively start over. Choose your domain carefully and treat it as permanent. Some platforms support account migration (Mastodon does), but it is not seamless and not all followers transfer.

Not Everything Federates Cleanly

Cross-platform federation works for basic activities (posts, replies, likes, boosts) but breaks down for platform-specific features. Lemmy’s upvote/downvote system does not translate to Mastodon. Misskey’s custom reactions appear as generic likes on Mastodon. Pixelfed’s alt text may or may not render correctly on every platform. Polls, content warnings, and formatting (Markdown vs HTML) also vary. Test cross-platform interactions before assuming they work.

Related

• How to Self-Host Mastodon
• How to Self-Host GoToSocial
• How to Self-Host Pleroma
• How to Self-Host Misskey
• How to Self-Host Lemmy
• How to Self-Host Pixelfed
• How to Self-Host Discourse
• How to Self-Host Flarum
• Mastodon vs GoToSocial
• Mastodon vs Pleroma
• Lemmy vs Discourse
• Discourse vs Flarum
• Best Self-Hosted Social Networks
• Best Self-Hosted Fediverse Platforms
• Docker Compose Basics
• Reverse Proxy Explained
• Security Hardening