Running a Matrix homeserver
Matrix gives you federated, end-to-end-encrypted chat where you own the server and your users’ identities live under your own domain. Synapse is the reference server; it rewards a bit of planning.
The one decision you cannot undo in Matrix is the server name — the part after the colon in @you:example.com. It is baked into every room and event. Choose it before you install, and use a clean domain you are happy to keep.
Server name vs. where it runs
The server name does not have to be where Synapse actually listens. Delegation (a .well-known file or SRV record) lets example.com be the identity while the server runs on matrix.example.com. Set this up first; retrofitting it is painful.
PostgreSQL, not SQLite
Synapse ships defaulting to SQLite, which falls over on any real room. Create a PostgreSQL database with the right locale and point Synapse at it from day one — migrating later means exporting and re-importing the whole thing.
Media grows forever
Synapse caches media from every remote room your users join. Left alone, that directory reaches hundreds of gigabytes. Run the retention and the media-repository cleanup jobs, and keep the store on its own volume — see a disk that fills up.
Federation and ports
Federation happens on port 8448 (or via delegation on 443). If you want your users to talk to the wider Matrix network, that port must be reachable; if you want a private island, firewall it off deliberately — see a firewall that does not lock you out.
When one process is not enough
A single Synapse process handles a surprising amount, but once you have hundreds of active users you split it into workers — separate processes for federation, media and client sync. Plan the box with that in mind rather than discovering it under load.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base