I want to preface this by saying that I think Mastodon is really great software from the user side. It’s a very powerful tool and deserves all the credit it gets for it’s UI, it’s filtering features, and it’s very in-depth profile settings.

This article is a stream-of-consciousness diatribe about the difficulties I had trying to run my own instance. It should not be taken as advice or, frankly, even be read by anyone.

Facing the Dragon

I’ve run ActivityPub enabled software before. My first foray into hosting a Federated social network was Misskey. It seemed like a fun, different take on a social media platform - and it was!

Setup was super simple and it was easy to maintain, but I sunset my Instance a few years back simply because translating the documentation from Japanese was taking far too much brainpower (this might be solved now).

I also have run a Pleroma instance before, but we’ll get into that later.

Anyways, this time the intent wasn’t to setup an instance just for myself, so I decided to face the dragon and setup a Mastodon instance. I chose Mastodon because, as I outlined above, it has a great user experience for people who are not used to the Fediverse.

The very first problem I came across was that nowhere in the Documentation does it recommend VPS requirements. I understand it’s easy to horizontally scale if required, but only the broadest estimates are given on how much computational resources each user would require. I had to do this math myself, which is fine, but I’m a notoriously terrible estimator.

Moving on, here’s everything you need to run a Mastodon server.

• An Object Storage Provider (S3)
• An SMTP Provider
• Ruby & Ruby on Rails
• A PostgresQL Instance
• A Redis Instance
• Node & NPM
• A JRE Environment (For Elasticsearch)

Many of these are standard, and not a problem - (almost) every app needs a database, I am my own SMTP host, etc. But it’s a lot of plates to spin.

Digging through the documentation, the only outline of how to setup a Mastodon instance is this page. Notice something? It’s a source-only install guide, and with this many services required, it screams for containerization.

Clearly I’m not the only one to realize this, as both a Dockerfile and a Docker-Compose.yaml file exist in Mastodon’s source repo. I could not find any official documentation of what these Docker files required or expected, so I worked backwards by reading through them.

Problems Arise

Number one, Ruby just consistently failed to build from source on Ubuntu, inside a container or out, seemingly at random. I could not trace this to its root cause. Normally just running the exact same command again caused it to work, so I didn’t investigate too deep.

Number two, it took a number of tries for the Postgres container to accept the default migration script. The default production .env file had the wrong outline for how Mastodon prefered to connect to its DB within Docker, so I had to manually figure that out.

I did, after about six hours, get everything running. The final bit of trouble arrived with NGINX, and Mastodon refusing to accept a non-amazon S3 provider.

I should note that Mastodon is interoperable with any S3 provider on paper, but something was going wrong where each upload was being sent without the publication settings, so files were being uploaded but not visible.

I could almost certainly have solved this but after further troubleshooting I came to a realization that stopped the entire project in its tracks

This system is too large for me to understand it

Mastodon has two API’s - a streaming API and a web API, running on port 3000 and 4000 respectively. It uses Sidekiq as a Job scheduler, Redis as a Key-Value Store, and Postgres as a Database.

I came to the realization that even though I could get it running, I did not have the mental headspace to reliably maintain the instance for myself, let alone other people. I was not confident that I could maintain its security as a side hobby - that it would be a full time job to ensure reliability.

Naturally, these problems would fall away as I became more comfortable with the system. But running a Mastodon server is not a weekend project - it’s a serious undertaking worth serious consideration, and that’s just from a technical debt perspective, not even considering community management.

What I Did Instead

After a full days worth of hacking, I gave up on running a Mastodon instance. I decided to instead run a Pleroma instance, which has considerably less overhead.

Here’s everything Pleroma requires to run:

• An Object Storage Provider
• Elixir
• PostgresQL

That’s four less requirements than a default Mastodon install.

It has no default Docker install, but it’s simple to set one up for yourself. It took me an hour to go from zero to a functioning, running instance.

I trust I can perform maintenance and troubleshoot issues, as I have eyes on every moving part. Piping data to Grafana took twenty minutes (I didn’t try on Mastodon - I see they have an existing data API, but I’d still need to setup monitors on all the other containers).

What did I learn from this? Nothing. Like I said at the top of this article, this is just a rant. It’s not even a real complaint.

Both systems just do things differently, and you have to consider how much overhead you’ll be able to handle for a personal project. Neither is better then the other - they just do different things.