Skip to Content

Really replacing Slack and Teams: deploying Matrix and Element

You know why Matrix. Here's the how: the server, the client, the calls, and especially how to migrate a team without breaking everything.

A few months ago, we explained why Matrix is a real alternative to Slack and Teams. The post has been read thousands of times, and ever since, one question keeps coming back: « OK, but how do we actually deploy it? » Here's the practical follow-up. Not theory: the real setup, with the pitfalls we've hit.

Because that's where most projects stall. Picking a free tool takes an afternoon. Running it reliably for a team that depends on it every day is a different craft.

Matrix in a nutshell (a refresher)

Matrix is an open real-time communication protocol. Instead of a single service owned by one company, it's a network of servers that talk to each other, a bit like email: everyone hosts their own server, and they can still all communicate. Your conversations live on your server, end-to-end encrypted by default in new rooms.

In plain terms, you're no longer a tenant on a platform that can change its pricing, its terms or shut down your account. You're the owner. That's the whole point, and that's also all the work.

The pieces to assemble

Unlike Slack, where you create an account and that's it, Matrix is built from a handful of components. Let's go through them, no jargon.

The server (the « homeserver »)

This is the heart of it: the software that hosts your accounts, your rooms and your messages. Three broad families are worth considering.

Server Tech Who it's for Worth knowing
Synapse Python The reference implementation, the most feature-complete Resource-hungry, but it's the one that gets every new feature first
Dendrite Go Lighter, second-generation In maintenance mode since 2025: security fixes only. Avoid for new deployments
Tuwunel and Continuwuity (Rust forks) Rust Very lightweight, single binary, ideal for a small team Tuwunel is the official successor to conduwuit, funded notably by the Swiss government, which deploys it at scale. Continuwuity is the community-driven continuation, very active. The original Conduit, still in beta, is moving slowly.

For an SMB, the usual reflex is Synapse (the comfort of the official implementation) or a Rust server if you want something light on a small machine. The right pick depends on user count and your tolerance for system administration.

The client

It's the application your employees see: Element, by far the most polished, runs on the web, on desktop and on mobile. On mobile, its new generation (Element X) is much faster and caught up with the classic app's features in late 2025: it's now the reference. Other clients exist, but for a team coming from Slack or Teams, Element is the most familiar ground.

Deploying your server, step by step

Without going line by line, here's the real path of a clean installation. Every step matters: skip one and you get the kind of glitch where « it works on my machine but not for anyone else ».

First, a domain name and a reverse proxy (Nginx or Caddy) with a TLS certificate: everything runs over HTTPS. Next, .well-known delegation: two small files that tell the rest of the network and the apps where to find your server. It's the step most often rushed, and the one that silently breaks federation.

Then the server itself, in a container, with its PostgreSQL database. That leaves two pieces that each deserve their own explanation: calls and mobile notifications.

Calls: Element Call changed the game

For a long time, a TURN server (coturn) was all you needed to get calls through firewalls. It's still useful for one-on-one calls from older clients, but the current standard is called Element Call: calls, one-on-one and group alike, go through a dedicated streaming server (the LiveKit SFU) and a small authorization service, also announced in your .well-known files. This is the setup that powers calls in Element X, end-to-end encryption included. Concretely: two more containers. If your teams do video calls, plan for them from the start rather than bolting them on later.

The sticky issue of notifications

On mobile, getting a notification when the app is closed goes, by default, through Google's services (Android) or Apple's (iOS). Ironic for a sovereign solution. The bright spot: there's a degoogled alternative (UnifiedPush) if all-the-way privacy matters to you. It's doable, but it's a conscious choice to make from the start, not later.

Migrating a team without breaking everything

The classic mistake: announcing on a Monday that « from today, everyone's on Matrix ». A messaging migration is a habit change, not a software change. It happens gradually.

The key is bridges: they temporarily connect Matrix to your current tools. Someone on Matrix can keep writing to a team still on Slack, and vice versa. Bridges to Slack, Discord, WhatsApp, Telegram and Signal are mature. The Teams one remains experimental and mostly targets personal accounts: if Teams is at the heart of your organization, plan for a temporary coexistence rather than a permanent bridge.

In practice, you roll out in waves: a pilot team, keep the bridges while habits form, then drop them when nobody asks for the old tool any more. Structure conversations with « Spaces » (the equivalent of project-grouped channels), and document a couple of simple conventions to avoid the early mess.

Want Matrix without becoming a sysadmin? We host and run your server in Quebec, on infrastructure that belongs to you, with migration and bridges included. Let's talk about your team messaging.

Where it gets tricky

Matrix comes with very real trade-offs, so let's name them.

The first is operational load. A Matrix server that runs well needs updates, backups and a bit of monitoring. It's not « install and forget ». The second is end-to-end encryption: excellent for security, but cross-device key management can throw off a non-technical user (the infamous « can't decrypt this message » if they lose their keys). It's manageable, but it has to be explained.

Finally, bridges are handy but fragile: they depend on third-party APIs that change. They're perfect for a transition, less so for permanent reliance. The goal stays the same: retire them.

At Blue Fox

We deploy Matrix when a team wants to own its communications rather than rent them, and is ready to take on (or delegate) the operational work that comes with it. For small teams, a light Rust server is plenty. For organizations that want every feature, Synapse remains the safe pick.

Our recommendation is simple: start with a pilot with bridges in place, measure real adoption, and only retire the old tool when nobody asks for it any more. A successful migration is one people barely notice.

If you're torn between running it yourself and having us host it, we'll talk it through and decide based on what you can actually take on.

Sources

Font Awesome: do you really need Pro?
Free, Pro, Pro+: what you actually get for $60, $120 or $600 USD a year, and when an open library does the job better.