Matrix high availability guide

Matrix high availability starts with knowing which component failure you must survive

High availability is about surviving the failure of individual components, not about running extra copies of the same thing. For an internal messaging service that staff depend on during the working day, the first decision is not how many Synapse processes to start. It is which failures the service must continue through, how long users can tolerate an interruption, and who is responsible when one of those failures happens at 2 a.m. A team considering a clustered Synapse deployment should write that list before choosing any architecture, because each entry leads to a different set of controls.

Synapse scales horizontally through worker processes. The main process and all workers connect to Redis, which relays replication traffic between them, and the generic worker type handles client, federation and event traffic. That design means the homeserver is not one box, and the pieces fail differently. PostgreSQL holds the room and user state and needs its own replication, failover and backup plan. Media storage holds uploaded files, so losing it damages content even when messages keep flowing. The load balancer is a separate point of failure that can take down every client path at once. Redis is also a dependency that the team must monitor, because replication stops when it does. Each of these needs a named owner, a health check and a tested recovery path.

Three factors make this harder than it looks. First, a single main process still carries coordination duties, so adding workers does not remove it from the critical path. Confirm with the Synapse workers documentation how the main process is handled during failover and which tasks cannot yet be moved off it in your release. Second, database schema changes between Synapse releases can make rollback difficult, as the upgrade notes warn. A failed upgrade may therefore need a restore from backup rather than a return to the previous binary, which changes how long recovery takes. Third, a clustered setup adds operational work: more processes to deploy, more configuration to keep consistent across workers, more dashboards and more on-call situations to rehearse. Ask who will carry that work after launch and how much time they can give it.

Before reading further, decide which failures are in scope for your first release: loss of one worker, loss of the main process, database failover, loss of a media store, a load balancer outage, or a full site or cloud region outage. Write the recovery time and data loss tolerance you expect for each, and mark any you cannot yet support. This list drives the rest of the planning and gives you a basis for comparing vendor and partner proposals.

This page does not replace the implementation plan, the upgrade process or the security hardening topics. It assumes you have already chosen a homeserver and a hosting model, and it does not cover how to deploy the chosen platform, how to keep it patched, or how to restrict its exposure. Use those topics for those decisions, and return here to confirm that the availability design matches the failures you have agreed to survive.

Which Synapse processes and services make up a Matrix high availability setup

A high availability Synapse deployment splits one homeserver into several processes and supporting services, each of which can fail on its own. The cards below cover the main process, workers, Redis, PostgreSQL, media storage and the routing layer, with what each depends on and what users experience when it stops.

Main process

The main process handles work that must happen in one place, such as certain background tasks and coordination for the rest of the homeserver. Every worker connects to it through Redis, so its health affects the whole deployment. When it fails, users may see sends or syncs stall even though other processes are still running. Confirm which tasks remain on the main process for your release in the Synapse workers documentation before you size it.

Worker processes

Workers are separate Synapse processes that take over part of the request load, so the homeserver can run more than one instance of a given role. Each worker depends on the shared database, Redis and the same configuration as the main process. If a single worker fails, requests routed to it fail until traffic is moved elsewhere or the worker restarts. Confirm the worker types and their routing rules against the Synapse workers documentation for the release you run.

Generic worker for client and federation traffic

The generic worker handles client, federation and event traffic, and it is the worker type most deployments scale first. Running two or more of them lets one instance fail without taking client sync away from users. It depends on Redis for replication and on PostgreSQL for all stored state. Test client sync and federation inbound traffic separately during failover drills, because a failure can affect one path and not the other.

Redis for inter-process replication

Redis relays replication between the main process and workers, so it carries the event stream that keeps processes in step. Every process depends on it, which makes Redis a shared point of failure unless it is deployed with its own redundancy. When Redis is unavailable, workers can stop receiving updates and users may see delayed or missing events. Ask your team how Redis failover is handled and how it reconnects after a restart.

PostgreSQL database

PostgreSQL stores room state, events, accounts and most other homeserver data, so it is the source of truth for every process. Synapse documentation recommends PostgreSQL for production, and recent releases require PostgreSQL 14 or newer. High availability here depends on replication, failover and tested backups, not on the homeserver processes themselves. Confirm the replication and restore design with your database team before the first release upgrade.

Media storage

Media storage holds uploaded files, images and voice messages that users retrieve through the homeserver. Every process that serves media must read from the same storage location, so an unavailable store breaks downloads and uploads even when messaging still works. Check that the storage layer is replicated or backed up separately from the database, because a database restore alone will not recover media. Confirm how your chosen storage backend is configured for workers in the current Synapse documentation.

Reverse proxy and load balancer

The reverse proxy or load balancer receives client and federation requests and routes each request type to the correct worker. Routing rules are specific to the endpoints each worker handles, so an incorrect rule can send requests to a process that cannot answer them. If this layer fails, users lose access to the homeserver regardless of how healthy the processes behind it are. Confirm the routing rules against the Synapse workers documentation for your release and test each route after every change.

Choosing a single-process, worker-based or multi-site Matrix layout

This table compares four ways to run Synapse, from a single process to a Kubernetes-hosted layout, against the fit conditions and operational costs of each. Read each row as a question to answer with your business owners before choosing, because user counts and uptime targets are set by your organization, not by the layout. The main takeaway is that every step up in availability adds components, Redis or replication to operate, and harder rollbacks.

Layout	When it fits	Operational cost	Confirm before choosing
Single Synapse process with PostgreSQL primary and backups	Small or moderate user base where short outages during restarts or upgrades are acceptable and a small team can run it	One process to patch and restart; recovery depends on restoring PostgreSQL backups and media storage; a host failure means downtime until restore	Acceptable outage window with business owners, tested restore time, and whether backups cover media files as well as the database
Worker-based cluster on one site with Redis and several workers	Larger user base or heavier federation and sync load, with a stated expectation of fewer restarts and staff who can run several services	Main process, workers, Redis and load balancer must all be patched and monitored; Redis becomes a dependency for replication between processes; upgrades need worker-aware testing	Whether the team can own Redis availability, and how worker configuration is versioned and tested after each Synapse release
Worker cluster with database replication across two sites	Organizations whose uptime expectations survive loss of one site or data center, and that can staff replication, failover and drills	Replication lag, failover runbooks and split-brain controls add work; two sites double much of the infrastructure; failover tests are needed on a schedule	Recovery objectives agreed with owners, network latency and bandwidth between sites, and where data may legally reside
Managed or Kubernetes-hosted layout (for example, Element Server Suite on Kubernetes with Helm charts)	Teams with existing Kubernetes operations skills or a requirement for declarative deployment and standard rollout tooling	Cluster operations, persistent volumes, ingress and Helm chart upgrades become part of the service; vendor support terms vary by edition	Who operates the cluster, which edition and support terms apply, and whether the chart pins the Synapse and worker versions you need
Rollback limits across all layouts	Applies to every option once a Synapse release changes the database schema	Upstream upgrade notes warn that rolling back can be difficult because of schema changes, so a failed upgrade may require restoring from backup	A tested restore procedure and a staging environment that mirrors production topology before each upgrade
Monitoring load	Grows with each layout step, from a single process to workers, Redis and a second site	More metrics, logs and alerts to correlate across processes, Redis and replication; alert fatigue is a common failure	Who receives alerts out of hours and which failure modes each layout is expected to detect

Why the main process and Redis still need a failure plan

The first question in a Synapse high availability design is not how many workers to add. It is what happens when the main process or Redis stops, because those two components sit on the path of every worker. In a worker deployment, the main process and all workers connect to Redis, and Redis relays replication between processes. Workers receive events, stream positions and cache invalidations through that channel, and the main process coordinates writes and replication. Losing either one affects the whole homeserver, even when every worker is still running. That is why these two components belong at the top of the failure plan. A worker outage is the easier case. If a generic worker or a specialized worker for sync, federation or media fails, the load balancer should stop routing requests to it, and the remaining workers of the same type should absorb the traffic. Users may see slower responses or retries for requests that were in flight, but the server stays available. Your test plan should stop one worker of each type under realistic load and record how long clients take to recover, how the load balancer detects the failure and whether federation traffic queues or fails. Confirm the health check endpoints and routing rules for your chosen release before you rely on this behavior.

A main process or Redis outage is a different category. Clients may still reach workers that are running, but replication and coordination stop, so messages can be delayed or rejected and some background processing halts. Recovery depends on how quickly the main process can restart, whether Redis data needs to survive the restart and whether the workers reconnect cleanly without a full restart of their own. Write down the expected behavior for each failure, including which users notice it first and which operations, such as room creation, sending messages or federated joins, are affected. Decide between three responses. A second Redis instance, a failover arrangement or a documented restart procedure each address a different risk. A restart procedure may be enough when your recovery objective allows a short, planned interruption and your team can restart both components quickly. A failover arrangement fits when the interruption must be short without manual steps, which means a standby Redis with automatic promotion and a tested reconnection path. A second Redis instance is a design choice that only helps if it is part of a failover or sharding plan. Ask your engineers which option their release and deployment mode support, and what each one costs in operations time. Confirm the supported modes before you commit. Redis deployment modes, failover behavior and the way Synapse reconnects after a Redis or main process restart change between releases. Check the Synapse release notes and workers documentation for the version you plan to run, and confirm the behavior in a staging environment built to match production. Record the result as a design decision, because it sets the monitoring, runbooks and budget for the rest of the high availability work.

Matrix high availability build sequence, from database to load balancer

This sequence takes a Synapse deployment from a confirmed release and a replicated database to a load-balanced, worker-based homeserver that a small test group has used through a component failure. Each step closes with a check the team can verify before moving on, so problems surface while the design is still easy to change.

Confirm release and runtime requirements
Choose the target Synapse release from the releases page, then read its upgrade notes for the minimum PostgreSQL and Python versions. Synapse 1.143.0 and later require PostgreSQL 14 or newer, and 1.142.0 and later require Python 3.10 or newer. Record the chosen version, database engine and Python runtime in a short design note that the platform, security and application owners all sign. Confirm the planned host images meet these minimums before anything is provisioned. The step is done when the note exists, every host image is confirmed against it, and the team has agreed that rolling back a release later may be difficult because of schema changes.
Stand up PostgreSQL with replication and backups
The database team builds a primary PostgreSQL instance on the approved version and adds at least one streaming replica on a separate host, using the database vendor's documented replication setup. Backups are configured on the primary and must include point-in-time recovery if your recovery objectives require it. Restore a backup to a separate host that is not part of the Synapse cluster, then confirm the restored copy starts and passes basic queries. The step is complete when the replica reports an active replication connection to the primary and a restore from backup succeeds on the separate host, with the restore time and steps written down for the runbook.
Configure Redis and connect the main process
Deploy Redis in a location reachable by the main process and every worker, and enable the Redis settings in the Synapse configuration. Redis relays replication traffic between processes, so it must be on the same trusted network segment and protected by authentication and network controls. Start the main process and review its logs for a successful connection to Redis. Confirm that the main process is the only process handling writes to the database and background tasks that must run once. The step is done when the logs show the main process connected to Redis without errors and a test message sent through the main process appears in a test room.
Define worker types and assign generic workers
Write a worker layout that names each process, its type and its listeners. The generic worker handles client, federation and event traffic, so the layout should start with generic workers and add specialized types only when load testing shows a need. Each worker gets its own configuration file, a replication listener, and a registration with the main process over Redis. Start one generic worker first and check that it registers with the main process. The step is complete when the worker appears as connected in the main process logs and a client sync request answered by that worker returns successfully.
Place the reverse proxy in front of workers
Configure the load balancer or reverse proxy to send client API paths, federation paths and media paths to the correct pools of workers or the media service. Federation traffic uses port 8448 by default, or port 443 when delegation is configured, so the proxy must listen on whichever port your federation design uses. Restrict the federation listener to the networks you intend to allow. The step is done when a client login completes through the load balancer and a federation request from a test server reaches a generic worker, with the proxy access logs showing each route taken.
Set server_name and delegation consistently
Set server_name once, because it fixes how user IDs such as @user:example.com and room identifiers are written and cannot be changed casually after users exist. Configure delegation so the domain in user IDs resolves to the host that serves federation, and make sure the well-known response, DNS records, certificates and proxy routes all agree on that host. If federation is restricted, set federation_domain_whitelist to the approved domains or an empty list to disable it. The step is complete when the well-known document returns the expected host, a request from outside your network reaches the federation listener on the intended port, and the documented whitelist behaves as your federation policy requires.
Run a staged test with a small group
Invite a small group of users, including at least one administrator, to use the cluster for normal messaging, file sharing and calls where those are in scope. During the test, stop one generic worker and one database replica in turn, and observe whether clients reconnect and messages continue to flow. Upload and download media to confirm the media path works end to end. Record every failure, its cause and the fix applied. The step is complete when the group completes login, messaging and media transfer during each induced failure, and the team has a written list of open issues to resolve before wider rollout.

How Matrix high availability differs on VMs, Kubernetes and air-gapped networks

On virtual machines or bare metal, you place each component on hosts you manage directly. The main process, generic workers, Redis, PostgreSQL and media storage are usually split across separate machines or availability zones so that losing one host does not stop messaging. Synapse's main process coordinates writes, while workers handle client, federation and event traffic, and Redis relays replication between them. Your team owns the operating system, patching, time sync and network rules for every node.

Points to plan:

Placement: run at least two generic worker hosts and keep Redis, PostgreSQL and media storage off the same host as the main process where your hardware allows.
Load balancer: route client traffic, federation on port 8448 or delegated port 443, and sync endpoints to the correct worker pools, with health checks per listener.
Upgrades: pin Synapse, Python and PostgreSQL versions per host and roll workers in a defined order, since schema changes can make rollback difficult.
Package sourcing: install from your OS package repository or a pinned upstream release, and record the exact version on each node.
Failover: confirm how PostgreSQL replicas are promoted and how media storage is shared or replicated between hosts.

Confirm with your infrastructure team which failover behavior you accept for each component before you size the hosts.

What drives Matrix high availability effort and cost

This table lists the factors that change how much work a highly available Matrix deployment takes, with one way to keep each driver under control. Read each row against your own user count, sites and compliance obligations, then ask for a quote built from a written scope rather than a generic estimate.

Driver	How it changes effort	One way to keep it down
Users and rooms	More active users and busy rooms raise event volume, worker count and database load, so scaling and tuning take more time to design and test.	Confirm expected peak concurrent users and the largest rooms before scoping, and size the first release for those numbers with a documented growth path.
Message and media volume	Heavy file sharing and media uploads increase storage growth, media worker load and backup size, and they add retention and cleanup decisions.	Set media size limits and a retention policy early, and agree which storage backend holds media before the load balancer design is fixed.
Worker types and instances	Each worker type (for example generic, federation sender or media) adds configuration, replication paths and monitoring targets that must be verified together.	Start with the smallest worker layout that meets measured load, and add worker types only when a specific bottleneck is observed.
PostgreSQL replication and backups	Streaming replicas, failover tooling and tested point-in-time recovery add build and drill work, and the schema changes between Synapse releases complicate restore planning.	Use a single, well-documented replication topology with scheduled restore tests, and ask the team to confirm the PostgreSQL version supported by the chosen Synapse release.
Redis topology	Workers depend on Redis for replication, so a single instance is a shared failure point, while a clustered or sentinel design adds operational steps.	Choose the simplest Redis layout that meets the availability target and document how workers reconnect after a Redis restart.
Number of sites	Multiple sites or data centers require cross-site database, media and DNS failover decisions, which multiply testing scenarios.	Limit the first release to the sites that must survive a failure, and define which site is authoritative for federation and DNS.
Identity integration (OIDC or MAS)	Connecting an upstream OpenID Connect provider through Matrix Authentication Service or Synapse OIDC settings adds claim mapping, token and session testing, and provisioning work, and SAML needs a bridge.	Standardize on one identity provider and one integration path, and confirm with the provider owner which claims and groups are available before design starts.
Monitoring and alerting needs	Per-worker metrics, replication lag, database health and media errors each need dashboards, thresholds and on-call runbooks, which grows with the number of components.	Agree a short list of service-level signals (message delivery, login success, database lag) and build alerts only for those first.
Compliance evidence requirements	Assessors may ask for configuration baselines, access logs, backup restore records and change history, which requires collecting and retaining evidence from every component.	Ask the assessor which evidence they expect and generate it from routine operations, such as automated backup logs and change records, instead of assembling it later.
Internal staff skills	Teams without experience in Synapse, PostgreSQL replication and load balancing need more vendor support, training and review cycles, while experienced teams carry more day-to-day operation.	Name an internal owner for each component and ask for a handover plan with runbooks, so operational knowledge stays inside your organization.

Securing replication, Redis, database and media paths in a clustered Synapse

In a clustered Synapse, the main process, workers, Redis, PostgreSQL and the media store exchange traffic that carries user data and credentials. Each of these paths needs its own network boundary, access rule and secret handling, because a single exposed component can expose the whole homeserver. The cards below cover the controls to decide and verify before the cluster takes production traffic.

Private network for Redis and PostgreSQL

Synapse workers depend on Redis to relay replication between the main process and each worker, and every worker reads and writes PostgreSQL. Bind both services to private addresses only, require authentication on each connection, and confirm that no security group or load balancer rule exposes their ports. Check the result from a host outside the cluster, not only from inside it.

Replication port access by host

Worker replication listeners accept connections from other cluster members, so they should not be reachable from client or federation networks. Restrict each replication port to the specific hosts that run the main process and workers, and document that list as part of the topology. Re-check the list whenever a worker is added, moved or replaced during scaling.

Federation listener firewalling

The federation listener, which defaults to port 8448, must match the federation policy you chose. If federation is limited to listed partner domains or disabled, block inbound traffic to that listener from the internet and allow only the expected peers. Confirm the policy and the firewall rule agree, since the Synapse configuration manual recommends firewalling the listener in addition to the domain setting.

Media storage access and permissions

Media files are shared by every worker that handles uploads and downloads, so the shared store needs one consistent access model. Grant each Synapse host only the read and write rights it needs on that store, separate the credentials used for media from those used for the database, and test that a worker can serve a file uploaded through a different worker. Ask your storage provider which access logs and object-level permissions are available.

Secrets for database and Redis credentials

Database passwords and the Redis password appear in Synapse configuration and in each worker's startup settings, so every copy of the configuration is a potential leak point. Keep these values in a secrets manager or an encrypted store, inject them at process start, and rotate them with a documented procedure that updates the main process and all workers in one change window. Avoid placing them in shared configuration files that are copied between hosts.

Admin API limited to internal routes

The Synapse admin API performs privileged actions such as user management and room administration, so it should never be reachable through the public load balancer. Configure the load balancer to route only the client, federation and media paths publicly, and serve admin endpoints on an internal address reachable from administrator networks. Test with a request from the public internet to confirm that admin paths return no usable response.

How to test that Matrix high availability works and fails safely

A Matrix high availability design is only proven when failures are triggered on purpose and checked against a written expected outcome. Before testing, agree on a pass or fail rule for each case, and run the tests on a staging copy that matches production in homeserver version, worker layout, Redis, PostgreSQL and media storage. Each test should name the component, the action, the expected safe behaviour, what test users see and what the on-call engineer does. Record the outcome as you go, not from memory afterwards. Start with worker restarts. Restart each worker type in turn while two test accounts exchange messages in a shared room, and confirm the worker list against your own configuration. Safe behaviour means no message is lost or duplicated, sending clients retry and deliver, and the restarted worker rejoins the load balancer routing without manual intervention. Users may see a short delay or a reconnecting indicator. On-call staff should watch replication and error logs during the restart and confirm the worker returns to normal traffic before closing the test.

Stop Redis next, because the main process and all workers depend on it to relay replication between processes. Expect real-time delivery to degrade. The safe outcome is that no events are silently dropped, clients show that sync is stalled instead of appearing healthy, and messages sent during the outage are delivered or clearly failed after Redis returns. Recovery should not require editing the database by hand. Confirm the exact client-side behaviour with the Synapse version you run, because it depends on the release. For PostgreSQL, restore a recent backup onto a separate host rather than repairing the live primary. Check that the restored server is PostgreSQL 14 or newer, that the homeserver starts with the same server_name, and that a test message written before the backup point is present. Ask your database administrator to confirm the recovery method and the data loss window. Document who can authorize a failover and how the homeserver configuration is pointed at the new host.

Remove one media storage path or node, then confirm uploads and downloads. Uploads should fail with a clear error and never report success for a file that was not stored. Existing media should either load or fail cleanly, and the on-call team should know which media paths are affected from logs or monitoring. Then simulate load balancer node loss. Traffic should move to the remaining node, health checks should remove the failed node, and clients should reconnect without signing in again. If you federate on port 8448, test that the federation listener also fails over, because it is a separate path from client traffic. Rehearse a rollback before any production upgrade. The Synapse upgrade notes warn that rolling back can be difficult because database schema changes between releases may not reverse cleanly. Run the upgrade on a restored copy of production, then attempt the rollback. Identify the step that becomes a point of no return, and write the decision rule for when to stop and restore from backup instead.

Record every test as evidence. For each run, capture the test identifier, date, Synapse version, configuration reference, operator, expected result, observed result, relevant logs or screenshots, pass or fail status, and the fix applied to any failure. Keep these records with the runbook so the on-call team can repeat tests after changes. This evidence helps your internal assurance work and any later compliance assessment, but DeployOpen prepares systems and records only. Independent auditors and certification bodies decide whether controls meet a standard.

What to monitor, back up, upgrade and document after a Matrix HA deployment

A highly available Synapse deployment keeps messaging running only if someone watches its moving parts, restores data on purpose, upgrades in controlled stages and writes down how it behaves. The cards below cover the checks, backups, upgrade work and documentation that connect the main process, workers, Redis, PostgreSQL, media storage and the load balancer after go-live.

Process and worker health

Track whether the main process and each worker type are running, restarting or failing health checks. Synapse exposes metrics you can scrape, and the set of worker types in your configuration determines which processes must be watched. Confirm exact metric names and health endpoints against the Synapse documentation for your release before building alerts.

Replication lag and Redis connectivity

Redis relays replication between the main process and workers, so lag or dropped connections show up as delayed events and stalled client sync. Alert on replication stream lag and on Redis reachability from every Synapse process. Confirm the replication metrics available in your release and the Redis settings your workers use.

PostgreSQL health and replication

The database is the single source of truth for rooms, events and accounts, so its failover behavior matters as much as Synapse itself. Monitor connection counts, replication state, disk growth and long-running queries on the primary and standbys. Confirm the connection pool sizing and failover tooling your team uses with your Synapse version.

Media storage capacity

Uploaded files and cached remote media grow with use and are not covered by database backups alone. Watch free space and growth rate on the media store, and confirm that every Synapse process that serves media can reach the same storage. Decide retention for remote media early, because it drives storage cost and restore size.

Load balancer and listener health

The load balancer routes client, federation and media traffic to the right processes, so a misrouted path can look like a homeserver fault. Check backend health, certificate expiry, and that federation traffic reaches the federation listener on the port you configured, whether 8448 or delegated port 443. Verify routing with test requests after every change.

PostgreSQL and media backups with restore tests

Back up PostgreSQL and the media store together on a schedule that matches your recovery expectations, and keep the two backups from the same point in time where possible. A backup only counts once a restore has been performed into a separate environment and Synapse has started against it. Record the date, scope and result of each restore test.

Staged upgrades and rollback planning

Follow Synapse release notes for every version you skip, and track Python and PostgreSQL end-of-life dates, since Synapse drops support when upstream support ends. Roll out to workers in stages, and plan rollback before starting because schema changes can make it difficult. Confirm the minimum Python and PostgreSQL versions required by your target release.

Architecture, runbooks and owners

Keep an architecture diagram showing the main process, workers, Redis, PostgreSQL primary and standbys, media storage and load balancer, with named owners for each component. Write runbooks for failover steps, worker restarts and restore procedures, and keep dated test records showing each runbook was exercised. Review them after every upgrade.

How much effort does Matrix high availability take, and what does it need from our team?

What drives the effort of a Matrix high availability setup?

The main drivers are how many components must survive a failure, how many users and rooms the server carries, and how much of the stack your team already runs. A high availability design usually touches the main process, Redis, worker processes, PostgreSQL replication and backups, media storage and the load balancer, and each one adds configuration, testing and failure scenarios.

Scope drivers: the number of workers, whether federation is open (which changes inbound traffic), whether media must stay available when a node fails, and how many failover scenarios must be tested.

Cost drivers: hosting in your own accounts or data centers, staff time for design and testing, and ongoing upkeep. Ask any partner to show how each driver maps to a line in the written scope.

Is Matrix high availability a one-time or recurring cost?

Most of the design, build and verification work is one-time, while infrastructure, patching and upgrade testing recur.

One-time: architecture decisions, worker layout, Redis and PostgreSQL replication setup, load balancer and media storage configuration, backup and restore testing, and documentation.

Recurring: redundant hosting, storage growth for PostgreSQL and media, any commercial license you choose, and staff time for Synapse upgrades. The Synapse upgrade notes warn that rolling back can be difficult because of database schema changes, so each upgrade should be rehearsed on a copy of production. Confirm current license terms with the vendor before you budget.

Can our internal team build Matrix high availability on its own?

Yes, a team with solid Linux, PostgreSQL and load balancer experience can build it, but it needs more than one person who understands the stack. The work spans Synapse configuration, Redis, PostgreSQL replication, reverse proxy routing for worker endpoints and identity integration.

The most common weak point is untested failover. A cluster that has never lost a node in a rehearsal often fails in its first real incident. Single-person ownership is another risk, so plan cover, runbooks and cross-training from the start.

A partner is useful when the team lacks time or has not operated Synapse before. Teams that build alone should still schedule a restore test and a failover drill before go-live.

What skills and access does a Matrix worker cluster require?

The work needs Linux administration, PostgreSQL administration (including replication and point-in-time restore), Redis operations, reverse proxy and TLS configuration, and enough Python and Synapse familiarity to manage configuration and upgrades.

Access typically includes hosts or Kubernetes namespaces in your environment, database administrator rights for replication setup, DNS and certificate control for server names and delegation, firewall changes for the federation listener, and a secrets management path.

Confirm whether your environment is public cloud, a data center or air-gapped, because that determines which access and tooling are possible. Security reviewers should also get read access to logs and configuration so hardening can be checked.

How long does Matrix high availability take to deliver?

Duration depends on the written scope. The main variables are the number of workers, whether PostgreSQL and media storage must be redundant, how many environments you need (typically staging and production), identity integration, and how many failover scenarios must be proven.

DeployOpen works on fixed-scope engagements, where deliverables and timelines are agreed in writing before work starts, so the timeline follows from the scope. Ask for milestones such as design sign-off, staging build, failover tests, production cutover and handover.

Your own calendar, change windows, and the lead time for hardware or cloud accounts often set the real pace. Ask for a timeline tied to each milestone rather than a single end date.

Does a small Matrix deployment need a worker cluster?

Not always. Synapse can run with a single main process and no workers, which is simpler to operate and may be enough for smaller user counts. A worker cluster adds Redis, more processes and more failure modes, so it is justified when load or availability requirements call for it.

For a small team, start with what must survive: a host crash, a database failure, or loss of media storage. Some availability goals can be met with a standby database and tested backups before you add workers.

Ask a partner to model your user count and federation policy against the worker design, and check the approach against the Synapse workers documentation and your own load tests.

How does Element Server Suite compare with a self-built cluster?

Element Server Suite is a packaged deployment on Kubernetes using Helm charts. According to Element, it includes Synapse Pro, Matrix Authentication Service, LDAP and SCIM integration, and auditing. A self-built cluster uses the components you choose, so your team owns every design decision and its upkeep.

Licensing matters. ESS Community is free for non-professional deployments and evaluations, ESS Pro is for professional and government use, and ESS TI-Messenger is for German healthcare. Confirm which edition fits your organization.

Confirm with Element which parts of the database, media storage and failover design the package covers and which remain with your team, along with supported Kubernetes versions and how upgrades are handled.

What should we ask a partner to include in a Matrix high availability quote?

Ask for a written scope that lists each component, its redundancy design and the test that proves it. A useful quote covers:

Architecture and worker layout
Redis and PostgreSQL replication and backup design
Media storage and load balancer configuration
Identity integration and staging and production environments
Failover and restore test plans with expected results
Documentation, knowledge transfer and handover
Support or retainer options after go-live

Also ask who is responsible for each item, which access you must provide, which assumptions the price depends on, how change requests are priced, and which Synapse and PostgreSQL versions the design targets.

How DeployOpen works on this

DeployOpen scopes Matrix high availability as a written, fixed-scope engagement inside your own infrastructure. The work covers the Synapse worker layout, Redis, PostgreSQL replication, media storage and load balancing, then hands over documented, tested runbooks your team can operate.

How we scope

Confirm the homeserver implementation and whether Synapse runs on PostgreSQL with replicas and failover.
Map which worker types, Redis and main process functions your user count and federation policy require.
Agree in writing which failure cases, such as a lost worker or database node, must keep messaging working.

How we build

Deploy the main process, generic workers and Redis in your environment, with the load balancer routing client, federation and media traffic.
Configure PostgreSQL replication and backups, then test restore procedures against a recent copy of the data.
Test failover by stopping individual workers, Redis and database nodes, and record how clients and federation recover.

How we hand over

Deliver architecture diagrams, configuration files and a runbook describing each component and its failure behavior.
Walk your platform and security engineers through failover tests, restores and the upgrade order for workers.
Document the upgrade constraints, including schema changes that can make rollback difficult, so your team plans releases safely.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover dependency updates for Python and PostgreSQL, plus repeat failover and restore tests after changes.
Confirm with DeployOpen which support levels, response expectations and testing cadence are included in the quote.