Why I’ve automated deployments

Free Radical is running on a Digital Ocean VPS. Instead of deploying it manually, I turned the process into a couple of Ansible playbooks1 that do the right things quickly and repeatably.

I describe what it does in the README, but that’s just a feature checklist. So why would I go through the effort? There are several reasons:

I’m no longer tied to that server. If I screw it up badly or if a hacker compromises it, I can rebuild it from scratch on a brand new VPS in about five minutes.

Similarly, I could switch to a different cloud host with minimal tweaking. There’s a sale at AWS? I’m on it!

I don’t have to remember how to do this. I am not smart and I am getting less smart by the day. In a few months I’ll have no recollection of how I installed and configured this service. Now I won’t have to worry about missing a critical step.

You can benefit from my work. You personally. If you want to deploy your own Mastodon server, you have a detailed blueprint of exactly what’s required.

I can benefit from you benefitting from my work. If you find better settings or an easier method, you can tell me so that I can use your improvements (and everyone else can too!).

Finally, it makes some abstract “maybe some day” considerations very concrete. A Mastodon user tooted that it might be possible for someone to flood the network with hundreds of new instances in a very short amount of time, and that we should plan for that becoming possible. I pointed out that it already is: I could spawn instance[0.99].freeradical.zone and run a hundred parallel copies of those playbooks to add a hundred instances to the Mastodon network. Dealing with this isn’t something we can defer until a “some day” that never comes, but something we have to consider right now. There’s nothing like a working proof of concept to motivate planning.