Gotosocial

One of the goals we have with GoToSocial is to make self-hosting your own fediverse instance really easy. In practice this means a few things: Providing a single static binary for easy deployment and without requiring containers Being very mindful of how much compute and memory we require No dependencies on external databases like Postgres, background job systems like Sidekiq which would require Redis, or an object store for media storage even though we do support using some of these things Though we don’t want to require an external database, we do need a database.

As part of setting up backups for my own GoToSocial instance, I’ve contributed some additions to the GoToSocial CLI and its backup documentation. This will hopefully make setting up backups easier for others too. This post goes through the why of setting up backups for this in the first place and looks at two pending changes to GoToSocial to make backups easier. So why backup your Fediverse instance? Because of the signing keys that are stored in your database.

As I got into the ActivityPub side of the Fediverse I ended up hosting my own instance. Fediverse after all. But I wanted something I could easily operate and run which meant Mastodon was out and most Elixir-based solutions aren’t entirely simple to deploy and manage. Thankfully I stumbled across GoToSocial which is written in Go and has a fabulous community to boot. GoToSocial’s niche is small or single-user instances running on low-powered devices, like single-board computers or old laptops repurposed as home servers.