Confidential client · Romania · Q4 2025
The Dendrite deployment guide behind this engagement — federation hardening, Element X setup, and the honest account of what's still hard.
The Keycloak deployment behind this engagement — how 47ID integrates with Matrix homeservers and bridges so every login goes through the NGO's centralised identity provider.
Admin access to the NGO's Matrix homeserver uses WireGuard — the VPN tunnel setup, key management without a central server, and the routing config that restricts management access to a single IP.
A 200-person Romanian NGO conducting sensitive human rights documentation work had its communications scattered across WhatsApp, Telegram, Slack, and Signal — four separate platforms, none of which they controlled. Their work involved confidential source communications and internal coordination on sensitive investigations. A security incident on any of these platforms could expose sources and compromise active cases.
The NGO had no technical staff. Their previous attempt to self-host a Matrix server had failed after three months when the server ran out of disk space and nobody knew how to recover it. They needed a deployment that would be maintainable by a non-technical operations team, with clear runbooks and a support escalation path.
The additional constraint: they couldn't do a hard migration. Staff were deeply embedded in WhatsApp group chats with external partners. The solution had to allow gradual migration — new messages in Matrix, but bridges keeping legacy platform members in the loop during the transition period.
We deployed Synapse on a dedicated VPS with ZFS storage for reliable volume management and automatic snapshots. The homeserver is hardened: registration disabled, federation limited to a whitelist of trusted servers, media retention policies enforced, and Mjolnir for abuse management.
We deployed four Mautrix bridges as separate processes: mautrix-whatsapp, mautrix-telegram, mautrix-slack, and mautrix-signal. Each bridge runs as a dedicated systemd service with resource limits and automatic restart on failure. Bridges connect to the Synapse homeserver via the Application Service API — they appear as bot users in Matrix rooms, transparently relaying messages between platforms.
This allowed a clean migration path: users could join Matrix rooms immediately while bridges kept external contacts (who hadn't migrated yet) receiving messages via their existing platforms. As contacts migrated, their bridge connections were simply deactivated — no disruption, no group chat splits.
Staff accounts are provisioned via LDAP sync from the NGO's existing directory. New hires get Matrix accounts automatically on their first day; leavers are deactivated without manual intervention. Element Web is deployed as the primary client, hosted on the same infrastructure. Element X (native apps) is used on mobile — significantly better than the old Element app in our testing.
We designed this explicitly for non-technical operators. The runbook is 12 pages, written in plain language with screenshots. Common operations (adding a user, clearing a stuck bridge, recovering from a full disk) are documented as step-by-step procedures. We set up automated S3 backups of the Synapse database and media store, tested restoration, and left a recovery exercise in the handover training.
"For the first time, our entire team is in one place. We know our communications are ours. The bridges meant we didn't have to force anyone — people migrated when they were ready."
— Operations Director, Confidential NGO ClientMost Matrix deployments fail at the bridges. WhatsApp and Telegram bridges require phone numbers, persistent connections, and careful rate-limit management — and they break silently when the underlying messaging platform changes its protocol. We deployed the mautrix suite with a dedicated monitoring alerting configuration: if any bridge went silent for more than five minutes, the on-call person got a page. The NGO's staff continued using their existing WhatsApp and Telegram contacts through the bridge without those contacts needing to change anything on their end.
The room structure was designed for their specific threat model. Sensitive investigation rooms were configured with encryption-verified membership only — Element X would show a warning if any unverified device joined. General operational rooms used standard encryption. External-facing rooms (for bridge traffic from WhatsApp contacts) were clearly labelled and kept separate from internal coordination. A runbook documented exactly how to add a new user, revoke access for a departing staff member, and rotate bridge credentials.
Disk management was handled via a cron-based media purge policy — remote media older than 90 days is automatically pruned, local media is retained indefinitely. The server that had failed previously had no such policy. We configured Prometheus alerts for disk usage at 70% and 85% — the NGO's ops person gets an email at 70% and a phone call at 85%, long before anything breaks.
The bridge strategy was critical to adoption success — no forced hard-cutover meant staff could migrate at their own pace while external contacts continued receiving messages normally. By the end of week 6, 78% of previously-external contacts had joined Matrix directly.