The Big Mastodon Migration


Elon Musk bought Twitter and fucked it up and caused a bunch of people to leave. My Twitter timeline is now just porn and Malaysians, and you can only jerk off so many times in a day. So I decided to take a look at my mastodon instance again.

I actually deployed it sometime early 2020 when the pandemic hit, but hadn’t really spent much time on it at all. Only my friend rewarp was using it and he seems to enjoy it. The software was outdated though and so was the OS, and the Linode Nanode it was running on. So I decided that it’s time to upgrade everything.

The first thing I tried was to update the OS. I had run installed Ubuntu Focal and the latest version was Jammy. It failed. So I decided to go bigger.

To stave off future storage issues – I had had to deal with mastodon’s aggressive media caching strategy before. It’s a whole thing. I think it’s dumb. I decided to move media attachments onto S3 storage. Luckily, Linode has one that is $5 monthly for 250GB storage which I think is more than adequate for my needs. I primarily followed this guide to work with Amazon’s S3 which is fine because Linode Object Storage is S3 compatible.

I then updated mastodon to the latest version. This was somewhat scary since mine was two years out of date… but it was surprisingly easy. Had to read up the notes for each release, and add the various quirks to the upgrade commands. But it’s easy enough. We’re up to 4.0.2 now.

I decided to next spin off the database onto a separate machine. I spun up a Nanode and put Debian on it and set it to listen on a VLAN interface. Spun up PGtune and changed default config to this:

max_connections = 200
shared_buffers = 256MB
effective_cache_size = 768MB
maintenance_work_mem = 64MB
checkpoint_completion_target = 0.9
wal_buffers = 7864kB
default_statistics_target = 100
random_page_cost = 1.1
effective_io_concurrency = 200
work_mem = 655kB
min_wal_size = 1GB
max_wal_size = 4GB

Then I followed these procedures to move the database contents to the new machine – which was painless. After setting up the same VLAN, and updating .env.production on the mastodon server to point to the new database, everything worked fine.

The next step was to move the mastodon server itself. I spun up another Linode node, 2GB this time, and also put Debian on it. I just didn’t want to be bothered, you know? I basically installed mastodon again and copied over .env.production and nginx configs from the old machine. I also took this opportunity to install pgbouncer. pgbouncer is also set to 200 max connections, of course.

I decided to look into CDNs next – BECAUSE WHY NOT? I decided on Bunny CDN because it’s cheap OK? It works fine enough. Spun up a pool for the media server. It works fine enough I think because the server is in Germany for reasons and we’re in Malaysia so it does feel like the site loads faster with the CDN.

I also switched to a fork of mastodon after this, treehouse, specifically, because I wanted Markdown posts and quotes.

I experimented a bit with another thing that could possibly break mastodon: switching LOCAL_DOMAIN from to just Setting up the proper redirects and fixing some quirks with CDN took some doing but I think on the whole it works. I don’t see a problem with other Mastodon, and Pleroma and Akkoma instances at least. Misskey instances have some problems but I am not entirely certain it’s not just a Misskey problem, you know? So I’m satisfied with it for the time being.

And I also added another sidekiq process so we have two processes, each with 25 threads, 25 db pool

  • scheduler mailers default pull push ingress
  • default push pull ingress

Seems to be working well so far, we’ll see. We’ll probably only need to revisit this if we invite more people to join.

Screenshot of both servers stats. Top one is the mastodon server. Bottom is the database server

As for costs, it’s now about $25.50 a month which is OK I think for now. I think we have the capacity for a few more users, and a connect to a few more relays.