Deployment of a complete Matrix/Synapse infrastructure — two dedicated servers, bridges to WhatsApp and Telegram, a shared database — for an organization that wanted to keep its conversations in-house, without sacrificing ease of use.
The organization had been using Slack for several years. As the contract renewal approached, management wanted to evaluate an alternative hosted in Europe — without giving up what employees already used daily: team discussions, direct messages, and above all the WhatsApp groups used with external partners who, themselves, would not switch tools.
The real challenge wasn't just replacing Slack, but doing so without forcing a break on external contacts — which steered the choice towards Matrix with application bridges rather than a simple migration.
No data hosted outside the European Union, hosting provider chosen and audited by the organization itself.
External contacts on WhatsApp and Telegram shouldn't have to change anything about their habits.
Strict separation between internal accounts and bridges to third-party services.
Being able to add a future bridge (Signal, Discord) without reworking the whole architecture.
The homeserver used daily by employees runs isolated from the homeserver that carries the bridges — an outage or update of a WhatsApp bridge can never affect internal messaging.
A single PostgreSQL VM, one database per component, adding a future component is a single variable entry away — no new Ansible task, no server restart.
The role never manages the reverse proxy, DNS, or TLS certificates — those responsibilities stay within the organization's shared infrastructure, keeping the role reusable elsewhere.
Bridge authentication tokens are generated once and kept — replaying the deployment never breaks an already active connection.
Database, user homeserver, homeserver + bridges, shared infrastructure — each with a single, documented role.
One homeserver for internal accounts, a second dedicated to the bridges — never mixed, never on the same application base.
Each bridge in its own container, its own database, its own registration file — adding the next bridge without touching the existing ones.
Checking that every bot responds and that messages flow both ways, before any team switches over.
Migration team by team, with Slack kept in read-only mode while everyone got comfortable with Element.
The business-level configuration of each bridge (WhatsApp QR-code pairing, Telegram linking) remains a manual step specific to each account — not automatable on the infrastructure side.
The reverse proxy, DNS, and TLS certificates aren't managed by this deployment — they belong to the organization's existing shared infrastructure.
Strong authentication (SSO/MFA) isn't integrated on this installation yet — a possible follow-up project with an identity provider the organization would validate itself.
Message backups are delegated to the hosting provider's existing backup policy — this deployment doesn't reinvent what's already handled correctly.
Every organization has its own constraints — let's talk about yours before talking about a solution.
Get in touch →