Self-hosting a Mastodon server, thus far: the good, the bad, the ugly.

The good:

  • Migrating from another server is very straightforward. Pieces of your account can be exported as CSV and consumed by another Mastodon server.

  • Hackable server. I’m running a variant that adds some features (I’ve also bumped my character limit, because that’s a function of the server features and not the protocol). Although it’s Ruby on Rails with JavaScript as the UI layer, it’s not deeply, deeply difficult to hack around on.

The bad:

  • Setup is a chore. You can use Docker, but at the end of the day it’s far from what most people without server admin experience would consider “turnkey.” You’ll still have to do the part where you push a bunch of nginx rules up and set up some security certificates by hand. In my case, I’m behind Cloudflare and that adds a bit of additional complexity because it’s off the getting-started script (though other people have blazed this trail and helpfully put together guides for it).

The ugly:

  • Stuff I think of as “par-for-the-course open-source usability sharp edges” are there. Little things that won’t stop you from using it but indicate that nobody’s paid to do the UX, like the fact that in the import UI and the export UI, the order of the “block list” and “mute list” options are flipped, increasing the odds that if you’re ripping down CSV files by hand and then slamming them into the other UI, you’ll swap the two. Fixable? Probably easily. But with all these eyes on the product nobody empowered to fix it has noticed or cared.

… all in all though, this is way low on the list of most painful open source projects I’ve ever tried to set up an install of, and I’m very, very impressed.

Sign in to participate in the conversation
Qoto Mastodon

QOTO: Question Others to Teach Ourselves
An inclusive, Academic Freedom, instance
All cultures welcome.
Hate speech and harassment strictly forbidden.