How to Self-Host Mastodon on an Ubuntu VPS

Work out the hardware for this from your user count and you will get it wrong, because the inbound workload is generated by whoever those users follow on other servers. That one property drives the CPU, the storage curve and the reason instances run out of disk. This covers it, the settings that cannot be changed afterwards, and the commitment that is not technical at all.

Mastodon is the most demanding application in the self-hosting canon, and not because of traffic. A single-user instance that federates with the wider network processes activity from every account anyone on it follows, so the workload is set by who you follow rather than by how many people use your server.

Federation Decides the Sizing

This is the fact that makes Mastodon different from every other app in this series, and understanding it prevents the most common disappointment.

When someone on your instance follows an account elsewhere, that remote server delivers every subsequent post to yours. Your Sidekiq workers process each delivery, store the post, fetch attached media, and cache the author's avatar. A single user following two thousand accounts across a thousand servers generates a continuous inbound stream that has nothing to do with anybody reading it.

Two consequences. Media storage grows without bound, because you are caching other servers' images indefinitely unless told otherwise. And CPU is consumed by queue processing rather than by serving pages, so a quiet-looking instance can be busy.

Those use MassiveGRID's per-resource rates of $2.87 per CPU core, $0.80 per GB of RAM and $0.01 per GB of SSD per month, less 20% on annual billing. Treat the storage figures as a starting point that grows, and read the media retention section below before believing any of them.

The Services You Are Running

Five components, and knowing which is which makes every later problem tractable.

Puma serves web requests. Sidekiq processes background jobs across several queues, and this is where federation happens. The streaming server is a Node process pushing live timeline updates. PostgreSQL holds everything structural. Redis backs the queues and the cache.

Sidekiq's queues have distinct jobs and distinct urgency: default for local actions, push and pull for outbound and inbound federation, ingress for incoming activity, mailers, and scheduler for periodic work. When something is wrong, queue depth per queue is the diagnostic, and a backed-up ingress queue is the usual answer to "why is my timeline hours behind".

sudo -u mastodon RAILS_ENV=production ./bin/tootctl feeds build
sudo -u mastodon RAILS_ENV=production ./bin/tootctl self-destruct --help
redis-cli llen queue:ingress

The Two Settings That Must Be Right First

LOCAL_DOMAIN is baked into every identity your server creates and it cannot be changed afterwards. Accounts, posts and federation relationships all reference it. Changing it breaks every remote server's knowledge of your users, permanently. Decide the domain before the first user is created, and if you want handles at @you@example.com while the server runs at social.example.com, set WEB_DOMAIN separately and serve the WebFinger redirect from the apex.

SECRET_KEY_BASE, OTP_SECRET and the Web Push and ActiveRecord encryption keys. Lose these and you have a database you cannot read. They are generated during setup, they go in .env.production, and that file must be in your backups as a credential rather than as one more config file.

Email is not optional either. Confirmations and password resets are the only route into an account, so an instance with a broken relay is one you will eventually be locked out of. Use an authenticated relay with SPF, DKIM and DMARC on the sending domain.

Media Storage Is the Real Cost

Left alone, a federating instance accumulates cached remote media forever. This is the single most common reason a Mastodon server runs out of disk.

# in .env.production
MEDIA_CACHE_RETENTION_PERIOD=14
CONTENT_RETENTION_PERIOD=90

# and on a schedule
sudo -u mastodon RAILS_ENV=production ./bin/tootctl media remove --days=14
sudo -u mastodon RAILS_ENV=production ./bin/tootctl preview_cards remove --days=30
sudo -u mastodon RAILS_ENV=production ./bin/tootctl media remove-orphans

Set the retention period on day one, not when the disk fills. Remote media is a cache: deleting it costs nothing except a re-fetch if someone scrolls far enough back, and it is the difference between 200 GB and 2 TB over a couple of years.

For anything beyond a personal instance, move media to S3-compatible object storage and keep the server's disk for the database. That decouples the growth curve from the instance size, though note that egress on the object storage becomes a real line item once the instance is popular. Our guide to object storage economics covers the charges that are easy to miss.

The Database Needs Attention

Mastodon writes constantly, and Postgres defaults are conservative. Two things matter more than the rest.

Tune shared_buffers, effective_cache_size and work_mem to the machine rather than leaving the packaged defaults, which assume a much smaller server. And keep autovacuum working: the statuses table churns heavily, and an instance where autovacuum falls behind degrades in a way that looks like a Mastodon problem and is a Postgres one.

Back up the database and the media store together, plus .env.production. Our guide to database backup strategy covers doing the Postgres half properly, including point-in-time recovery, which for a social instance is the difference between losing a day and losing a minute.

Moderation Is the Work Nobody Budgets

Running an instance with open registration means becoming responsible for what strangers post from your domain, which is a commitment of a different kind from operating a server.

Three honest options. Keep it single-user or invite-only, which is what most people should do and removes the problem entirely. Run open registration with a moderation team and a published policy, which is a real ongoing role. Or approval-required registration, which is the middle path and still means reading applications.

Whichever you pick, decide before opening rather than after. Also know that a poorly moderated instance gets defederated by others, at which point your users are talking to a shrinking portion of the network and the technical work was wasted.

Upgrades Need Reading

Mastodon releases carry migration steps that are occasionally mandatory and order-dependent, including database migrations that must run before or after a restart depending on the release.

Read each release's notes, do not skip versions, and rehearse on a restored copy before touching an instance people use. Our guide to upgrading self-hosted applications covers the general pattern; Mastodon is one of the applications where the pre-deploy and post-deploy migration distinction genuinely matters.

Infrastructure for an Instance That Federates

An instance that goes offline stops receiving federated activity, and remote servers retry for a while and then give up, so extended downtime means gaps in your users' timelines that never fill.

MassiveGRID runs Proxmox high-availability clustering with automatic failover over Ceph storage replicating every block three times across independent NVMe drives, behind a 100% uptime SLA, so a host failure is a restart rather than a hole in the timeline. A Linux VPS at the per-resource rates above suits most instances, and HA cloud storage covers the media store once it outgrows the server's disk. For the retention and backup work, backup services use block-level incremental backups with AES-256 encryption at $0.01 per GB.

Instances can be ordered across a partner footprint of more than 700 datacenters in 85 metros, 30 countries and six continents, with auto-provisioning in New York, London, Frankfurt and Singapore, so a community can sit in the jurisdiction it belongs to.