Ensuring Security, Privacy, and Compliance on Your Mastodon Instance
Managing a Mastodon instance carries real security and legal weight, even if you’re running a small community for a dozen people. The work is not complicated, but it is unforgiving. This article deals with the measures that actually matter, what GDPR and the DSA require in practice, how Mastodon’s privacy settings behave, and the way federation complicates all of it.
The security basics that stop most problems
The first line of defence is boring for a reason. Keep Mastodon updated. The development team ships security patches regularly, and running an old version is one of the easiest ways to expose users to avoidable risk. Subscribe to release notifications, patch within a few days where you can, and use staging if the instance is large enough to justify it. Automating OS dependency updates takes one more quiet failure out of the equation.
SSH needs proper handling too. Key-based authentication should be the default, not an optional extra. Password-based SSH is just asking for brute-force attempts. Change the default port, install fail2ban, and treat unusual login activity as something to check rather than something to wave away.
The firewall side is simple. Only HTTP, HTTPS, and SSH need to be open to the public. Everything else should be blocked inbound by default.
TLS should be locked down properly as well. Force HTTPS everywhere, set HSTS headers, redirect HTTP traffic, and use Let’s Encrypt with automatic renewal. Letting a certificate expire is the sort of incident that should never happen, because it is almost always preventable.
Database setup is another place where small instances often get loose. PostgreSQL should use a strong password, accept connections only from trusted networks, and use SSL for any remote connection. Backups need regular restore tests. A backup you have never restored is not something you can trust.
Mastodon’s secrets - secret_key_base, OTP secrets, VAPID keys - should stay out of version control. Keep them separate from the codebase, use different values in each environment, and rotate them if you have any reason to think they may have been exposed.
GDPR obligations for instance operators
If your instance accepts users from EU countries, GDPR applies. That is true whether the server serves 10 people or 10,000. As the data controller, you need records of your processing activities, a clear and accurate privacy policy, and a lawful basis for the data you collect - usually consent or legitimate interest, depending on what you are doing.
Mastodon does cover several of the rights users expect under GDPR. People can export their own data, delete their accounts, and download machine-readable exports. They can also edit their profile details directly. What the software does not do is write the privacy policy for you or decide how long you keep data after an account is closed. Those calls sit with the operator.
Retention policy is where a lot of small instances get sloppy. Decide how long to keep data after deletion, configure cleanup jobs to match that policy, and make sure the privacy policy reflects what actually happens rather than what sounds tidy on paper. That includes old media and server logs. If you keep them, say so. If you purge them, do it on a schedule.
Federation makes GDPR harder to reason about. Public content is distributed to other instances, and you do not control how those instances handle it. ActivityPub deletion requests do propagate, but there is no enforcement mechanism. A remote instance may honour them, or it may not. That is not a reason to panic, but it does need to be explained honestly in the privacy policy.
What the DSA means for smaller instances
The EU’s Digital Services Act applies to Mastodon instances available to EU users. The obligations scale with size, so a small server has fewer formal requirements than a large one. That does not remove moderation duties.
In practice, you need clear terms of service, a working way for users to report content, and a process for acting on those reports promptly. Moderation decisions should be recorded and kept consistent. If illegal content turns up, you need a process before the report arrives, not a scramble afterwards. Cooperation with law enforcement, within your jurisdictional rules, and clear records of how you responded are part of that too.
Transparency reports are encouraged and, depending on scale, may eventually be mandatory. Even where they are not required yet, a public summary of moderation activity shows that the rules are being applied rather than left as decoration.
Mastodon’s privacy settings, without the gloss
Mastodon offers four post visibility levels.
Public posts appear in timelines and search and are visible to anyone. Unlisted posts show on your profile but stay out of timelines and search results. They are useful for posts you do not want amplified, but do not need to hide. Followers-only posts go only to confirmed followers. Direct posts go only to the users mentioned in the post.
That last setting needs a blunt reminder: direct messages on Mastodon are not end-to-end encrypted. Instance admins can technically read them. That is not a flaw in the software so much as a reflection of how the platform works. Mastodon is built around public conversation, not private messaging. If something is genuinely sensitive, use an encrypted messenger.
The profile settings matter too. The discoverable flag controls whether the account appears in directories and search results. The indexable flag affects whether posts are indexed. A locked account requires approval before new followers can see followers-only content. These are not settings to leave on autopilot.
Federation and where privacy stops
Federation changes the privacy picture in ways that do not have neat answers. When a post is public, it is distributed to every server where someone follows the account, and sometimes beyond that depending on boosting and caching on remote instances. Admins on those servers can access the content. If you defederate from an instance later, that does not automatically erase content already shared there. It only stops new content from flowing.
Metadata matters as well. Federation logs reveal communication patterns between instances even when the actual content is not obvious. None of this makes Mastodon unusable. It does mean privacy on the fediverse works differently from privacy on a closed platform, and users should understand that before they post.
Planning for incidents before they land
The most common incidents on Mastodon instances are account compromises from weak or reused passwords, spam and bot invasions, DDoS attacks, and data breaches. It is much easier to deal with any of them if the response plan already exists.
A sensible response runs in a fixed order. First, detection: watch logs and user reports for odd patterns. Then containment: suspend compromised accounts, block spam sources, and turn on rate limiting where needed. After that comes investigation, to work out the scope and origin of the problem before guessing at the cause. Remediation follows - fix the underlying vulnerability, rotate credentials, and repair the damage. Communication comes next. Tell users what happened and what has been done about it, without waiting for a perfect narrative. Finally, review the incident and update the procedure.
See our developer notes for more on technical monitoring approaches.
Common mistakes that keep showing up
Small instances are not insulated from security incidents just because they are small. If anything, they are more likely to run outdated software and less likely to have anyone watching the logs. That is a real risk, not a theoretical one.
Backups should be encrypted. An unencrypted backup of user data becomes a liability the moment the storage medium is lost or compromised. Keep backups somewhere separate from the primary server as well.
GDPR compliance is not optional for hobby instances that accept EU users. Instance size affects how you implement the obligations, not whether they apply at all.
Another persistent misunderstanding is direct messages. People assume privacy that Mastodon does not provide. Say plainly, in the instance documentation and privacy policy, that admins can technically access DMs.
Incident response has the same problem. If the plan does not exist before the incident, the incident is where everyone starts arguing about responsibility. That is the wrong time.
FAQs
Is a privacy policy necessary for my Mastodon instance? Yes. If your instance is accessible to EU users, a clear and accurate privacy policy is a GDPR requirement, not optional documentation.
Can admins read DMs on Mastodon? Technically, yes. Direct messages are not end-to-end encrypted, so instance admins can access them at the database level. For anything genuinely sensitive, use a dedicated encrypted messenger.
What happens to my data if my instance closes? Data is lost unless it has been exported beforehand. Mastodon provides migration and export tools, but they only help if you use them before the instance goes offline.
Does Mastodon ensure out-of-the-box GDPR compliance? Mastodon provides tools that support compliance - data export, account deletion, and similar functions - but compliance still depends on how the instance is configured and operated, and on the policies that sit around it.
How do I report a security vulnerability in Mastodon? Follow Mastodon’s responsible disclosure process as set out in their security policy.
Does the DSA apply to all Mastodon instances? Yes, if the instance is accessible to EU users. Formal obligations scale with instance size, so smaller servers have fewer requirements, but content moderation duties apply regardless of scale. Check our articles hub for updates as implementation guidance develops.