How to Use Authorized Fetch With a Single-User Instance

Single-user Mastodon instances are private servers where you run your own account without sharing the instance with other users. These instances can still receive malicious requests from unverified remote servers that pretend to be someone else. Authorized fetch is a security feature that forces all incoming federation requests to carry a valid signature from the requesting server. When enabled, it prevents unauthorized servers from pulling your public posts without your instance approving the connection. This article explains how to enable authorized fetch on a single-user instance and what changes you can expect after turning it on.

What Authorized Fetch Does and Why Single-User Instances Need It

Authorized fetch is a Mastodon security mode that rejects incoming federation requests unless the requesting server proves its identity with a cryptographic signature. In normal mode, Mastodon accepts unsigned requests from any remote server that asks for a user’s public posts. This open behavior allows third parties to scrape public timelines without the instance owner knowing. On a single-user instance, the risk is lower because there is only one account, but the instance still exposes public posts to anyone who sends a GET request to the right API endpoint.

When you enable authorized fetch, Mastodon checks every incoming request for a valid HTTP signature signed by the remote server’s private key. If the signature is missing or invalid, the request is denied with a 401 Unauthorized response. This prevents unverified servers from downloading your posts, boosts, or follower lists. The feature is sometimes called “secure mode” in the Mastodon documentation.

Single-user instances benefit from authorized fetch because they have no moderation team to review suspicious traffic. The instance owner is the only user, so any unauthorized data pull goes unnoticed until damage is done. Enabling authorized fetch adds a layer of protection without requiring additional moderation tools. The trade-off is that some legitimate servers that do not sign their requests will be unable to fetch your posts. In practice, most modern Mastodon instances and Pleroma instances sign their requests, so the impact is minimal.

Steps to Enable Authorized Fetch on a Single-User Instance

The process differs depending on how you run Mastodon. The two most common setups are Docker Compose and a systemd-based installation. Both methods require you to set an environment variable and restart services.

For Docker Compose Installations

1. Open your Docker Compose file
   Navigate to the directory containing your docker-compose.yml file. This file is usually located in /opt/mastodon or /srv/mastodon. Edit the file with a text editor such as nano or vim.
2. Add the AUTHORIZED_FETCH environment variable
   Find the environment block under the web service. Add a new line: AUTHORIZED_FETCH=true. If the block does not exist, create it under the web service. Repeat this step for the streaming and sidekiq services if they are defined separately.
3. Save the file and restart the containers
   Run docker-compose down followed by docker-compose up -d. This stops all containers and starts them again with the new environment variable. Verify the containers are running with docker-compose ps.

For systemd Installations

1. Edit the Mastodon environment file
   Open the file .env.production located in your Mastodon root directory, typically /home/mastodon/live. Use a text editor to add the line AUTHORIZED_FETCH=true at the end of the file.
2. Restart Mastodon services
   Run sudo systemctl restart mastodon-web, sudo systemctl restart mastodon-streaming, and sudo systemctl restart mastodon-sidekiq. You can combine these into one command: sudo systemctl restart mastodon-{web,streaming,sidekiq}.
3. Confirm the services are active
   Use sudo systemctl status mastodon-web to check that the web service started without errors. Look for the line “Authorized fetch enabled” in the logs.

What Changes After Enabling Authorized Fetch

Once authorized fetch is active, your instance will reject all unsigned federation requests. This means that remote servers that do not sign their requests will be unable to pull your posts. In practice, this affects a small number of outdated or misconfigured servers. Your own posts will still appear in the federated timeline of other instances, because your instance signs the outbound requests it sends.

You can verify that authorized fetch is working by checking your Mastodon logs. Look for entries that say “Unauthenticated request rejected” or “Authorized fetch enabled.” If you see these messages, the feature is active. You can also test by sending a direct HTTP request to your instance’s API endpoint for public posts without a signature. The response should be a 401 error.

Common Issues After Enabling Authorized Fetch

Remote Servers Cannot Fetch My Posts

If a specific remote server cannot fetch your posts after you enable authorized fetch, the problem is likely that the remote server does not sign its requests. This is common with very old Mastodon versions or non-Mastodon software that does not implement HTTP Signatures. There is no workaround on your end. The remote server administrator must update their software to support signed requests.

My Own Posts Disappear From Other Instances

If your posts stop appearing on other instances, the issue is usually that the remote instance is rejecting your outbound requests. This is not caused by authorized fetch on your side. Check your instance’s outbound federation logs. The remote instance may have blocked your instance or may be experiencing a temporary network issue.

Increased CPU or Memory Usage

Authorized fetch adds signature verification overhead to every incoming request. On a single-user instance with low traffic, the impact is negligible. If you run a very busy instance, you may notice a slight increase in CPU usage. Monitor your server’s resource usage with top or htop after enabling the feature.

Authorized Fetch vs Default Federation Mode

Item	Authorized Fetch Enabled	Default (No Authorized Fetch)
Request authentication	Requires valid HTTP signature	Accepts unsigned requests
Data scraping protection	Blocks unverified scrapers	Allows any server to pull public data
Compatibility with old servers	May block outdated servers	Compatible with all servers
Configuration effort	One environment variable change	No configuration needed

Enabling authorized fetch on a single-user instance is a straightforward security hardening step. The feature requires no ongoing maintenance once set up. If you later decide to disable it, simply remove the AUTHORIZED_FETCH=true line from your configuration and restart the services. After disabling, your instance will return to accepting unsigned requests. For most single-user instance owners, the added protection against data scraping outweighs the minor compatibility risk with outdated servers.