Mastodon

Last reviewed Aug 26, 2026 · 921 words

A single-user Mastodon instance needs 2 GB of RAM, a PostgreSQL database, Redis, three separate Ruby and Node processes, working outbound email, and a domain name you will never be allowed to change. Everything else about running it is ordinary sysadmin work. Those six items are the whole "Hard" difficulty rating, and the last one is the only decision you cannot undo, so settle it before you touch a compose file.

The domain is permanent, so pick it like a tattoo

Every account on your server is identified across the fediverse as @[email protected]. Other servers cache that identifier, followers point at it, and every post you have ever federated carries it. Mastodon has no supported way to rename a server once it has federated with anyone; the closest thing is account migration, which moves your followers to a new account and leaves your post history behind. So LOCAL_DOMAIN is written once. A subdomain like social.example.com is fine, and if you want handles at the bare apex (@[email protected]) while the software lives on a subdomain, WEB_DOMAIN plus a WebFinger redirect from the apex handles that. Decide it on day one either way.

Four processes, two datastores, one mail server

The upstream compose file runs the web app (Puma, port 3000), the streaming server (Node, port 4000), Sidekiq for background jobs, plus PostgreSQL and Redis. Sidekiq is the piece newcomers underprovision: every federated post you receive, every image you upload, every notification and every timeline fan-out is a Sidekiq job, and on a busy day a single worker at default concurrency falls behind and your home timeline lags by minutes. Give it two worker containers on anything with more than a handful of users, and match DB_POOL to the concurrency or PostgreSQL will start refusing connections.

Generate secrets with the setup wizard rather than by hand:

docker compose run --rm web bundle exec rake mastodon:setup

It writes SECRET_KEY_BASE, OTP_SECRET, the VAPID key pair for push notifications and, in recent versions, the Active Record encryption keys. Losing any of those after users exist means broken logins, broken push and unreadable encrypted columns, so .env.production belongs in your backups next to the database dump.

Outbound SMTP is not optional. Sign-ups, password resets and the confirmation email all go through it, and an instance with no mail will happily let you register and then never let you in. A transactional provider's free tier covers a small server.

The media cache fills the disk before anything else does

Your own uploads are small. What grows is the cache of every image and video attached to every post your server has ever seen from the rest of the network. A single-user instance following a few hundred active accounts can accumulate tens of gigabytes within months. Two fixes, and I would do both. Put media on S3-compatible object storage (S3_ENABLED=true, which works with MinIO on the same box or any cloud bucket) so the disk holding PostgreSQL never fills. Then run the retention commands from cron:

docker compose run --rm web bin/tootctl media remove --days 7
docker compose run --rm web bin/tootctl preview_cards remove --days 14

Seven days of remote media is plenty; anything older is refetched on demand if someone scrolls back to it.

A one-person server starts empty, and that is the real cost

Mastodon shows you posts from accounts you follow and from accounts your users collectively follow. On a fresh single-user instance the federated timeline is blank, hashtag searches return nothing, and following someone shows only their posts from that moment on. The network fills in as you follow people, and a relay can pump in a firehose of public posts if you want one, but the first two weeks feel lonely compared with joining an existing 50,000-user instance. If your motive is owning your identity rather than running a community, that emptiness is the price and it fades. If you expected discovery on day one, it will disappoint.

Full-text search of posts additionally needs Elasticsearch, which is another 1 GB of RAM on its own. Most small instances skip it.

When GoToSocial is the better answer

For one to five people who want a fediverse presence and nothing else, GoToSocial speaks the same ActivityPub, works with most Mastodon mobile apps, and runs in about 100 MB with SQLite. It has no web timeline of its own and fewer moderation tools, which is exactly why it is lighter. Mastodon earns its 2 GB when you host other people: the report queue, domain blocks, custom roles, admin announcements and per-user limits are the parts that matter the moment a stranger registers. The social category lists the fediverse servers that sit in between.

What I'd do

Decide the domain, then run the upstream compose file with PostgreSQL and Redis on a 4 GB VPS (about $12 a month at last check), media on object storage from the first boot, the two tootctl retention commands in cron, and a nightly pg_dump plus .env.production shipped off the box. Two Sidekiq containers if anyone besides you signs up. Put Caddy in front for TLS and websocket pass-through to port 4000. The official docs cover the remaining knobs well. And if it is only ever going to be you, run GoToSocial instead and spend the saved RAM on something more fun.