Mastodon relays collect public posts from multiple instances and redistribute them to all connected servers. This feature helps small instances discover content from the wider fediverse without manually following every user. However, relays can consume significant bandwidth because every post from every connected instance is pulled into your server. This article explains how relay bandwidth is calculated, what monthly data volumes you can expect, and how to manage costs on your Mastodon server.
Many new admins are surprised when their server’s data transfer spikes after enabling a single relay. The root cause is that relays do not filter posts by language, topic, or user activity. Your server downloads all public posts from every instance in the relay pool. This article will help you estimate bandwidth usage, choose the right relay settings, and avoid unexpected hosting bills.
Key Takeaways: Mastodon Relay Bandwidth Costs
- Relay bandwidth formula: Monthly bandwidth = (average post size × posts per relay per day × 30) × number of connected relays.
- Admin > Relays > Relay list: Shows current relays, their post volume, and last activity; remove inactive or high-volume relays here.
- Instance-side filtering: You cannot filter relay content on your server; choose relays that match your instance’s language and topic to reduce waste.
Why Mastodon Relays Consume So Much Bandwidth
A Mastodon relay acts as a redistribution hub. When an instance sends a public post to the relay, the relay forwards that post to every other connected server. Your server must accept and process every forwarded post, even if your local users never interact with it. This is fundamentally different from following individual accounts, where you only receive posts from users you explicitly follow.
The bandwidth cost depends on three factors: the number of relays you join, the total number of posts those relays forward each day, and the average size of each post including media attachments. A relay with 500 connected instances may forward tens of thousands of posts daily. If your server joins five such relays, you could receive over 150,000 posts per day. Each post carries text, metadata, and potentially images or videos. A single image can be 500 KB or more, and a short video can be 5 MB or more.
How Relay Post Volume Accumulates
Relays do not deduplicate posts. If the same post appears on two different relays you are connected to, your server downloads it twice. This duplication multiplies bandwidth quickly. For example, a popular post that is federated through three relays will be downloaded three times by your server. The Mastodon server software does not cache or skip duplicate deliveries from relays.
Media Attachment Impact
Text-only posts are small, typically 1 KB to 5 KB. But many posts contain images, GIFs, or videos. Mastodon servers download media attachments immediately when a post is received. There is no option to defer or skip media downloads from relay traffic. If a relay forwards 10,000 posts per day and 20 percent contain an image averaging 300 KB, that adds 600 MB of daily media download traffic. Over 30 days, that is 18 GB of media bandwidth alone.
Estimating Monthly Bandwidth for Your Instance
To calculate your expected bandwidth, start by checking your current relay list. Go to Preferences > Administration > Relays on your Mastodon server. Note the number of relays you are connected to. Then check the relay’s own statistics page if available. Many relays publish their daily post count. If not, you can estimate based on instance size. A medium-sized relay serving 200 instances may forward 8,000 to 15,000 posts per day.
Use this formula to estimate monthly bandwidth:
Monthly GB = (posts per day × average post size in MB × 30) / 1024
For example, 10,000 posts per day with an average size of 0.3 MB gives 90 GB per month per relay. Multiply by the number of relays. If you use three relays, that is 270 GB per month just from relay traffic. This does not include regular user-to-user federation, media caching, or API calls.
Tools to Measure Actual Bandwidth
Use your hosting provider’s bandwidth monitoring dashboard to see actual data transfer. On a Linux server, you can use vnstat or iftop to track traffic per interface. Compare traffic before and after enabling a relay to isolate relay costs. Some admins also monitor the Mastodon sidekiq queues to see how many incoming posts are being processed per minute.
Steps to Reduce Relay Bandwidth Costs
You cannot filter relay content on your own server. The only control you have is which relays you join. Follow these steps to reduce bandwidth consumption.
- Audit your current relays
Go to Preferences > Administration > Relays. Review the list of enabled relays. Remove any relay that does not serve your community’s language or interests. Click the Delete button next to each unwanted relay. - Choose topic-specific relays
Instead of joining general relays that forward all public posts, look for relays focused on a specific language, topic, or region. For example, a German-language relay will forward mostly German posts. A photography relay will forward mostly image posts. This reduces irrelevant traffic. - Limit the number of relays
Join only one or two high-quality relays. Many small instances need only one relay to discover new content. Each additional relay adds linear bandwidth cost without proportional benefit. - Monitor relay activity weekly
Set a recurring calendar reminder to check relay statistics. If a relay becomes inactive or starts forwarding spam, remove it immediately. Inactive relays still consume bandwidth if they occasionally forward posts. - Consider not using relays at all
If your instance has fewer than 50 active users, relays may not be necessary. Users can follow hashtags and individual accounts directly. Disable all relays from Preferences > Administration > Relays and monitor whether user engagement drops.
Common Mistakes That Increase Relay Bandwidth
Joining Multiple General Relays at Once
New admins often join three or four general relays to get content quickly. This multiplies bandwidth because the same posts appear on multiple relays. Start with one relay and wait two weeks. If you need more content diversity, add a second relay only if the first one is not covering your desired topics.
Ignoring Media Attachment Size Limits
Your server’s media attachment size limit affects how much data is downloaded for each post. Mastodon defaults to 8 MB per file. If you raise this limit to 20 MB or 40 MB, relay bandwidth increases proportionally for posts containing large media. Keep the default limit unless your community specifically needs high-resolution images or longer videos.
Not Using a CDN for Media Delivery
While a CDN does not reduce inbound relay traffic, it reduces outbound bandwidth when users view media. This can lower your total bandwidth bill if you pay for outbound data. Configure a CDN like Cloudflare or Bunny CDN to cache media files. Outbound bandwidth for cached media is served from the CDN, not your server.
| Item | No Relay | One General Relay | Three General Relays |
|---|---|---|---|
| Daily inbound posts | 500 | 10,000 | 30,000 |
| Monthly bandwidth estimate | 4.5 GB | 90 GB | 270 GB |
| Media storage growth per month | 1.5 GB | 30 GB | 90 GB |
| Server CPU load | Low | Moderate | High |
Bandwidth estimates assume 10,000 posts per relay per day with an average post size of 0.3 MB including media. Actual values vary by relay and instance.
Conclusion
You can now estimate your Mastodon relay bandwidth cost using the formula provided and reduce it by auditing your relay list, choosing topic-specific relays, and limiting the number of relays to one or two. Start by removing any relay that does not match your instance language or topic. For advanced control, consider running your own private relay that only forwards posts from specific instances you approve. This gives you full control over inbound traffic and eliminates duplicates from public relays.