Synapse

Self-hosted federated messaging, honestly reviewed. The most battle-tested Matrix homeserver, and also the most demanding one.

TL;DR

• What it is: The original, reference implementation of a Matrix homeserver — the server software that powers decentralized, federated, end-to-end encrypted messaging [1][2].
• Who it’s for: Privacy-focused organizations, open-source communities, and technical teams who want to own their communications infrastructure instead of paying per-seat SaaS bills forever [1].
• License: AGPL-3.0 (free to self-host); commercial license available from Element for proprietary embedding [1].
• Cost savings: Slack costs $7.25–$12.50/user/month. A 20-person team pays $1,740–$3,000/year. Synapse on a $20/month VPS is $240/year — perpetually, regardless of headcount growth.
• Key strength: Federation. Your Synapse server can talk to every other Matrix server on the internet — including matrix.org — giving users a cross-organization communication network no proprietary chat tool can match [2].
• Key weakness: Resource appetite and operational complexity. This is Python (plus Rust for hot paths), it needs PostgreSQL, it idles at 500MB+ RAM with modest usage, and the setup is legitimately hard for anyone who hasn’t run a production web service before [1][3].

---

What is Synapse

Synapse is the original Matrix homeserver, written in Python/Twisted with performance-critical components rewritten in Rust. It is developed and maintained by Element (formerly New Vector, the company spun out of the Matrix.org foundation) [1].

Matrix itself is an open standard for real-time communication — think of it as email but for chat. Each organization runs its own homeserver; those homeservers federate with each other. A message sent from a user on your company’s Synapse instance can reach a user on matrix.org, or on a university’s homeserver, or on any other Matrix-compatible server in the world. Nobody controls the network. There is no central server to go down, no vendor to raise prices, no terms-of-service change that kicks out your community [2].

The practical comparison: Synapse is to Slack what running your own email server is to using Gmail. More powerful, more private, more effort.

Element’s README is honest about the deployment story: the recommended approach for most operators is the Element Server Suite (ESS), a Helm-based Matrix distribution with three tiers — ESS Community (free, for small non-commercial use), ESS Pro (commercial, for enterprises), and ESS TI-M (a specialized version for Germany’s healthcare messaging requirements) [1]. Running Synapse standalone is possible and well-documented, but Element pushes you toward ESS for anything serious.

As of this review, the element-hq/synapse repository sits at 3,911 GitHub stars — a number that understates actual adoption, since the project was migrated from its original matrix-org/synapse home (which accumulated stars over a decade before the move).

---

Why people choose it

The reasons to run your own Matrix homeserver cluster around three recurring concerns: cost at scale, data ownership, and federation.

Cost at scale. Slack, Microsoft Teams, and Google Chat all bill per user per month. That model is fine when you have 10 people. At 50+ people it becomes a significant line item. At 200+ people in growth-stage companies it is often the first SaaS cost that gets challenged. The math on Synapse is simple: the software is free, you pay for compute, and compute does not scale with headcount. A Hetzner CPX31 (4 vCPU, 8GB RAM, €13.80/month) comfortably handles a few hundred active users [3].

Data sovereignty. Enterprise teams in finance, legal, healthcare, and government care where their messages live. End-to-end encryption (E2EE) is supported natively in Matrix — it is not an add-on [2]. With Synapse self-hosted, the server operator never has access to E2EE message content at all. No third-party vendor is copying your conversations for model training or advertising.

Federation. This is the capability that has no equivalent in proprietary tools. Your organization’s Synapse server can join public Matrix rooms, collaborate with users on other homeservers, and participate in communities across the Matrix network — while keeping your internal rooms private and your data on your own infrastructure. Mozilla, KDE, Fedora, and the German government’s Bundeswehr all run Matrix deployments specifically because federation means they can talk to the outside world without routing messages through a vendor’s servers.

---

Features

Based on the GitHub README and official documentation [1][2]:

Core messaging:

• Text rooms, threads, rich formatting (Markdown)
• Direct messages and group rooms
• Voice and video calling (via WebRTC; requires a TURN server for NAT traversal)
• File and media sharing
• Read receipts, typing indicators, presence
• Message history retention controls per room

Security and encryption:

• End-to-end encryption via Matrix’s Olm/Megolm protocol (managed by clients, not the server)
• Room-level access controls (public, knock, invite-only)
• Server-to-server TLS for federation
• Client-to-server TLS (standard HTTPS)
• User verification via cross-signing

Federation:

• Full Matrix federation — your server joins the global Matrix network [2]
• Room alias sharing across servers
• Configurable federation allowlists/denylists for private deployments

Administration:

• Admin API for user management, room management, and server statistics
• Rate limiting configuration
• Media purge tools (the media store grows indefinitely without manual management)
• Server-side search (requires the optional Synapse Search module or a Postgres full-text configuration)
• Configurable retention policies per room

Bridges (not bundled, but standard practice):

• Matrix bridges exist for Slack, Discord, IRC, Telegram, WhatsApp, Signal, and dozens of others [2]
• Bridges run as separate processes alongside Synapse; the most mature are mautrix-* (Python/Go)
• This is the migration path: keep your team on Slack while bridging to a self-hosted Matrix room, then cut over when ready

Deployment features:

• Docker and Helm (ESS Helm chart for production) [1][2]
• PostgreSQL backend required for production (SQLite supported only for development)
• Worker mode: Synapse can be split across multiple processes for high-traffic deployments
• Configurable media storage (local filesystem, S3-compatible object storage)

What is NOT included:

• A web or mobile client (use Element, Cinny, FluffyChat, or any other Matrix client)
• Push notification infrastructure (requires a separate push gateway like sygnal)
• TURN server for voice/video (requires coturn, configured separately)

---

Pricing: SaaS vs self-hosted math

Synapse itself: $0. AGPL-3.0 for self-hosting. Commercial license required only if you embed Synapse in a proprietary product [1].

Element’s managed hosting (Element Matrix Services / EMS):

• Starter: pricing not publicly listed; contact required
• ESS Pro: commercial, contact sales
• This is for teams that want the Matrix stack without the ops burden

Infrastructure cost for self-hosting:

Scale	Hardware	Estimated monthly cost
1–20 users	2 vCPU, 4GB RAM (e.g. Hetzner CPX21)	~€7–$10
20–100 users	4 vCPU, 8GB RAM (Hetzner CPX31)	~€14–$20
100–500 users	8 vCPU, 16GB RAM + separate PostgreSQL	~€30–$60
500+ users	Worker deployment, multiple nodes	$100+

These estimates assume you are not federating with high-traffic public rooms. Joining a room with 50,000 members (like the Matrix HQ room on matrix.org) will spike RAM and CPU noticeably — Synapse has to replicate room state.

Competitor comparison:

Tool	Model	20 users/year	50 users/year
Slack Pro	$7.25/user/month	$1,740	$4,350
Microsoft Teams Essentials	$4/user/month	$960	$2,400
Discord Nitro (per user)	$9.99/month individual	not team-priced	not team-priced
Synapse self-hosted	VPS only	~$120–240	same (~$120–240)

The break-even point on setup time is around 10–15 users at Slack Pro pricing — the VPS savings pay for a half-day of setup within the first month.

---

Deployment reality check

This is where the honest review diverges from the marketing.

Synapse is not beginner-friendly. The README says as much by steering new users toward the ESS Helm chart rather than standalone installation [1]. The standalone path works, but it has real prerequisites.

What you actually need:

• A Linux VPS (Debian/Ubuntu recommended) with at minimum 2GB RAM; 4GB is the realistic floor for any active usage
• PostgreSQL 13+ (SQLite is explicitly not production-ready)
• A domain name you control, with DNS pointing to the VPS
• A valid TLS certificate (Let’s Encrypt via Certbot or Caddy works)
• A reverse proxy (nginx or Caddy) — Synapse does not serve HTTPS natively
• Optional but practically required: coturn (TURN server) for voice/video to work through NATs

What typically goes wrong:

Federation misconfiguration. Matrix federation requires your server to be reachable at port 8448, or a .well-known delegation file served at the correct path. Getting this wrong means your users can’t interact with the outside Matrix network — a silent failure that’s annoying to diagnose.

Media store bloat. Every image, file, or avatar sent through your homeserver is stored locally (or in S3 if configured). There are no automatic purge tools in the default setup. A homeserver that’s been running for a year without media pruning will have gigabytes of storage consumed by thumbnails [3].

RAM ceiling surprises. Synapse’s memory usage scales with the number of rooms it’s tracking, particularly federated rooms with many members. Joining your users to public Matrix rooms (Matrix HQ, various open-source project rooms) can double idle RAM use. Budget more than you think you need.

Python upgrade friction. Synapse tracks Python releases and drops support for older versions. Servers on long-term-support distros occasionally need Python version management (pyenv or Docker) to stay on current Synapse releases.

Realistic time estimates:

• Technical user following official docs: 2–4 hours to a working instance with federation
• Non-technical user: this is not a realistic solo project; budget for someone to deploy it for you
• With ESS Helm on an existing Kubernetes cluster: 30–60 minutes for experienced Kubernetes operators

The community support room (#synapse:matrix.org) is active. Element explicitly states there is no free support for standalone Synapse — support is included only in ESS subscriptions [1].

---

Pros and Cons

Pros

• True data sovereignty. Your messages, your server, your storage. E2EE means even you (as server operator) can’t read message content [2].
• Federation. No other self-hosted team chat tool connects your organization to the broader internet-wide communication network. Slack and Discord are walled gardens by design.
• Bridge ecosystem. The mautrix bridge collection is mature and actively maintained — Slack, Discord, Telegram, WhatsApp, Signal. The bridge path is how most teams migrate without a hard cutover.
• AGPL-3.0 license. Free for self-hosting without restrictions. Commercial embedding requires a license from Element, but self-hosters are not in that bucket [1].
• Rust performance improvements. The push-rule and state resolution modules have been rewritten in Rust over the past two years, meaningfully reducing CPU usage on busy servers [1].
• Mature project. Been in production since 2014. The codebase, protocol, and community are stable. This is not a weekend project — it is what Mozilla and KDE run their communities on.
• Multiple client choices. Element, Cinny, FluffyChat, Hydrogen, and others — the protocol is open, no vendor lock-in on the client side either.

Cons

• Resource appetite. Synapse is the heaviest Matrix homeserver implementation. Conduit (Rust) and Dendrite (Go) both idle significantly lower. On a $5/month VPS, Synapse will struggle; they won’t.
• Complex setup. There is no “one-click install” path to a properly configured, federated Synapse instance. The official docs are thorough but assume familiarity with Linux server administration [1][3].
• No bundled voice/video infrastructure. You must separately deploy and configure coturn to make 1:1 and group calls work reliably across NATs.
• Media store is not automatic. Without manual pruning scripts or S3 lifecycle policies, media storage grows indefinitely.
• Federation cost. Joining high-traffic public rooms pulls room state from the network. A busy open-source community room can measurably spike your server’s load.
• No free support from Element. The README states it explicitly: if you’re not on an ESS subscription, you’re on community support only [1].
• Slower than alternatives on limited hardware. Conduit (Rust) and Dendrite (Go) are meaningfully faster to start and lighter at idle. For solo users or very small teams, they are often better choices.
• Python dependency management. Running on a long-lived server requires keeping Python versions compatible with Synapse’s releases — occasionally a friction point on LTS distros.

---

Who should use this / who shouldn’t

Use Synapse if:

• You’re running Matrix for 20+ users in an organization that wants to own its infrastructure.
• You have someone technical (or are willing to pay for deployment once) who can handle Linux, PostgreSQL, and nginx.
• Federation matters: you want your users to interact with the broader Matrix network, open-source communities, or other organizations running Matrix.
• You need bridges to Slack or Discord during a migration — the mautrix ecosystem is production-quality.
• You are in a regulated industry where third-party SaaS is a compliance problem.

Use Conduit or Dendrite instead if:

• You want a Matrix homeserver on limited hardware ($5 VPS, Raspberry Pi, NAS).
• Your homeserver is for a small household or personal use (1–5 users).
• You don’t need worker-mode scaling and want something that stays under 100MB RAM at idle.

Skip Matrix entirely if:

• Your team is not technical and you won’t have budget for managed hosting — setup and maintenance overhead will exceed the cost savings.
• You need voice/video as a first-class feature (Matrix voice/video works but is not the smooth experience that Google Meet or Zoom is).
• You have fewer than 10 users and the Slack free tier covers you.

Use Element Matrix Services (managed) if:

• You want the Matrix ecosystem (federation, bridges, E2EE) without self-hosting the ops.
• Your compliance team won’t approve self-hosted infrastructure but is fine with Element as the vendor.

---

Alternatives worth considering

• Conduit — Rust-based Matrix homeserver. Dramatically lighter than Synapse. Runs on a Raspberry Pi. Still maturing (some federation edge cases), but the right choice for small homeservers [3].
• Dendrite — Go-based Matrix homeserver developed by the Matrix.org team. More feature-complete than Conduit, lighter than Synapse. Good middle ground for medium-scale deployments.
• Mattermost — Self-hosted Slack alternative. No federation, but a much simpler deployment story and a polished UI that non-technical users can actually navigate without training.
• Rocket.Chat — Self-hosted team chat with video, channels, and federation of its own kind. More feature-complete out of the box than Matrix clients, but a heavier stack (Node.js + MongoDB).
• Zulip — Self-hosted team chat with a thread-first model that actually works for async communication. Open-source core, simpler deployment than Synapse, no federation.
• Element Matrix Services — If you want Matrix without managing Synapse, Element’s own managed hosting is the obvious path.
• Slack / Microsoft Teams — If operational overhead is not acceptable and compliance isn’t a blocker, the SaaS tools are genuinely easier. The honest trade-off.

---

Bottom line

Synapse is the right answer to a specific question: can I run a production-grade, federated, end-to-end encrypted team chat server that I fully control? For that question, the answer is yes, and Synapse is the most battle-tested way to do it. The trade-off is real ops overhead — PostgreSQL, TURN, federation configuration, media pruning, Python version management. None of it is insurmountable, but it is a system to run, not software to install and forget.

For organizations with 20+ users, a technical person on staff, and a real problem with Slack/Teams pricing or data residency, the math favors self-hosting quickly. A Hetzner VPS and a half-day of setup replaces a SaaS bill that compounds with every hire. For everyone else — small teams, non-technical founders, anyone who doesn’t want to think about server maintenance — look at Mattermost, Zulip, or Element’s own managed hosting before committing to the Synapse path.

If the deployment is the blocker, upready.dev handles exactly this kind of one-time infrastructure setup for clients. You own the server; we make it work.

---

Sources

1. Element Synapse GitHub Repository — README, license, deployment instructions, ESS editions. https://github.com/element-hq/synapse
2. Matrix.org — Matrix open standard, federation model, E2EE specification, bridge ecosystem. https://matrix.org
3. Synapse Official Documentation — Installation, configuration, reverse proxy, federation, administration. https://element-hq.github.io/synapse/latest/
4. Element Server Suite (ESS) — Commercial and community editions, pricing context. https://element.io/server-suite
5. ESS Community Helm Chart — Helm deployment reference for self-hosted Matrix. https://github.com/element-hq/ess-helm