Hacker News Reader

Comment by alwayslikethis | Hacker News Reader

If you want to host a homeserver but feel overwhelmed about the amount of services you'll have to host (especially if you want to have bridges to other services), check out matrix-docker-ansible-deploy [1]. It's pretty much a set and forget experience with reproducible deployment, and the documentation walks through any decision you need to make.

1. https://github.com/spantaleev/matrix-docker-ansible-deploy

View on HN

Ironically i just spent all weekend writing a new "quick start" guide for Matrix 2.0 deployments using docker-compose (so you literally just set some env variables, `docker compose up` and that's it; no ansible involved). I just shifted to the debugging phase, but once it's ready, it might be even easier than matrix-docker-ansible-deploy as a super-fast way to get started :)

I'd say the primary benefit of ansible is it makes you document everything. It's easy to simply set and forget with tools like docker compose, but then when you need to change something again, you have to recall what you did originally and fix that.

yup, although i'm hoping that a self-contained docker-compose repo that you don't need to edit will help with that (rather than it being a homespun docker-compose setup, which i agree can rapidly become unmanageable).

ansible just feels a bit slow & cumbersome for simpler setups, so i'm using envsubst for basic templating to see how it feels. It's perhaps telling that something like Rocket.Chat just has `docker-compose up` too: https://docs.rocket.chat/v1/docs/deploy-with-docker-docker-c... and it's annoying that Matrix doesn't have something that simple (especially given Matrix 2.0 has more moving parts serverside: auth + voip server).

Not directly related, but I feel that any references to Ansible being slow should be accompanied by a mention of the amazing Mitogen.

https://mitogen.networkgenomics.com/ansible_detailed.html

Please share the code here

well, yes - just let me finish writing it first ;P

can you give it a codename that's not impossible to remember if you do add such a docker? something that is likely I'll be able to remember it in a couple of months?

repo's currently called element-quick-start (given i'm doing it with my Element hat on to showcase EW+EX+EC as much as the Matrix 2.0 backend)

But it's not yet publicly available anywhere?

https://github.com/element-hq/element-docker-demo in the end

For me the benefit of the ansible playbook is that it installs not only synapse and element web but also a ton of bridges and other services like the chatgpt bot. It handles the configuration of those etc.

yup, totally - and the quick-start thing i'm playing with (just got it working!) is not a replacement for that at all. it's just literally providing a solution for people who want to type `docker compose up` and have something immediately working, but without all the bells and whistles.

Having more deployment options and quick-start guides is always great!

That said, the Ansible playbook provides various benefits that you cannot currently get with any other Matrix deployment method. For one, it seems to be the only deployment method that supports hundreds of Matrix and related services which all tie together nicely.

Getting started quickly and easily is an important part, but is not the end. Most people will sooner or later need "that extra service" (bridge, bot, etc.) and it's always a hassle to get it added to a "quick & dirty" deployment.

Using the Ansible playbook, enabling an extra service is usually one extra line of configuration and you're up & running with a deployment that has been battle-tested and improved by hundreds/ thousands of others. You're not alone debugging a hand-made "Synapse worker configuration" or "Matrix Authentication Service" integration - there are many others iterating on the same exact setup.

Another compelling reason to go with the playbook is maintaining your deployment over time - handling major Postgres version upgrades, backups, uninstalling old/deprecated services (to replace them with newer alternatives), etc.

Yes, Ansible can be slow and clunky (and the YAML format is definitely annoying), but it seems like a reasonable tradeoff that provides plenty of benefits.

Disclaimer: I'm the author of the matrix-docker-ansible-deploy (https://github.com/spantaleev/matrix-docker-ansible-deploy) playbook

Thank you for your work! Once that's done I'd love for Elest.io to add support for that. They already support running a custom Element instance.

Is this being tested on Debian 10, 11 and 12 ?

nginx or caddy or something?

I haven't tried them, but I've seen https://etke.cc/ suggested for dealing with a group who will "host" the server.

at the same time, we are developing MDAD playbook, referenced in https://news.ycombinator.com/item?id=42034100

I'm Aine of etke.cc, and yes, we can ease your pain by managing the server part of the matrix on your behalf, be it on-premises or hosted in the cloud by us.

I love the idea, but I have tried this three times and failed each time.

Sure I was learning docker and ansible at the time, and I did get a little bit of 'tech suggestions' from those in the know.. (enable less things to start)

It seemed to install a lot of things and get close.. it could be because I was trying debian 10 when it was made for debian 9 or whatnot..

I just need to mention that as much as it may be an all easy solution for some, it does not always work and turned out to be a big time waster for me three times (although I'll chalk up learning some docker and ansible as not being time spent that I consider wasted) - it did delay me getting a matrix / element setup running.

I think nginx is doing some things different in latest debian as well that effed up some of the tutorials and chat support.

but it's been some months, maybe it works fine now on latest debian without issues, but my experience has shown it to be very finicky.

would be genuinely interested in if the “oneliner” docker-compose approach at https://github.com/element-hq/element-docker-demo works better for you :)

Alternatively, you can just get your server managed by https://etke.cc - the developers of the MDAD paybook - and not worry about the server part at all

Disclaimer: I'm Aine of etke.cc

If there was a way to deploy there and make a snapshot of it that could be cloned to my own server, change DNS settings (to point the domain to my own server and re-grab the ssl certs) and be good to go.. I'd jump on that.

especially with the addons setups offered, that could be nice.

> If you want to host a homeserver but feel overwhelmed

I feel overwhelmed at the number of options there are in this ansible thing. Now I definitely don't want to try it either way.

I'm sorry to hear that you got overwhelmed and gave up on Matrix! Below, I'll try to explain why it can overwhelming and how one might navigate things better.

While the Ansible playbook's documentation is huge (which can be both good and bad), one does not necessarily need to read through everything to get started.

The playbook's documentation tries to guide you through the required steps to get started and always tries to suggest "skipping ahead" and staying with the recommended defaults. It does mention additional services, but branching off into reading about esoteric additional features from the very beginning is not necessary.

It's better to follow the steps and start with the basics. You can add additional services and tweak the existing ones later on at any time.

That said:

- just like a production-ready email system is complicated to deploy, so is Matrix (even with the Ansible playbook). Some learning and planning is necessary. Important decisions (with regard to domain names, etc.) need to be made upfront

- the playbook's documentation may benefit from a new and dedicated "quick-start guide" which would not even mention most or any of the additional services. This could help people get started quicker, instead of making them give up due to analysis paralysis

As for the latter, there are various articles (blog posts) online where people guide you through using the playbook (they act as a "quick start guide"). A downside to those is that some may be out of date and/or skip through steps which may turn out to be important later.

The playbook's documentation is extensive, because it not only aims to get you running, but to also instill knowledge as to how things work so that you're more capable of managing the deployment later on. It's a bit like the Arch Linux Wiki in this regard - it gives you more to read (and walls of text can be scary), but is also there for you for when you need help.

Disclaimer: I'm the author of the matrix-docker-ansible-deploy (https://github.com/spantaleev/matrix-docker-ansible-deploy) playbook

Reply on news.ycombinator.com