[snorremd]

When me and a bunch of friends and acquaintances switched away from Slack a little under a year ago (I think) we looked into Matrix. One of the primary requirements was that even our non-technical friends should be able to use it.

At the time Matrix/Element had recently launched their Matrix 2.0 efforts and I tried setting up the whole stack without resorting to their all in one shell-script meant for non-production use. I did not mind hosting four different servers (Synapse, Matrix Auth Service (MAS), Call, etc), but did find the integration and config job a bit tedious. The main blocker though was the lack of an invite-system in the new Matrix Auth Server. Also the fact that the Element X app uses a new Livekit based call server while other clients/apps use a different approach is also something not great.

We ended up going for Mattermost. One service easily hosted with Docker. One app, and easy invites. While I think federation would be cool, right now Mattermost was a bit simpler to get up and running.

Element seems more focused on enterprise and government contracts than self-hosters. I think this is fine, they need to pay their bills. But Matrix 2.0 for self-hosters might need a better story right now.

[Arathorn]

When we first announced Matrix 2.0 implementations in Sept 2024 we made a major error by not providing an easy distro, so I feel your pain.

We fast-followed with https://github.com/element-hq/ess-helm as a really easy distribution (albeit using helm charts) based on the paid offering we provide for folks for NATO and the UN and folks. It really is trivial to install now - e.g. here's a live-install from FOSDEM last weekend: https://youtu.be/EngsGD30Ow0?t=929

Meanwhile if you're allergic to k8s I went and published a trivial docker-compose at https://github.com/element-hq/element-docker-demo/ too.

[horsawlarway]

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.