They give the impression that stringing a bunch of config files together is all you need to become operational. Get a server, follow the HOWTO and you’re good.
If the reader needs that HOWTO, they will probably not be aware of how to set up backup and restore themselves. The server is now a ticking time bomb. And that’s just the basic operational concern.
Or the reader doesn’t need the HOWTO, and the article is just mildly interesting. Great, they use YAML to generate systemd units that run podman, that forwards environment variables to a container.
The only thing needed to backup the Matrix homeserver state is to save the content of the PostgreSQL database. The steps to do that are in the project README. They are written with updates in mind but apply equally.
How is the server a time bomb? We took great care to make sure everything auto-updates regularly so that you are not running software with know issues or vulnerabilities.
I didn’t think it was supposed to be a bulletproof how to set up your server guide, more “here’s how you might use CoreOS”. Which is why I liked it, I’ve not seen many good motivating introductions to CoreOS.
I agree with jaffachchief here, this article is one of those use case examples. Trying to find “reasons” to use CoreOS is challenging, this gives you a happy path to get something working.
Sometimes posts like this are just enough to be able to drop your other app in and see it work.
I’m curious on Fedora CoreOS (currently using a Fedora Server machine as basically a container OS) but haven’t seen many articles around on the subject. So thanks for linking!
In case anyone else is interested in setting up a Matrix server but on more familiar distros, this ansible repository is simply great: https://github.com/spantaleev/matrix-docker-ansible-deploy