4 ms·

How do you deal with the complexity of hosting Matrix? I was in the same position, wanted to set one up - decided it was too much work.

by Aloha 4y ago

lannisterstark 4y ago
There's not much complexity really. This handbook takes care of most stuff for you: https://github.com/spantaleev/matrix-docker-ansible-deploy/ https://github.com/spantaleev/matrix-docker-ansible-deploy/ Been hosting it alongside some bridges(like irc) for a while now.
- spantaleev 4y ago
  I'm happy to hear that my Ansible playbook for managing Matrix is helpful to people and is being appreciated! Shameless plug - for people who'd rather not maintain their own server manually with Ansible, a few others and I are running https://etke.cc https://etke.cc - a completely FOSS service service built on top of the Ansible playbook. Hopefully, this provides the best of both worlds - ease of getting started (on your own or on a rented server), everything built on top of FOSS, no vendor-lock-in (you can migrate to using the playbook yourself at any time, etc.).
snerbles 4y ago
I use AVENTER-UG's docker-matrix container for Synapse, and a separate VM for PostgreSQL. Element-web I currently upgrade straight from the tarballs. Upgrades are fairly seamless, and it's been well behaved for the past 24 months or so - the teams behind the Matrix ecosystem have been phenomenal. But you want sysadmin pain points, here are some random pointers in no particular order: - Familiarity with reverse proxies helps a lot. I recommend terminating both client (443) and federation (8448) traffic through nginx or similar. - The Synapse Github (https://github.com/matrix-org/synapse/issues https://github.com/matrix-org/synapse/issues) is one of the first places I start trawling if something gets weird. - Federation is the second-hardest part, and if something goes wrong and you're not watching the Synapse logs it can fail silently - here it helps to have friends on other instances there to check connectivity (and blame you when THEIR instance breaks federation, that's fun). https://federationtester.matrix.org https://federationtester.matrix.org and similar help a lot too, and it's good to at least have a couple of bots from matrix.org to poke at if you suspect something's amiss. - Fuck everything about troubleshooting STUN/TURN. Newer playbooks may make coturn deployment easier. - It's easy to test migrations/deployments with an update to your hosts file - you can verify that your clients connect to the new server and that data has been restored without doing anything to the original server. EDIT - Keep in mind that a lot of the above went on from 2018-2019 (except the server migration, but that was easy) and the documentation/automation has improved quite a lot since then.

How do you deal with the complexity of hosting Matrix? I was in the same position, wanted to set one up - decided it was too much work.

by Aloha 4y ago

How do you deal with the complexity of hosting Matrix? I was in the same position, wanted to set one up - decided it was too much work.

lannisterstark 4y ago

There's not much complexity really. This handbook takes care of most stuff for you: https://github.com/spantaleev/matrix-docker-ansible-deploy/ https://github.com/spantaleev/matrix-docker-ansible-deploy/ Been hosting it alongside some bridges(like irc) for a while now.

spantaleev 4y ago
I'm happy to hear that my Ansible playbook for managing Matrix is helpful to people and is being appreciated! Shameless plug - for people who'd rather not maintain their own server manually with Ansible, a few others and I are running https://etke.cc https://etke.cc - a completely FOSS service service built on top of the Ansible playbook. Hopefully, this provides the best of both worlds - ease of getting started (on your own or on a rented server), everything built on top of FOSS, no vendor-lock-in (you can migrate to using the playbook yourself at any time, etc.).

snerbles 4y ago

I use AVENTER-UG's docker-matrix container for Synapse, and a separate VM for PostgreSQL. Element-web I currently upgrade straight from the tarballs. Upgrades are fairly seamless, and it's been well behaved for the past 24 months or so - the teams behind the Matrix ecosystem have been phenomenal. But you want sysadmin pain points, here are some random pointers in no particular order: - Familiarity with reverse proxies helps a lot. I recommend terminating both client (443) and federation (8448) traffic through nginx or similar. - The Synapse Github (https://github.com/matrix-org/synapse/issues https://github.com/matrix-org/synapse/issues) is one of the first places I start trawling if something gets weird. - Federation is the second-hardest part, and if something goes wrong and you're not watching the Synapse logs it can fail silently - here it helps to have friends on other instances there to check connectivity (and blame you when THEIR instance breaks federation, that's fun). https://federationtester.matrix.org https://federationtester.matrix.org and similar help a lot too, and it's good to at least have a couple of bots from matrix.org to poke at if you suspect something's amiss. - Fuck everything about troubleshooting STUN/TURN. Newer playbooks may make coturn deployment easier. - It's easy to test migrations/deployments with an update to your hosts file - you can verify that your clients connect to the new server and that data has been restored without doing anything to the original server. EDIT - Keep in mind that a lot of the above went on from 2018-2019 (except the server migration, but that was easy) and the documentation/automation has improved quite a lot since then.