If your Mastodon instance uses a public relay, your local timeline can become cluttered with posts from servers that have no connection to your community. A public relay indiscriminately distributes all messages from all connected servers, which can overwhelm small instances with irrelevant content. Switching to a private relay gives you control over which remote servers your instance follows, keeping your federated timeline focused and manageable. This article explains how to leave a public relay and subscribe to a private relay instead, with step-by-step instructions for Mastodon server administrators.
Key Takeaways: Switching Mastodon Relays
- Administration > Relays > Unsubscribe from relay: Removes your instance from a public relay and stops receiving its messages.
- Administration > Relays > Add relay: Subscribes your instance to a private relay by entering the relay's inbox URL.
- Private relay invitation: You must obtain the relay's inbox URL from the relay operator before you can subscribe.
What a Mastodon Relay Does and Why You Might Switch
A Mastodon relay is a server that acts as a message broker between multiple Mastodon instances. When you subscribe your instance to a relay, your server sends its public posts to the relay, and the relay forwards posts from all other subscribed servers back to your instance. This effectively populates your federated timeline with content from many servers at once, without you having to manually follow each one.
Public relays accept any instance that requests a subscription. This open-door policy means you have no control over which servers contribute content to your timeline. You may receive posts in languages your community does not speak, or content that violates your instance's rules. Private relays require an invitation or approval from the relay operator. Only servers that the operator adds to an allowlist can subscribe. This gives you direct control over the sources of federated content.
Switching from a public relay to a private one involves two operations: unsubscribing from the public relay and subscribing to the private relay. The order matters. If you subscribe to the private relay first and then unsubscribe from the public one, your instance will briefly receive duplicate messages. To avoid this, always unsubscribe from the public relay first.
Steps to Unsubscribe From a Public Relay and Subscribe to a Private Relay
These steps require administrative access to your Mastodon instance. You must be logged in as an admin or moderator with the manage relays permission. If you do not have this permission, contact your instance owner.
- Open the Administration panel
Click the Preferences link in the navigation bar on the right side of the Mastodon web interface. On the Preferences page, click Administration in the left sidebar. If you do not see Administration, you do not have the required permissions. - Navigate to the Relays page
In the Administration section, click Relays. The Relays page lists every relay your instance is currently subscribed to, along with its status, inbox URL, and the number of messages received. - Identify the public relay you want to leave
Check the inbox URL of each relay. Public relays often have generic names like relay.example.com or pub-relay.social. If you are unsure which relay is public, ask the relay operator or consult your instance's documentation. A private relay's URL will be shared only with approved instances. - Unsubscribe from the public relay
Next to the public relay entry, click the Unsubscribe button. A confirmation dialog appears. Click OK or Confirm. Your instance immediately stops receiving new messages from that relay. Existing messages that were already delivered remain in your database. They are not removed. - Obtain the private relay inbox URL
Contact the operator of the private relay you want to join. Ask them for the relay's inbox URL. This URL typically looks like https://relay.example.com/inbox. The operator may require you to provide your instance's domain name before they add you to the allowlist. Do not proceed until you have the URL. - Add the private relay
Back on the Relays page, click the Add relay button. In the dialog that opens, paste the private relay's inbox URL into the text field. Click Add relay. Your instance sends a subscription request to the relay. - Wait for the relay to approve your subscription
If the relay operator configured an automatic allowlist, the subscription is approved immediately. If the operator manually approves requests, your instance will show a status of Pending. Once approved, the status changes to Active. Messages from the relay begin flowing into your federated timeline shortly after approval. - Confirm the relay is working
After the status shows Active, check your federated timeline. You should see posts from servers that are members of the private relay. If you see no new posts after 15 minutes, verify that the relay URL is correct and that the operator has approved your instance.
If the Relay Switch Does Not Work as Expected
Public relay still appears in the relay list after unsubscribing
If the public relay remains visible after you click Unsubscribe, refresh the Relays page. Mastodon may take a few seconds to update the UI. If the relay persists after a refresh, check your browser's cache or try a different browser. In rare cases, a database error can prevent the unsubscribe action from completing. Check the Mastodon server logs for error messages related to relay operations.
Private relay subscription stays in Pending status for days
A Pending status that lasts more than 24 hours usually means the relay operator has not approved your instance. Contact the operator directly and confirm that they received your subscription request. If the operator added your instance to the allowlist but the status does not change, ask them to restart the relay service. If you cannot reach the operator, consider finding a different private relay.
Federated timeline becomes empty after switching relays
This can happen if you unsubscribed from the public relay before the private relay became active. The gap between the two operations leaves your instance with no relay subscription. Recheck the status of the private relay. If it is still Pending, wait for approval. If it is Active but your timeline is empty, verify that other servers in the private relay are actually posting. You can test this by manually following a server that belongs to the relay. If that server's posts appear in your timeline, the relay is working and the issue is simply low activity.
Messages from servers not in the private relay still appear
A relay only controls messages that pass through it. Your instance may still receive posts from servers that your users manually follow, or from servers that were already followed before you switched relays. This is expected behavior. A relay supplements, not replaces, direct follows. To fully restrict federated content to only the private relay, you would need to disable the federated timeline entirely, which is not recommended for most instances.
Public Relay vs Private Relay: Key Differences
| Item | Public Relay | Private Relay |
|---|---|---|
| Subscription method | Open to any instance | Requires operator invitation or approval |
| Content control | No control over which servers contribute posts | Operator controls allowlist of participating servers |
| Setup time | Instant after adding the relay URL | May take hours or days if manual approval is needed |
| Risk of unwanted content | High, because any server can join | Low, because only approved servers participate |
| Maintenance burden | Low, the relay handles everything | Moderate, operator must manage allowlist and approve requests |
After switching to a private relay, your instance will receive only the posts that the relay operator approves. This keeps your federated timeline relevant to your community. If you ever want to revert to a public relay, simply repeat the steps in reverse: unsubscribe from the private relay and subscribe to a public one. Remember that you can subscribe to multiple relays at once, but each relay adds to the total message volume your server must process. Monitor your server's resource usage after switching to ensure the new relay does not overload your instance.