How to run a Mastodon instance: rent a Linux server, point a domain at it, install Mastodon with PostgreSQL, Redis and nginx, then keep up with backups, security updates and moderation. The software is free; the ongoing admin work is the real cost.
Running a server is one route into the wider self-hosted community world, and it suits groups that want their own rules and their own data.
What running a Mastodon server involves
An instance is a full copy of the Mastodon application that hosts its own accounts and talks to other servers in the fediverse. The administrator owns everything that follows from that: the database, the uploaded media, the legal exposure, and the moderation of both local users and remote content. Unlike a bulletin board, which usually lives in one closed space, a Mastodon server constantly exchanges posts with strangers’ servers, so the workload and the risks reach beyond the members.
Before installing anything, decide who the server is for, how many people will join, and whether sign-ups will be open, approval-based or invite-only. A small server for friends or a club is a very different commitment from a public one, and moderation burden grows with open registration.
Prerequisites and preparing the machine
The official installation guide lists three requirements. According to the Mastodon installation guide, the install needs a machine running Ubuntu 24.04 or Debian 13 that you have root access to, a domain name or subdomain for the server, and an email delivery service or other SMTP server so the instance can send confirmation and notification mail. Check the current guide before starting, because supported operating system versions change between releases.
Hardening comes before installation. The Mastodon preparation guide, written around Ubuntu 22.04, recommends disabling password-based SSH login so that only keys work, updating system packages, and installing fail2ban so repeated login attempts are blocked. It warns to confirm key login works first, or the change will lock the administrator out.
- Server: a virtual machine with root access and a supported Linux release.
- Domain: a domain or subdomain, chosen carefully, since it forms part of every account’s address and is hard to change later.
- Email: an SMTP provider for sign-up confirmations and notifications.
- Storage plan: local disk to start, or an external object store for media.
How to run a Mastodon instance: installation steps
The documented installation from source runs as root for the system steps and as a dedicated mastodon user for the application. The table summarises the order.
| Stage | What happens |
|---|---|
| System repositories and packages | Install curl, wget, gnupg, lsb-release and ca-certificates, then the required packages |
| Dedicated user | Create the mastodon user that will own the application |
| PostgreSQL | Create a database user with “ident” authentication, so no separate password is needed |
| Setup wizard | Run mastodon:setup to write the configuration, precompile assets and create the schema |
| TLS certificate | Obtain a free Let’s Encrypt certificate with certbot |
| nginx and systemd | Configure the web server and enable the Mastodon services |
The stages above follow the official Mastodon installation guide.
The interactive wizard is run with RAILS_ENV=production bin/rails mastodon:setup. Per the guide, it creates a configuration file, runs asset precompilation and creates the database schema, and the configuration is saved as .env.production. That file holds the application secrets, which matters again for backups. The guide obtains the certificate with certbot and then copies the supplied systemd service templates into place before enabling them.
Once the services are running, create the first account, promote it to owner through the command line tool, and test federation by following an account on a large server and posting a reply.
Backups: what to protect first
The Mastodon backup guide ranks what needs saving in order of importance: the PostgreSQL database, the application secrets from the .env.production file, user-uploaded files, and finally the Redis database.
- PostgreSQL: losing it results in complete failure of the server, including all accounts, posts and followers.
- Secrets: if lost, users are logged out, two-factor authentication becomes unavailable and Web Push subscriptions stop working.
- Uploads: losing them means losing avatars, headers and media attachments, though Mastodon keeps working.
- Redis: loss is almost harmless; the only irrecoverable data is the contents of the Sidekiq queues and scheduled retries of failed jobs.
The guide recommends occasional dumps with pg_dump or pg_dumpall, and says the best backups are off-site, stored away from the Mastodon machine itself. If media sits on an external object store such as Amazon S3, Google Cloud or Wasabi, those files do not need separate backing up. Test a restore at least once; an untested backup is only a hope.
Updates and security patches
Per the upgrade documentation, Mastodon versioning follows the spirit of SemVer. Major versions, such as 4.x to 5.x, may make breaking changes or alter system requirements, while minor versions, such as 4.1.x to 4.2.x, add functionality in backwards compatible ways. The documentation says Mastodon occasionally releases critical security updates that must be applied in a timely fashion, so an unattended server is a liability.
Releases correspond to git tags. The upgrade procedure is to read the release notes on GitHub, switch to the mastodon user, fetch tags, check out the chosen tag and run the upgrade instructions included in that version’s notes. The guide notes that running unreleased code from the main branch, while possible, is not recommended, and that it is safe to skip individual patch-level releases when upgrading from an old version. Take a database backup before each upgrade.
Moderation and ongoing care
Federation means content from other servers reaches the local timeline, so rules and tools need to exist before the first public sign-up. The community moderation guidelines cover the policy side; Mastodon supplies the mechanics.
The moderation documentation splits actions into those for individual users and those for entire websites. For users, the options are sensitive, freeze, limit and suspend:
- Sensitive: all media the account posts is automatically marked as sensitive.
- Limit: formerly called silencing; a limited account is hidden from all other users on that instance except its followers.
- Suspend: the account is effectively deleted, and data is removed after a 30-day window unless an admin force-deletes it sooner.
For other servers, the same documentation lists reject media, limit, suspend and a blocklist, along with spam measures such as blocking by email server or IP address. With reject media active, no files from that server are processed locally. Moderators can also approve or reject appeals. Add announcements to tell members about maintenance or rule changes, and recruit a second moderator early so the work does not rest on one person.
Frequently asked questions
Is it free to run a Mastodon instance?
The software costs nothing, but the server, domain name and email delivery service do, and so does the administrator’s time for updates, backups and moderation.
Which operating system does the official guide use?
The installation guide specifies Ubuntu 24.04 or Debian 13 with root access. Confirm against the current documentation before building.
What is the most important thing to back up?
The PostgreSQL database. Mastodon’s backup guide ranks it first, followed by the secrets in the .env.production file, uploaded files and Redis.
How often must the server be updated?
There is no fixed schedule, but critical security releases must be applied promptly. Patch-level releases may be skipped when upgrading from an old version.
