Self-host Mastodon on a VPS.
Your own corner of the fediverse, on owned Nordic metal.

Three reasons. (1) Your data is on your server. The big public instances are run by volunteers and good-faith operators, but the data lives where they decide. (2) Your rules. You write the rules-of-the-house and you moderate by them. The big instances inherit moderation decisions you may not agree with. (3) Your domain identity. @you@yourdomain reads as "you, on your own server" rather than "you, customer of public service X." For most users joining a public instance is fine; for users who want long-term identity sovereignty, self-hosting is the path.

Technically yes for a single-user instance with limited federation. Realistically no for anything past 1-5 federated accounts. Mastodon's Sidekiq queue grows non-linearly with the number of remote actors you follow; at 50-100 followed accounts the queue lag on a 4 GB box becomes noticeable. Ravelin ($23.90/mo, 16 GB RAM) is the practical floor. Bulwark for an instance with 50+ users or 1,000+ federated peers.

Two practical paths. (1) Njalla registers the domain in their name and lists you as a customer — the registrar shielding is real. They accept crypto and have no KYC. (2) Any conventional registrar via a non-KYC crypto-to-fiat swap — buy a $15 prepaid card for XMR on a no-KYC service, register at any registrar that accepts cards, use a privacy-respecting email. The Njalla path is cleaner but slightly more expensive; the conventional path is cheaper but has more moving parts.

It is non-trivial but rarely a constraint on a real VPS. Federation pushes every public post to every following remote instance, multiplied by media (images, video). A small single-user instance uses ~5-10 GB/month outbound; a medium-active 50-user instance uses 100-300 GB; a popular 1,000-user instance ranges from 1-5 TB. NordBastion VPS plans have unlimited bandwidth at every tier, so this is not a cost vector.

Default to closed (invite-only). Open registration creates immediate moderation burden — spam accounts, abuse, and the moderation labour that goes with it. Closed registration is the default Mastodon-admin recommendation and matches the way most successful smaller instances operate. You can flip it later as your moderation capacity grows.

Three things to back up: (1) the Postgres database (mastodon_production), (2) the .env.production file (env settings), (3) the media files in public/system/ (user uploads — can be huge, 10s of GB). NordBastion VPS snapshots cover the whole disk in one shot and are the simplest "full instance" backup; for granular DB-only backups, pg_dump on a schedule. Take a backup before every Mastodon version upgrade.

Yes — Mastodon supports account migration both directions. A user can import their followers/following lists from a previous instance, and announce a move to a new instance that propagates redirects to their followers automatically. Posts do not migrate (they remain on the origin instance), but the social graph does. This makes self-hosting lower-risk: if you decide to stop running the instance later, your users can move out without losing their networks.

Cleanest is dual access — clearnet primary plus a Tor hidden service mirror. Set up the hidden service per /guides/tor-hidden-service-on-a-vps/, point both your domain and the .onion at the same nginx, and Mastodon serves both. Note: ActivityPub federation between two Tor-only instances is uncommon and may not interop with every fediverse software; clearnet primary keeps you federated, .onion adds a privacy access path for your users.