Owning a Mastodon server means full control over your social media presence: your data, your rules, your users. It also means you are responsible for maintenance, moderation, security updates and costs. That trade-off is real, and worth thinking through carefully before you commit.
What follows covers how to set up and run a Mastodon server in 2026 - from choosing infrastructure to keeping things running once you go live.
Is Self-Hosting Actually Right for You?
Running a Mastodon instance is not a casual weekend project. You need working knowledge of Linux system administration: configuring web servers, managing PostgreSQL, understanding basic networking. Docker makes some things easier, but it does not replace those fundamentals. If you have never touched a VPS before, expect a steep learning curve.
Time is the cost most people underestimate. Monthly software updates and prompt security patches are non-negotiable. Moderation demands consistent attention even on a single-user setup, because you are still federating with the wider network and other admins will contact you when something goes wrong.
On the financial side, a bare-bones VPS starts at roughly £10-15 per month. That number grows with your instance, and media storage in particular has a habit of outpacing compute costs within six months of active use. Plan for it from day one rather than scrambling later.
There are also legal obligations to consider. Depending on your location and who uses your instance, you may be subject to GDPR or equivalent local regulations. As the operator, you are the data controller. That is not a technicality.
If any of that gives you pause, joining an established instance is a perfectly reasonable alternative. Our FAQ can help you weigh the options.
Planning Your Infrastructure
How much server you need depends almost entirely on how many users you are running for. For one to fifty users, a minimum of two CPU cores and 4 GB of RAM will get you started, though 8 GB is noticeably more comfortable. Around 40 GB of disk is enough for the application itself, but media storage should be handled separately from the outset.
Once you move into the fifty to five hundred user range, you are looking at four or more cores and 8 to 16 GB of RAM, and object storage becomes essential rather than optional. Federation traffic is constant at this scale and grows with your user count.
Media accumulates faster than most people expect. Even a single user pulling federated media can rack up several gigabytes a month without trying.
For hosting providers, DigitalOcean, Hetzner and Linode are all solid choices. Hetzner’s pricing is particularly attractive if you are based in Europe. If you want the benefits of owning your own domain without carrying the full operational burden, managed solutions like Masto.host or Fedi.Monster are worth looking at as a middle ground.
Home server setups are technically viable for single-user instances, but they require a static IP, decent upload bandwidth and a UPS for power redundancy. Upload speed becomes a bottleneck under peak federation load, which makes home hosting unsuitable for anything beyond personal use.
Setting Up the Server
Domain and DNS
Choose your domain carefully. It becomes the permanent identity of your instance across the fediverse, and changing it later causes real disruption to federation relationships. Set up an A record pointing to your server’s IP. If you are using a CDN, add a CNAME for your media subdomain.
Preparing the Server
Start with Ubuntu 24.04 LTS or Debian 12. LTS releases are the sensible choice here - they avoid the dependency conflicts that crop up with shorter-release cycles. Once you have a base system, update all packages, configure your firewall to allow HTTP, HTTPS and SSH, create a non-root user with sudo access, and install Node.js, Ruby, PostgreSQL, Redis and Nginx.
Installing Mastodon
Deploying via Docker is generally the easier path. It sidesteps Ruby version conflicts and makes future updates more predictable. The process involves cloning the Mastodon repository, configuring your .env.production file, initialising the database and starting the services.
Bare-metal installation gives you finer control over resource allocation, but it is significantly more involved - you will need to install Ruby and Node.js manually, compile Mastodon and configure Systemd services yourself. Unless you have a specific reason to avoid Docker, most operators do not find the extra complexity worthwhile.
Core Services
PostgreSQL handles all of Mastodon’s database work. Set up automated backups before you go live, not after. Connection pool exhaustion is a common source of errors as instances grow, so keep an eye on your connection limits.
Redis manages caching and job queues. Default settings are fine for small instances, but memory usage climbs with scale and deserves monitoring.
Sidekiq processes federation, email delivery and scheduled jobs. Queue depth is the metric to watch - relay spikes or under-resourcing can cause it to back up quickly, and a backed-up Sidekiq queue means delayed federation and unhappy users.
Nginx sits in front of everything as the reverse proxy, handling TLS termination and serving static assets. Proper cache configuration here can meaningfully reduce load on the rest of the stack.
Email, Object Storage and TLS
Email is required for account verification and notifications. Use a dedicated SMTP provider such as Mailgun or Postmark rather than trying to run your own mail server - deliverability is difficult to manage, and the maintenance overhead is not worth it.
For media files, use S3-compatible object storage rather than local disk. AWS S3, Backblaze B2 and Wasabi are all viable, each with different pricing structures. The important thing is to make this decision before launch. Migrating media storage after the fact is doable but unpleasant.
TLS should be handled via Let’s Encrypt using Certbot. Automate the renewal process - a lapsed certificate will take your instance offline with no warning.
Once You Are Live
Federation
Federation starts happening as soon as your users follow accounts on other servers. Relays can increase content visibility for your community, but they also raise the volume of incoming content that needs moderation review. Think through your federation policies early: which instances you will block, which you will limit, and how you will handle reports from remote admins.
Moderation
Write clear server rules and make them visible during signup. Vague rules are genuinely harder to enforce - both for you and for users trying to understand what is acceptable. Decide on a registration policy (open, approval-based or invite-only) before you open the doors, and define how you will handle reports. These decisions are easier to make in advance than under pressure.
Customisation
A well-written about page and clear community guidelines do more than look professional - they attract users who are actually a good fit for your instance. Vague pages tend to draw vague interest. Custom branding, a defined community mission, custom emojis, and a system for notifying users about maintenance windows all contribute to a more credible and usable instance.
Keeping Things Running
Self-hosting is a long-term commitment. Mastodon releases updates regularly, and some security patches arrive with short notice. Staying current matters both for security and for federation reputation - instances running significantly outdated software can find themselves defederated by others.
Automate daily database backups and make sure your media storage has redundancy. Critically, test your restores. A backup you have never tested is not a backup you can rely on.
Monitor CPU, RAM, disk space, bandwidth, Sidekiq queue depth and error logs. Set alert thresholds so you find out about problems before your users do.
Moderation is often the most time-consuming part of running an instance, and it does not scale down to zero just because your user count is small. Review reports consistently and adjust your federation policies as your understanding of the network develops.
Keep an eye on your hosting and storage costs. Media storage in particular has a way of growing quietly in the background. Billing alerts are cheap insurance.
For deeper operational detail, visit our developer notes.
Common Mistakes
Underestimating media growth catches a lot of operators off guard. Object storage needs to be in your plan from the start, not retrofitted after you have already run out of local disk.
Skipping backups is the other classic error. A server failure or corrupted database without a working backup means losing your community’s data and potentially the community itself. There is no recovering from that gracefully.
Running outdated software creates security vulnerabilities and can lead to defederation. Other instance admins do check, and instances with a reputation for neglect get cut off.
Ignoring moderation - even on a small instance - tends to accelerate defederation faster than most operators expect. Clear rules and consistent enforcement are what keep your instance in good standing with the wider network.
Finally, resist the urge to over-provision at the start. Begin with a smaller server and scale up as you need to. Upgrading is straightforward; recovering money spent on unused capacity is not.
Frequently Asked Questions
What does it actually cost to run a Mastodon instance?
A single-user setup on a basic VPS runs to roughly £10-15 per month. A multi-user instance with active federation costs more, primarily because of increased compute demand and storage growth. Managed hosting options start at around £6-8 per month for smaller setups, which can be cost-competitive once you factor in the time you would otherwise spend on operations.
Is a Raspberry Pi a reasonable option for hosting?
Technically possible for a single-user instance, but not really recommended. Federation can generate resource spikes that a Pi handles poorly, and the reliability trade-offs compared to even a low-end VPS are significant. A cheap VPS is a more sensible starting point.
How do I move my instance to a different server?
Mastodon provides tools for migrating user accounts and instance data. The process requires careful planning, particularly around database and media migration. Test everything thoroughly in a staging environment before touching a live instance.
What happens if my instance goes offline?
For short outages, federation is generally forgiving - other instances will retry delivery. Longer downtime may cause some servers to pause delivery attempts, but things typically resume after recovery. Persistent or repeated outages are a different matter: they damage your instance’s federation reputation over time.
Do I need to think about moderation if it is just me on the instance?
You still need to keep software updated and respond to abuse reports from other instance admins. Solo operator or not, you are the responsible party for your instance. See our tools page for admin resources that make this easier.
Can I open my single-user instance to other people later?
Yes - registration settings can be changed at any time. Going from one to ten users is manageable with some preparation. Moving beyond that requires more deliberate infrastructure and moderation planning. Our articles hub has guidance on managing growing communities.