For a while now I’d had a Pleroma relay running in my homelab, and at some point it just stopped. I never got around to bringing it back. Recently I decided to fix that, and the process turned up a couple of things worth writing down.
Starting from the current upstream
The image I was running was a 2022 build of pleroma/relay pinned to version 0.2.2. Upstream has moved on since then — the current release is 0.3.5, which adds a web-based admin interface and a few other things. Rather than resurrect the old image, I rebuilt from the current source in the Forgejo repo and pushed a fresh travnewmatic/relay:latest to Docker Hub. My own fork is here.
The skip_questions stumbling block
This is the part that actually bit me. The 0.3.5 release has a bug: on first start in a container it crashes with
TypeError: cli_setup() missing 1 required positional argument: 'skip_questions'The setup code calls cli_setup.callback() without the argument the callback now requires. It’s a one-line fix — pass skip_questions=True — but it’s the kind of thing that’s easy to miss when you’re just trying to get a container running. I patched it in my fork and rebuilt.
It’s not the first time I’ve hit this pattern: something that works fine in a plain Docker environment (where you can answer the interactive setup prompts by hand) falls over the moment you try to run it unattended in Kubernetes. The relay needs to skip its interactive setup when it’s containerized, and 0.3.5 forgot to wire that up.
Deploying to k3s
Once the image was built, deployment was straightforward: a StatefulSet in my mastodon namespace with a 1Gi PVC for its database and signing key, a read-only ConfigMap mount for the config, and a Service exposing port 8080. The old PVC had some leftover data from the 0.2.2 days, but the new version handles the migration cleanly — it reads the old JSON-LD dump, ignores it, and starts fresh with a SQLite database. No data loss to worry about (the old relay had never actually federated with anything, so there was nothing to lose).
Which relays it’s following
A relay is only as useful as the other relays it’s connected to, so I went through and added a bunch. Here’s the current list:
- relay.infosec.exchange
- relay.mycrowd.ca
- relay.dico.gg
- relay.mastodon.nu
- relay.publicsquare.global
- relay.uggs.io
- relay.c.im
- relay.101010.pl
- relay.fedi.agency
- relay.minecloud.ro
Full disclosure: I have no idea if any of these are reputable or not. I picked them from relaylist.com and a list of relays my Mastodon instance was already using, and checked that they were actually online. If any of them turn out to be a source of spam or otherwise problematic content, let me know and I’ll remove it.
How to follow my relay
If you want to add my relay to your instance, the URL you use depends on what you’re adding it to:
- Mastodon:
https://relay.travnewmatic.com/inbox - Pleroma (or another relay):
https://relay.travnewmatic.com/actor
Mastodon wants the inbox URL, while Pleroma and other relays want the actor URL. Easy to mix up, so I’m writing it down here.
Admin
One nice thing about 0.3.5 is the web admin interface at relay.travnewmatic.com/login — you can manage instances, the whitelist, domain/software bans, and config from the browser instead of exec’ing into the pod and using the CLI. The CLI still works too, so I have both options.
Leave a Reply