Self-Hosted Matrix Messaging with Synapse

Real-time communication is one of the areas where organizations are often most dependent on external Software as a Service (SaaS) providers. Chat history, file attachments, user directories, and internal conversations may all live on infrastructure operated by Microsoft, Slack, Discord, or another third party. For teams that want more control over where their communication data is stored and how their messaging infrastructure is operated, Matrix provides an open alternative.

Synapse is the most widely used Matrix homeserver implementation. It provides the server-side infrastructure behind Matrix users, rooms, messages, federation, authentication, and media storage. Synapse is developed by Element and can be self-hosted on your own infrastructure. Combined with a Matrix client such as Element, it can provide an organization with a complete chat platform while still allowing communication with users hosted on other Matrix servers.

Synapse project information:

Name: Synapse

URL: https://element-hq.github.io/synapse/

License: AGPLv3 or Element Commercial License

Protocol: Matrix

Language: Python/Twisted with Rust components

Latest Release: 1.163.0

Database: PostgreSQL recommended

Commercial Offering: Synapse Pro/Element Server Suite

A Homeserver for the Matrix Network

Matrix is a federated communication protocol. Instead of every user belonging to one central provider, organizations can operate their own homeservers while still communicating with users on other servers.

Synapse implements this homeserver role. When a user creates an account on a Synapse server, their Matrix ID contains the server name (e.g., @alice:example.com). Rooms, users, messages, membership information, and other Matrix events are then handled by one or more homeservers participating in the conversation.

For self-hosters, choosing the server_name is therefore one of the most important decisions during installation. The value becomes part of user IDs and room addresses and cannot simply be changed later. A company might therefore use example.com as its Matrix identity while physically running Synapse at matrix.example.com.

Synapse does not normally include the user-facing chat interface itself. Users connect with a Matrix client such as Element, FluffyChat, or another compatible application. This separation between client and server is one of Matrix's strengths: Users are not tied to a specific application simply because the organization chose Synapse as its server.

Federation

Federation is what distinguishes Matrix from many self-hosted chat systems. If federation is enabled, users on your Synapse server can join rooms with users hosted elsewhere, and remote Matrix servers can exchange events directly with yours.

This makes Matrix conceptually closer to email than to a traditional company chat platform. Two organizations can each operate their own infrastructure without needing accounts on the same central service.

Federation does, however, make the network setup slightly more involved. Other Matrix servers need to know how to reach your homeserver. By default, this is derived from the configured server_name, but Matrix also supports delegation through .well-known files. This allows user IDs such as @alice:example.com while Synapse itself runs at another hostname such as matrix.example.com.

For private installations, federation can also be restricted or disabled. A company that only wants Matrix as an internal communication platform does not necessarily need to expose its homeserver to the wider Matrix federation.

Deployment and Database

Synapse can be installed from packages, Python environments, or containers. For a production self-hosted deployment, a typical architecture consists of Synapse, PostgreSQL, a reverse proxy, persistent media storage, and optionally a Traversal Using Relays around NAT (TURN) server for reliable voice and video connectivity.

Synapse supports SQLite for simple installations, but PostgreSQL should be considered the standard choice for production systems. PostgreSQL becomes particularly important when the installation grows, and it is required when Synapse is scaled using multiple worker processes.

A reverse proxy such as NGINX, Caddy, Apache, or HAProxy is normally placed in front of Synapse. It terminates TLS and exposes the Matrix client and federation endpoints over standard HTTPS ports while Synapse itself listens on an internal HTTP port.

Media also requires planning. Images, videos, voice messages, documents, and other uploaded content are stored separately from the PostgreSQL database. Administrators therefore need backups for both the database and the media store. Backing up only PostgreSQL is not sufficient for a complete restore.

Authentication and User Management

Synapse can maintain its own users and passwords, but organizations will often want to integrate it with an existing identity provider. Depending on the environment, Synapse can work with authentication mechanisms such as OpenID Connect and Security Assertion Markup Language (SAML), allowing users to sign in through an existing identity platform.

Registration should be configured carefully. An Internet-facing homeserver should generally not allow unrestricted account registration unless that is an intentional part of the service. Administrators can instead create accounts themselves, use controlled registration mechanisms, or rely on an external identity provider.

The server configuration also contains sensitive values such as registration secrets and signing keys. These should be treated like other infrastructure credentials and included in the backup and secret-management strategy.

Scaling with Workers

For a small or medium Matrix installation, Synapse should normally start as a single process. There is no official capacity limit expressed as a specific number of users or events per second because Matrix workloads vary considerably: 500 mostly idle users in small private rooms create a very different load from 500 users participating in large federated rooms. As a practical rule of thumb, a well-sized single Synapse process with PostgreSQL can comfortably serve a few hundred active users, and installations with around 1,000 registered users may still have no reason to introduce workers if concurrency and federation traffic are modest.

Worker scaling is worth considering when the main Synapse process regularly approaches 100 percent of one CPU core, /sync requests become noticeably slower, federation queues start falling behind, or message delivery latency increases under normal peak load. Synapse is largely divided into specialized workloads, so the first step is often not to create multiple identical instances but to move expensive functions such as client synchronization, federation handling, media processing, background jobs, or event persistence into dedicated workers. At a larger scale, event persisters can also be sharded by room ID across multiple workers.

A reasonable planning model is therefore to keep installations with tens or a few hundred active users on the simpler monolithic architecture and monitor them before adding complexity. Once an installation reaches several hundred concurrently active users, sustained request rates in the hundreds per second, or CPU saturation on the main process, workers become increasingly worthwhile. Very large deployments with thousands of simultaneously active users should generally be designed around multiple workers from the outset. All workers still share PostgreSQL and communicate through Synapse's replication mechanisms, typically using Redis, so scaling Synapse horizontally does not remove the need for a properly sized database.

For a dedicated Synapse server, a small installation does not need particularly large hardware. A homeserver for a small company, family, or community can comfortably start with 2-4 modern CPU cores, 4-8GiB of RAM, and roughly 100-250GB of SSD or NVMe storage, assuming moderate federation and media usage. A medium installation with several hundred active users, larger federated rooms, or initial worker processes is better served by around 6-12 cores, 32-64GiB RAM, and 500GB-1TB of NVMe storage. For a large installation with thousands of active users and multiple Synapse workers, 16-32 cores, 64-128GiB RAM, and 1-4TB of fast NVMe storage provide a reasonable starting point. At that scale, however, separating PostgreSQL, Synapse workers, and media storage across multiple systems usually becomes more useful than continuing to scale a single server vertically. In all cases, fast SSD storage is more important than large amounts of slow disk capacity because PostgreSQL performance has a major impact on Synapse responsiveness.

Security and End-to-End Encryption

Matrix supports end-to-end encryption for private conversations and rooms. In an encrypted room, message contents are encrypted by clients before they reach Synapse, meaning the homeserver stores and forwards encrypted events rather than plaintext message content.

This is an important distinction when self-hosting. Operating your own Synapse server gives you control over account data, room metadata, media, infrastructure, and retention, but end-to-end encryption still depends primarily on the Matrix clients and their key management.

The homeserver itself remains security-critical. Administrators should keep Synapse and PostgreSQL updated, restrict administrative APIs, protect registration mechanisms, use HTTPS, back up signing keys, and avoid exposing internal services directly to the Internet.

Review & Outlook

Synapse is the most mature choice for organizations that want to operate their own Matrix homeserver. Its biggest strengths are compatibility with the Matrix ecosystem, federation, support for end-to-end encrypted communication, mature administration features, and the ability to scale from a small single-server installation to much larger deployments.

The tradeoff is complexity. A serious installation involves more than simply starting a chat container: PostgreSQL, DNS, TLS, federation, media storage, backups, identity management, and optionally TURN infrastructure all need to be considered.

All in all, Synapse is a strong fit for teams that want control over their communication infrastructure without creating another isolated messaging island. For self-hosters willing to operate the supporting infrastructure, Matrix and Synapse offer a compelling alternative to centralized communication platforms.