While I definitely appreciate that this exists now (as another person who considered matrix and ended up passing due to deployment complexity) this is not what I think most folks would reasonably call a "trivial" docker compose setup.

It's a 16 service compose setup, complete with init hacks, inline docker-file builds to use those init hacks, a whole bunch of required config templates, some services that aren't clear if they're examples or requirements (ex - why is mailhog in there? just give me the SMTP env vars), and just a lot of general complexity still.

This feels like several discrete services that don't play nicely, herded together like cats. It doesn't feel like a solid and planned set of tools.

---

From my end - it's not enough to just stand it up. If this is my primary messaging tool and I'm hosting it, I need to have a feel for how it might break, and how I can fix it when it does.

Hell, I'm not even allergic to k8s (I host dozens of services on a baremetal cluster), but I am allergic to helm for very similar concerns: Complexity at the self-hosting scale (individual to small business) is rarely worth the additional overhead, and helm rapidly makes what should be simple yaml file deployments a complex, abstracted process. Your docker compose has a similar feel.

My first rule of thumb is "How long will it take me to manually read and understand a compose file while converting it to a k8s deployment?" This one looks onerous, not trivial.