Matrix and Element: Self-Hosted Messaging That Federates

Three years ago a group chat I’d relied on for the best part of a decade evaporated overnight when the company behind the app got acquired and shut the service down. No export, no migration, a curt email and a dead login screen. That was the afternoon I decided the next messaging platform I trusted with my family’s conversations would be one I actually controlled. The pitch for Matrix is the same one email made fifty years ago and instant messaging has spent its entire existence refusing to make: you run your server, I run mine, and we talk anyway. No walled garden, no single company holding the keys, no app that gets bought and switched off while you’re mid-conversation. After running a Matrix homeserver for my family and a handful of friends for a couple of years, I’m convinced it’s the only self-hosted messaging story that actually delivers federation rather than just promising it. It’s also fiddly in ways worth being honest about before you commit a weekend to it.

What “federated” actually buys you

Federation means your identity is @you:example.com, tied to a server you control, and you can join rooms and message people on matrix.org, tchncs.de, or anyone else’s homeserver as if you were all in the same building. When you send a message to a room that has members on five different servers, your homeserver fans that message out to all five. Each server keeps its own full copy of the conversation history. Nobody’s chat lives in a single company’s database waiting for a business-model pivot to make it disappear.

The mental model that helped me most: Matrix is to chat roughly what SMTP is to email, except the history is replicated rather than delivered-and-forgotten, and encryption is built in from the start rather than bolted on decades late. Your address has a local part and a domain, discovery works across independent operators, and no central authority can revoke your ability to participate. If you already run infrastructure for its own sake, this is the same appeal that makes a project like self-hosting your own photo library with Immich satisfying: the data is yours, the uptime is yours, and the failure modes are yours too.

This replicated, federated design is the genuinely good part and also the source of every operational surprise you’ll have. A busy room with thousands of federated members means your little server is now syncing state from dozens of other servers, and that state can be surprisingly heavy. The famous example is the Matrix HQ room: join it from a cold homeserver and watch your CPU and database groan as it back-fills years of membership events from every server that has ever participated. Federation is a firehose you opt into one room at a time.

Synapse, Conduit, or Dendrite

There are three server implementations worth knowing, and picking the right one for your scale saves you a lot of grief.

Synapse is the reference implementation, written in Python and maintained by Element. It’s by far the most mature and compatible, supports every feature the spec has, and as of late 2025 still runs the overwhelming majority of homeservers on the network — north of 85% of deployments. It is also the most resource-hungry by a wide margin.

Conduit (Rust) and its actively-maintained forks such as Continuwuity take the opposite approach: a single static binary that asks “what is the minimum viable homeserver?” and builds exactly that. Conduit will run happily on a Raspberry Pi for a small group and starts in milliseconds. It lags Synapse on a handful of edge features, but for a family or a circle of friends you will likely never hit them.

Dendrite (Go) sits in between — a second-generation, componentised rewrite aimed at deployments that need to scale past a single box without carrying Synapse’s memory footprint.

For a family server I’d genuinely now reach for Conduit or Continuwuity. For anything where obscure compatibility edge cases matter, or where you’ll run bridges and bots against unusual features, Synapse remains the safe default. Here’s a minimal Synapse stack with the Postgres backend you should be using from day one:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

# docker-compose.yml
services:
  synapse:
    image: matrixdotorg/synapse:latest
    restart: unless-stopped
    environment:
      SYNAPSE_SERVER_NAME: chat.example.com
      SYNAPSE_REPORT_STATS: "no"
    volumes:
      - ./data:/data
    depends_on:
      - db
  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_USER: synapse
      POSTGRES_PASSWORD: change-me-please
      POSTGRES_DB: synapse
      POSTGRES_INITDB_ARGS: "--encoding=UTF8 --locale=C"
    volumes:
      - ./pgdata:/var/lib/postgresql/data

Use Postgres from the start, and note the --locale=C in the init args — Synapse is specific about collation, and getting it wrong on first init means a painful re-import later. Synapse will happily let you run on SQLite and then quietly make your life miserable once the database grows past a few gigabytes, at which point migrating to Postgres is a chore you’ll wish you’d avoided.

The .well-known trap

The single most common reason a new homeserver “doesn’t federate” is server discovery, and it catches nearly everyone the first time. Other servers need to find yours, and the way they do it is by fetching https://example.com/.well-known/matrix/server. If your Matrix server runs at chat.example.com but your user identities are @you:example.com — which is what you almost always want, because nobody wants to type the chat. prefix into their username — then you must publish a delegation file at the apex domain telling the world where the real server lives:

1

{ "m.server": "chat.example.com:443" }

That file has to be served with a Content-Type of application/json and be reachable over plain HTTPS on the apex. Get any part of it wrong and everything works locally — you can log in, you can message your own users — while the wider Matrix network silently can’t reach you. It’s the worst kind of bug because there’s no error; things simply don’t arrive.

The official Federation Tester is the tool you run before declaring victory. Paste your server name in and fix whatever it complains about until it’s green. Do not skip this step because “it works on my phone” — your phone is talking to your own server, which proves nothing about federation.

Element, and the encryption you’ll forget about

Element is the de facto client — web, desktop and mobile, all reasonably polished, with the newer Element X mobile apps built on a faster Rust core. Point it at your homeserver URL at login and you’re in.

Matrix supports end-to-end encryption per room, and here’s the bit people trip over hard: encryption keys live on your devices, not the server. This is a feature — your homeserver operator (you) genuinely cannot read encrypted rooms — but it has a sharp edge. If you log out everywhere without backing up your keys, your encrypted history becomes unreadable even to you, permanently. There is no reset button. Set up secure key backup the day you create the account, before you’ve said anything you’d miss.

Cross-signing — verifying your own devices against each other and your contacts’ devices — is what turns the alarming red “unverified session” warnings into a green shield of trust. It’s worth doing properly rather than reflexively dismissing the prompts, because those prompts are the entire point of the encryption model: they tell you when a new device has appeared claiming to be you or a contact.

Troubleshooting the things that will actually break

Federation silently fails. Run the Federation Tester first. Nine times out of ten it’s .well-known (wrong content-type, wrong port, served over a redirect it doesn’t follow) or a firewall blocking inbound 443/8448.

Synapse eats all the RAM. As your federated rooms grow, budget 1–2GB and watch it climb. The usual culprit is state accumulation in large rooms. Run the state-compression tool (rust-synapse-compress-state) and periodically call the purge-history and purge-remote-media admin APIs to keep the database from ballooning. A Synapse database that’s never been maintained will happily grow to tens of gigabytes.

“Unable to decrypt” messages. Almost always a cross-signing or key-backup gap — a device that was never verified, or history sent before a device came online with no key sharing. Verify all sessions and make sure key backup is enabled and its recovery key is stored somewhere safe.

Bridges are a second job. Bridges to WhatsApp, Signal or Telegram exist and are genuinely clever, letting you funnel other networks into Matrix rooms. But each one is another service to babysit, another database to back up, and a fresh security surface — a bridge holds credentials to the network it bridges. I run one; I would not run four.

Registration gets abused. Leave open registration on and you’ll wake up to spam accounts, and worse, your server can be roped into the abuse other operators see coming from you — at which point you land on block lists and federation degrades. Turn open registration off, require an admin-issued token or shared secret to create accounts, and treat your homeserver’s reputation on the network as something you actively maintain, not a given.

The database restore you never tested. The single scariest failure isn’t Synapse falling over; it’s discovering your Postgres backup can’t be restored on the day you need it. Because encryption keys live on clients, a lost server database costs you room state and history that the network won’t magically hand back. Take Postgres dumps, and actually restore one into a throwaway instance once, so “I have backups” means something.

If you’re the kind of person who keeps this running for years, you’ll want to point something at it so you find out about outages before your family does. Pairing the homeserver with Uptime Kuma for self-hosted monitoring took ten minutes and has caught two certificate-renewal failures that would otherwise have quietly severed federation for a day.

Is it worth it, and who is this for?

If you want frictionless secure chat for non-technical relatives and nothing more, just use Signal. It’s better at that exact job, it requires nothing of you, and it’s end-to-end encrypted by default. Matrix is not the easy answer there, and I’d be lying if I pretended otherwise.

Matrix is for the person who specifically wants the federated, self-owned model: an identity on a domain you control, history you keep forever, and the ability to participate in the wider open network without surrendering to anyone’s app. If that’s the itch, nothing else scratches it. Run Conduit or Continuwuity for a small circle or Synapse if you need maximum compatibility, get .well-known right on the first try, back up your encryption keys before you do anything else, and accept that you’ve adopted a small server with ongoing needs — updates, backups, the occasional database purge. I have no regrets. My family’s chat history is mine, it can’t be revoked by an acquisition or a shutdown email, and it’ll outlive whichever messaging app happens to be fashionable this year. Three years on from the group chat that vanished overnight, that alone has made the fiddliness worth every hour I spent on it.