wickend.dev / Writing / Why I Run My Own Matrix Server
9 min read

Why I Run My Own Matrix Server

notes from three months of running a Conduit-fork on a homelab box, with WhatsApp / Telegram / Discord / LinkedIn bridges and one shared identity.

I have one identity I want my friends to talk to me through. WhatsApp, Telegram, Discord, LinkedIn, Instagram, Messenger — none of them think this is their problem. So for years I’ve been the person juggling six apps, six sets of unread badges, and six reasons to context-switch during deep work.

For the last four or five years I lived inside Rambox, which crams every chat app into one window via Electron. As a unifying frontend it works, and for a long time it was good enough. Two things eventually stopped being good enough: the resource footprint kept getting heavier as I added services, and there’s no programmatic surface — meaning no way for an AI assistant to read or act on any of it. There’s also no Rambox on phones, so the “one inbox” promise was already half-broken every time I unlocked my phone.

Matrix takes the opposite shape. Open source, self-hostable, runs the homeserver as a single binary on a small box. Bridges have existed for every major network for a long time, and the math works out: one homeserver, one bridge per network, every conversation in one client — and the client is a normal Matrix client (Element on Mac, Windows, Linux, FluffyChat on Android) that runs natively wherever I am. I finally did the thing.

The Server

Synapse is the reference implementation but it’s heavy. I ended up on Tuwunel — a Conduit fork written in Rust — running on a small home-lab mini-PC I call Hive. It sits around 385 MB of RAM idle, ships as a single binary, and stores everything in RocksDB. Boring infrastructure in the good way.

The Bridges

All from the mautrix project:

  • mautrix-whatsapp — pairs with the WhatsApp Web QR flow, then runs as a long-lived process.
  • mautrix-telegram — connects via Telegram’s MTProto.
  • mautrix-discord — uses an unofficial-but-tolerated Discord token flow.
  • mautrix-linkedin — runs against a LinkedIn web session; the most fragile of the five (more on that below).
  • mautrix-meta — one bridge, covers both Instagram and Messenger.

Three Months In

The four other bridges (WhatsApp, Telegram, Discord, Meta) have stayed up well enough that I don’t think about them. The one I babysit is mautrix-linkedin. LinkedIn doesn’t want a long-lived programmatic session, and the out-of-the-box config gets flagged fast. Two things help: override the bridge’s user-agent so requests look like a current real browser, and accept that the session expires on its own schedule and you’ll re-auth from time to time. It’s the only bridge I have a maintenance ritual for.

The biggest UX win isn’t fewer notifications. It’s getting all of them in one place where the search bar actually works. “What did <friend> say about that book in October” is a single query now, regardless of which app the conversation originally happened in.

The whole stack — Tuwunel plus five bridges — sits around 550 MB of RAM idle, with ~1.7 GB on disk after three months. That’s a fraction of what Rambox was eating, and it’s the same conversations on every device I own (Element on Mac/Windows/Linux, FluffyChat on Android) instead of an inbox that disappeared the moment I picked up my phone.

// tags: matrix · homelab · self-hosting