Can anyone chime in on their experiences hosting a synapse server? I have close to a dozen people on mine (although we don't federate much with the network as a whole, I set it up initially for a couple of groupchats/DMs with friends) and I'm not even close to hitting the limits of the $5/mo Digitalocean server I put it on. Does federating with the greater Matrix ecosystem cost that much extra processing power, that one user's chats are taking multiple gigs of RAM and gigabytes of space? It looks like the author's using multiple bridges, which could be a problem, but my understanding is that bridges are separate programs that hook into synapse via an API.
I will agree that voip/video isn't there yet, tried it with some friends and none of us could get anything working. I did go out and set up a TURN server afterwards, but once a piece of tech fails as badly as element did for us the damage is done. E2EE could definitely be done better as well, but in another post on here I saw a comment detailing a bunch of clients (many of which were abandonware) that didn't support E2EE at all. That's going to kill mass adoption, since you have no idea how many people are on those zombie clients that you still need to support. I wonder if the Matrix API has a way to define versions for these purposes, to advertise the highest supported version by both the client and server?
I have been running my own Matrix instance with federation on my 20 dollar/month Linode VPS for 5 years already.
I use between some friends and family and I'm also connected to massive channels like the official "Element Android" and "Element Web/Desktop".
And it runs... just fine. The server can be a bit performance hungry but I also host plenty of other services on my VPS (email, HTTP server, Seafile, VPN, etc) and I never noticed any degradation in performance in any of them.
They have been making a lot of progress in improving the performance of the Synapse server and it is very usable now. And it is not difficult to configure at all, it's easier than configuring Prosody.
I would say that the bottleneck now is more about improving the UX and the Voip capabilities of the clients.
I have been running a Synapse instance for nearly 3 years now. My instance is not for open registration but just for family and friends, currently it has around 7 users on it and federates with the rest of the Matrix ecosystem. I also have some experience writing apps that use the Matrix APIs.
The federation API on matrix is a little too chatty for my taste. But that in itself causes no problems. The problems start when a user on your homeserver joins a massive room on any other homeserver. Most commonly these are the bug rooms on matrix.org. Once someone joins one such room, synapse will start slowing down and taking tons of RAM. This has significantly improved in the last year, by huge leaps and bounds. It however does remain a memory hungry process.
VoIP / video on the other hand has been a success story for me. 1:1 calls run smoothly after installing a TURN server. Me and my users use the calling functionality multiple tines a day and don't seem to have any problems with it.
I've been running one on my server for about 4 years. My server is a computer I got for free (some dell optiplex with an i3 in it), it eats 20W of power. It works more or less well depending on available bandwidth (on ADSL attachments were a pain).
These days it's mostly fine. The database is about 15GB (including media), there are scripts around the net to clean it up (rooms you've left, etc). Joining big, federated rooms is ram-expensive with synapse, though you now can specify a maximum complexity on your server to prevent joining those. Other small federated rooms are completely fine to join, and don't cost much more than a local room (IMO, there's little point in hosting a non-federated matrix server).
I use yunohost to simplify deployment, though it has some limitations. I did give access to a few friends, but I feel like I cannot guarantee uptime even though it has been pretty good so far. Once profiles-as-rooms land, that might change, as a user could just hop on another server if mine is down.
I just set up synapse last week. The config file has 93,000 characters in it, which i joked is worse than IRCd. I'm running it on gentoo, pretty bare system, probably equivalent to double an rpi4. I did notice that the database file grows quickly. Currently the entire machine is using 272MB RAM, 0.8% CPU peaks, 0.01 15 minute load average.
Every part of setting up a server that will federate/host repeats again and again that you need a TURN server (and they recommend coturn) - which is another 26,000 character config file - in order to do VOIP. If you've ever run or used a pbx before, STUN is needed 100% of the time for nat traversal between clients. Coturn even says it won't run if it's NAT'd (it will, but that's irrelevant to most people.)
This is the fourth concurrent tech trial of chat daemons, with rocket.chat and mattermost being a couple of the other ones that we're testing. synapse/element/matrix has the benefit of forced e2ee by my configuration. I don't know of any other matrix federated servers, so i haven't tried that yet, but an associate says it works on my configuration - which means it's not as big of a pig as i thought it was based on the outlandishly, comically large config file - where whitespace matters!
I’ve been hosting my own homeserver for a few years on my own personal computer with a residential internet connection. It’s technically a violation of Verizon’s TOS but they don’t seem to care, probably since the traffic isn’t crazy.
I have about 20 users, with 5 of us being really active (but not much federation).
The computer is an Intel Kaby Lake i7 - really nothing special. I’ve never noticed crazy CPU usage.
Yes the federation completely killed my 5usd vps last time ive tried it. Ive been running synapse for 5+ years for about 20 active users.
I have it running on 4gb 8core arm sbc nowadays and i dont dare to federate. When somebody connects to a federated room with history and many users it explodes.
It seems future will be federated but with beefy servers.
Considering Matrix supposed to be the answer to decentralization... its mostly used on one main instance or in centralised silos like companies.
I didn't try personally, but i heard from some hosting cooperatives they dropped synapse (and matrix entirely) because it was too resource hungry. for example disroot https://disroot.org/en/blog/matrix-closure
I run a non-federated instance on a tiny 2GB RAM ARM SOC. About 4-5 active users. Extremely light (under 80MB RAM usage) as long as you don't federate. Attempted enabling federation once - maxed out all cores, all mem/swap, and basically blew up the entire machine. Had to wipe away the database and start without federation.
Encryption UI is a mess. I have actively tried and failed to set up E2E encryption with at least one other technical user. Recommend disabling encryption unless you want non-technical users to abandon ship immediately.
I will agree that voip/video isn't there yet, tried it with some friends and none of us could get anything working. I did go out and set up a TURN server afterwards, but once a piece of tech fails as badly as element did for us the damage is done. E2EE could definitely be done better as well, but in another post on here I saw a comment detailing a bunch of clients (many of which were abandonware) that didn't support E2EE at all. That's going to kill mass adoption, since you have no idea how many people are on those zombie clients that you still need to support. I wonder if the Matrix API has a way to define versions for these purposes, to advertise the highest supported version by both the client and server?