Hey I’ve been running my own mastodon instance for a few months now so why not write up a little retrospective. For context my background is: I signed up for mastodon on sunbeam city after the tumblr purge but decided that self hosting might be fun (it is!)
mastodon is ram hungry
Now to be fair all of the other services I run are dormant most of the time and really only for me. Buuut in particular precompiling assets after making a change to the client side of things takes up /a lot/. So originally I was running it on a $5/mo nanode (sponsor me linode) but had to bump it up to a 2GB ram system and even then I’m sitting at mostly full utilization constantly.
media files ... are big
So the second bugaboo is that .... files big. If you’re running it all on one server expect remote media files to grow constantly. A rough estimate shows that on my 5 person server after about a week it cleared 7GB, but it will depend very much based on what files your users are requesting to see and how active the servers you federate with are. It quickly became clear to me that the immediate solution was to switch to S3 style storage (wasabi was just recommended to me). Although a cronjob running
tootctl media remove is a good idea as well.
just set up a local dev environment
It’s a pain to get it started but once you’ve got it you can precompile assets locally and deploy them to production no problem. You can make changes and test it without bothering your users. I know how tempting it is to do it live but just .... don’t.
git is good
Git is your friend. I’ve got my site set up as a fork so that I have the freedom to make any changes I wish, but if you don’t set it up right beforehand then it will be a pain of merge conflicts when you try to update. I’m still working on this actually so I’ll have to write it up in a follow up but basically there are a few approaches to consider. You can set production up as a remote so that updating is as simple as pushing it. You should consider setting up git hooks to automate precompiling the assets and deploying them as well.
set up your about page
I went ahead and set up a code of conduct early on to prevent any future “that’s not fair I didn’t agree to that” arguments. A good starting point is the community covenant. It’s got the basics laid out in a template you are free to use. Be sure to actually read and understand the promises you’re making to your users and try your best to deliver on them.
It’s also a good time to consider how your community will be governed. Setting up a wiki or using your issue tracker for proposals are both good options!
why did my engagement drop :(
The actual sending and receiving of toots happens via sidekiq jobs try fiddling with the number of workers
plans for the future
I’ve got a lot in the works, but nothing certain as yet. I’m considering the merits of various mastodon forks (Florence, glitch-soc, etc).