A Single-Person Mastodon Server: What Breaks and What Works

Mastodon is a decentralized network of independently operated servers running open-source software. Accounts on different instances can follow one another, but the architecture has consequences that become obvious when you run a server with only one user. I’ve spent several months on my own instance and want to share what I’ve learned about the practical trade-offs.

Deciding to Self-Host (a Little)

Choosing an instance involves weighing server stability, moderation policies, reputation with other servers, and community vibe. Running my own instance looked simplest: I control the domain name in my identity and sidestep disagreements about moderation. I did not want to operate infrastructure, so I pay masto.host about $19/month for managed hosting; their cheapest plan starts at $6/month.

One thing worth noting: if you want your handle to use your own domain (for instance, @[email protected]), you basically have to run your own server. You can redirect an existing domain to another instance, but your posts still originate from the hosted address. Some other ActivityPub software like Takahē handles personal domains as a first-class feature, but Mastodon doesn't.

On my setup, I followed these directions to present my username as [email protected] while the server actually lives at social.jvns.ca. I imported a short block list and otherwise ignore administration.

The Cost of a Tiny Server

Mastodon servers only store posts they were explicitly sent: someone on the instance follows the author, or a post mentions a user on the instance. A single-person server therefore receives a very narrow slice of the network. This creates visibility problems that affect any small instance, not just one-person setups:

  • Visiting a profile you don't follow fetches the avatar, bio, and pinned posts but not post history, so the account can look empty.
  • Reply threads are incomplete. You only see replies that reached your server. Additionally, because different participants are on different servers, it is possible that no single user—including the original poster—can see every reply.
  • Favourite and boost counts are underestimated, often showing only 1–2 even for popular posts, because counts only reflect interactions from people you follow.

Poor reply visibility makes conversations redundant: people reply with the same point because they cannot see each other's responses. As a workaround, you can open a post directly on the author's instance to read the full thread.

These are known, long-standing issues. Mastodon developers acknowledge improvement plans, but GitHub issues about backfilling statuses and fetching full threads have been open for years, suggesting meaningful technical hurdles.

Discovery suffers too. Without a local timeline full of humans, there's no casual feed of what your server's community is posting. Relays like FediBuzz populate a federated timeline with activity from other instances, and some Android clients can follow remote instances, but it's not the same as being on a busy server.

Workarounds

Tools exist to patch the fetching gaps. Fedifetcher and combine.social are designed to fetch remote profiles and replies into your instance. Some clients handle this better: Mammoth on iOS fetches remote replies automatically, while Mona has a manual "load from remote server" option.

Migration Notes

Account migration between Mastodon servers works, but with caveats:

  • Your posts do not move. They stay on the old instance.
  • Your follow, mute, and block lists do not move either, though you can export and re-import them. Private accounts you follow must re-approve you.
  • Followers do follow you to the new account, but imperfectly.

In my case, most followers moved within 24 hours. A handful of servers missed the migration message entirely, leaving about 2,000 followers stuck; re-running the migration after 30 days fixed most of that. A small number of followers on non-Mastodon ActivityPub software never migrated.

The API, DMs, and Moderation

The Mastodon API is far more approachable than Twitter's was. Client software can run entirely in the browser with JavaScript; the API docs cover this. I wrote a small threaded-reply viewer for my own use and appreciated not needing a backend. OAuth scope-to-endpoint mapping is best documented in a longstanding GitHub issue.

Direct messages are implemented as posts with visibility limited to named recipients. Consequences:

  • Mentioning an unintended address in a "DM" can leak the message to them.
  • Admins of the sending and receiving servers can read message contents from databases—DMs are not end-to-end private.
  • You cannot opt out of receiving DMs outright; muting notifications just routes incoming messages into a black hole.

Moderation at the server level has two distinct modes. Defederation, which docs call suspension, prevents users of one server from following users of the other. Limiting, also called silence, means content from a user or server is visible only to its followers and not discoverable via boosts. Beyond that, instances sometimes keep their moderation decisions secret, so it's not always obvious why you can't see content.

Search limitations

There is no general search across posts from other users. The optional Elasticsearch feature only searches your own posts, mentions, favourites, and bookmarks. This is a deliberate privacy decision that frequently causes debate; Tim Bray's summary has details.

Beyond Mastodon Servers

ActivityPub unites Mastodon with other software—Calckey, Akkoma, GoToSocial, Takahē, writefreely, and Pixelfed are examples. Servers speak ActivityPub to each other; clients talk to their own server via the Mastodon API. Some projects like GoToSocial specifically aim to be Mastodon-API compatible so existing clients work.

Running a single-user instance was the right call for me because owning my domain matters for my professional use of social media. Even so, I would recommend starting on an established instance before going solo—the learning curve is gentler with a real local timeline. Despite rough edges, the technical control and better conversations make it worthwhile.