This could come in handy:
https://discourse.gitea.io/t/migrate-gitea-db-from-mariadb-to-postgresql/2072/3
By the way, I think we should use only the Postgres master on Andromeda from both machines, and set up a hot standby (and read-only) replica on Centaurus. This way, we can recover all apps that use Postgres very easily, and without using outdated backup downloads, when one of the machines goes down.
To be honest, I'd prefer not to use Docker on normal servers wherever possible. It adds another layer of complexity both for running the thing, but also for preparing it for deployment (can't go straight from source to server).
Gitea deployment only requires a database server and a single executable to build or download, and run. And building it ourselves on the server would automatically solve the problem of creating custom builds for us, when we e.g. want to deploy our own fixes or additions from a different branch.
(Drone CI is a different beast, of course, and Docker Compose seems like the best way to go to me.)
From my first quick try, it looks like Jitsi Meet is requires Prosody as XMPP server. :/
Have to investigate further. The jisti-meet package installs many different packages, which, in combination, make up the system.
I checked again, and Andromeda is actually not too far from RAM limits, and also using considerable CPU resources already. So it would probably make more sense to throw Jitsi on the new Centaurus, which is going to be online soon.
After everyone in the last call agreed about the Hetzner move, I just ordered a used box (from the auction system), which I thought was the best value for what we need. As it's the middle of the night, and also a weekend, in Germany, it'll be ready by tomorrow or Monday.
It's an Intel Core i7 4770 with two 240GB SSDs and 32GB of RAM. This should be way enough to run all of Gitea, Drone CI, and Jitsi Meet.
I think it would also be cool to use this to add a second ejabberd node, as that should be pretty easy with Erlang (or maybe not, but then we know what it involves). And if someone wants to dive into Postgres replication, it'd be awesome to have a warm standby server, so that in case of the main server going down, we could easily deploy all apps elsewhere and switch to the standby, with zero data loss from backup intervals.
Also good to know: performance of the videobridge seems to be pretty good. When they introduced it last year, they said it would be orders of magnitude better than what they had before.
Oh, and it wants a host entry to the loopback interface. I.e. adding one line to /etc/hosts.
Found the quick install guide and it seems like we really just need to install an apt package and set up an nginx vhost.
I'll give it a try.
Aside from this being useful to be configurable as an attribute per node/role/environment, I think this should not use full debug logs in production.