When you run a Mastodon instance, you have two primary methods to populate the federated timeline with content from other servers: joining a relay or configuring direct federation with specific instances. The federated timeline shows public posts from instances your server follows. Without either method, your users see only local posts. This article explains how relays and direct federation work, compares their tradeoffs in bandwidth, content control, and moderation overhead, and helps you decide which approach fits your community.
Key Takeaways: Relay vs Direct Federation for Mastodon Admins
- Relay subscription via Preferences > Administration > Relays: Automatically pulls public posts from all instances connected to the relay, increasing content volume with minimal manual effort.
- Direct federation via Preferences > Administration > Domain Blocks > Allow: Manually whitelist specific instances to follow their public posts, giving you full control over content sources.
- Bandwidth and storage tradeoff: Relays consume significantly more server resources than direct federation, especially on small or single-admin instances.
How Relays and Direct Federation Work in Mastodon
Mastodon uses the ActivityPub protocol to exchange public posts between instances. When your instance follows another instance, it receives all public posts from that instance. The federated timeline on your instance displays these incoming posts alongside local posts.
Relay Mechanism
A relay is a dedicated Mastodon account or service that re-broadcasts public posts from all connected instances. When you subscribe to a relay, your instance follows the relay account. The relay then pushes public posts from every instance in its network to your instance. This creates a one-to-many distribution model. Popular relay operators include relay.mastodon.au, relay.fedi.buzz, and instance-specific relays.
Direct Federation Mechanism
Direct federation means your instance manually follows another instance. You enter the instance domain in your server settings, and Mastodon sends a follow request. Once accepted, your instance receives all public posts from that instance. This is a one-to-one relationship. You can follow hundreds of instances this way, but each follow requires manual configuration.
Comparing Relay and Direct Federation Tradeoffs
The choice between a relay and direct federation affects server load, content diversity, moderation workload, and community experience. Below are the key tradeoffs.
Bandwidth and Storage Consumption
Relays send a high volume of posts. A single relay can deliver thousands of posts per hour to your instance. This consumes significant bandwidth and database storage. Direct federation lets you choose low-volume or topic-specific instances, reducing total data flow. For a small instance with limited VPS resources, direct federation is more sustainable.
Content Control and Moderation
With direct federation, you know exactly which instances contribute to your federated timeline. You can vet each instance before following it. With a relay, you receive posts from all instances connected to the relay, including ones you might not want. You must then rely on domain blocks and keyword filters to remove unwanted content. This increases moderation overhead.
Content Diversity and Discoverability
Relays provide a broad, unpredictable stream of posts from many communities. This can help users discover new topics and instances. Direct federation limits content to the instances you explicitly choose, which may create a smaller, more curated timeline. For a general-purpose instance, a relay offers richer discoverability.
Setup and Maintenance Effort
Setting up a relay requires finding a relay operator and entering its URL in your admin panel. That is a one-time action. Direct federation requires manually finding and following each instance. If you want a timeline with 50 instances, you need 50 manual follows. Maintenance also differs: if a relay goes offline, your federated timeline empties until you switch relays. With direct federation, a single instance going offline only removes that instance’s posts.
Steps to Configure Each Method
Both methods are configured in the Mastodon admin panel. You need admin access to your instance.
Subscribe to a Relay
- Open Administration > Relays
In your Mastodon web interface, go to Preferences > Administration > Relays. This page lists existing relay subscriptions. - Enter the relay URL
In the text field, paste the relay URL. Example:https://relay.mastodon.au/actor. Click the Add button. - Enable the relay
After adding the relay, click the Enable button next to its entry. Mastodon sends a follow request to the relay. Wait for the relay to accept. The status changes to Enabled when the connection is active. - Verify the federated timeline
Open the federated timeline. You should see public posts from instances connected to the relay within minutes.
Directly Follow an Instance
- Open Administration > Domain Blocks
Go to Preferences > Administration > Domain Blocks. This page manages allowed and blocked domains. - Add the instance domain
Click the Add button. In the Domain field, enter the instance domain name. Example:mastodon.social. Set the Severity to Allow. Click Save. - Wait for synchronization
Mastodon sends a follow request to the instance. The receiving instance must accept. Acceptance happens automatically for most public instances. The federated timeline begins showing posts from that instance within a few minutes. - Repeat for additional instances
Add each instance you want to follow. There is no limit, but each follow consumes resources.
Common Mistakes and Limitations
Relay Overload on Small Instances
A relay can overwhelm a small instance with a single CPU core and 2 GB RAM. The database grows rapidly, and the sidekiq queue backs up. Monitor your server load after enabling a relay. If CPU usage stays above 80 percent, switch to direct federation with a few high-quality instances.
Direct Federation Without Whitelisting
Simply allowing an instance does not guarantee you receive all its public posts. The remote instance must also allow your instance to follow it. If your instance is not whitelisted by the remote instance, the follow request may be ignored. Confirm the remote instance’s federation policy before adding it.
Relay Dependency
If the relay operator shuts down or changes its URL, your federated timeline stops receiving new posts. You must find and subscribe to a new relay. Direct federation does not have this single point of failure. If one instance goes offline, others still deliver content.
Relay vs Direct Federation: Key Differences
| Item | Relay | Direct Federation |
|---|---|---|
| Setup effort | One URL entry | Manual follow per instance |
| Bandwidth usage | High | Low to moderate |
| Content diversity | Broad and unpredictable | Curated and predictable |
| Moderation control | Reactive (block after seeing content) | Proactive (choose content sources) |
| Server resource impact | High | Low |
| Single point of failure | Yes (relay goes down) | No (multiple independent sources) |
You can combine both methods. Use one relay for broad content discovery and add direct follows for specific communities you trust. Monitor your server resources and adjust as your instance grows.