Which Matrix homeserver fits your rollout
Choose Synapse if you need the widest documentation, the most established scaling path and a vendor with commercial options. Synapse is developed by Element and distributed under AGPL-3.0, and its current release line is documented in detail in the Synapse documentation. Its production guidance recommends PostgreSQL, and its worker model relies on Redis to relay replication between processes, so a Synapse rollout is also a database and cache operations commitment. Dendrite fits only a narrower case: Element has placed it in maintenance mode with security fixes only, and its README describes it as beta software for homeservers of tens or hundreds of users with no high availability or clustering. Accept those limits only if the user base is small and stable and you are comfortable with a server that will not gain new features.
Tuwunel and Continuwuity are Apache-2.0 Rust homeservers, and Tuwunel's README states that migration from Synapse is not yet possible, so they are a fresh-start decision rather than a drop-in replacement for an existing Synapse estate. Before you adopt either, confirm production fit against the current docs for the exact version you plan to run, including whether it is supported for your scale and what its upgrade and backup path looks like. For all three options, confirm Element X support for your chosen version directly with the project, and confirm the scaling story (worker support, database options and high availability) in that version's documentation rather than in older blog posts. Check identity integration too: Synapse documents OIDC, SAML2 and CAS single sign-on, and any alternative must be verified for the same features.
Before you commit, run a short proof of concept with your real federation settings. Decide whether federation is needed at all, since federation_domain_whitelist can restrict federation to listed domains or disable it entirely, and confirm the federation listener is firewalled as the Synapse documentation recommends. Then price the operating effort: ask any implementation partner to quote the database, Redis, reverse proxy, backup and upgrade work in writing, and plan for the fact that Synapse upgrades can be difficult to roll back because of schema changes. Treat the choice of homeserver as the decision that is hardest to reverse, and document the exit path before go-live.
Which Matrix homeserver fits each scenario
This table matches six common Matrix rollout scenarios to the homeserver that fits each one, based on maintenance status, scaling, database options and licensing. Read each row with its condition in mind, since the right choice depends on your user count, federation needs and licensing position. Rows marked Confirm depend on capabilities you should verify with the vendor or in your own test environment before you commit.
| Scenario | Best fit | Why |
|---|---|---|
| Small team of tens or hundreds of users | Synapse on PostgreSQL | Actively maintained and widely documented. Dendrite's README targets this size, but Dendrite receives only security fixes. |
| Large federated deployment needing workers | Synapse with workers and Redis | Redis relays replication between the main process and workers. Dendrite's README lists no clustering or high availability. Confirm sizing with load tests. |
| Air-gapped or internal-only, no federation | Synapse with federation disabled | An empty federation_domain_whitelist disables federation, and the docs advise firewalling the federation listener. Confirm the equivalent on Tuwunel or Continuwuity. |
| Team migrating from Conduit or conduwuit | Tuwunel | Migrates Conduit and conduwuit RocksDB databases in place on first boot. Synapse migration is not yet possible. Confirm Continuwuity's migration path with its maintainers. |
| Team that must avoid AGPL obligations | Tuwunel or Continuwuity | Both are Apache-2.0, while Synapse and Dendrite are AGPL-3.0-or-later. Confirm with counsel which AGPL obligations apply to your use. |
| Team that wants Element commercial support | Synapse with Element commercial licensing | Element sells Synapse Pro and AGPL exceptions. Confirm support scope, response terms and pricing directly with Element. |
How Synapse scales with workers and Redis
Synapse scales by splitting its single main process into worker processes, and the decision a team faces is whether the operating effort of that split is justified by its load. The main process and every worker connect to Redis, which relays replication between them, while the generic worker type handles client, federation and event traffic. Before choosing this layout, confirm with Element's Synapse workers documentation which worker types your traffic pattern needs and how many of each you intend to run.
A worker deployment needs more than an extra process. The team must provide PostgreSQL, which the Synapse documentation recommends for production, along with a Redis instance, a reverse proxy that routes client and federation paths to the right workers, and a federation listener. Federation runs on port 8448 by default, so either that port must be open and routed to the federation listener, or delegation must serve the server name from another host on port 443. The server_name setting fixes how user and room identifiers are written, so it must be settled before the first user joins. Plan the ports, DNS records and certificates before the configuration work begins.
This layer adds operating effort compared with a single-process install. Each added component needs monitoring, upgrades that track Synapse's release notes, and a rollback plan, since the upgrade notes warn that rolling back can be difficult because of schema changes. Dendrite is a useful reference point here: its README describes it as beta software for small homeservers of tens or hundreds of users, with no high availability or clustering support. If your requirement includes clustering or high availability, ask each vendor or project to confirm it in writing against your own load test rather than assuming it from the architecture.
Matrix homeserver capabilities side by side
This table compares the three homeservers named in the topic, plus Continuwuity, on the capabilities that decide a Matrix rollout: language, license, maintenance, scaling, databases, single sign-on, federation controls and migration. Read the rows with a clear question in mind, and treat every confirm cell as a point to verify with the vendor or in a test deployment before you commit.
| Capability | Synapse | Dendrite | Tuwunel | Continuwuity |
|---|---|---|---|---|
| Language | Python | Go | Rust | Rust |
| License | AGPL-3.0-or-later, with commercial licenses available from Element | AGPL-3.0-or-later | Apache-2.0 | Apache-2.0 as listed by Matrix.org |
| Maintenance status | Actively released; v1.163.0 published October 14, 2026 | Maintenance mode, security fixes only | Presented as the official successor to conduwuit; confirm current release cadence | Confirm current release status and maintainer activity |
| Scaling model | Worker processes coordinated through Redis | Confirm; the README describes small homeservers only | Confirm scaling approach with the project | Confirm scaling approach with the project |
| High availability | Possible through the worker model; confirm the design with Element documentation | No high availability or clustering support | Confirm | Confirm |
| Database options | PostgreSQL recommended for production; SQLite supported | PostgreSQL recommended | Confirm supported backends with the project | Confirm supported backends with the project |
| SSO (OIDC, SAML2, CAS) | OIDC, SAML2 and CAS supported | Confirm | Confirm | Confirm |
| Federation controls | Domain allowlist, delegation and server_name settings; federation can be disabled | Confirm | Confirm | Confirm |
| Migration path in | Native deployment; migration from other servers depends on the source | Confirm | Migrates Conduit and conduwuit RocksDB databases in place; Synapse migration not yet possible | Confirm migration sources with the project |
| Element X support | Confirm with Element for the current release | Confirm with Element | Confirm | Confirm |
Each homeserver in brief, with its license
Matrix homeservers differ less in protocol support than in who maintains them, what language they are written in and how far their licenses and maturity match your rollout. The four cards below set out each option's language, license as listed by Matrix.org, maintenance signal and the condition under which it is the right pick.
Synapse
Synapse is the most widely documented Matrix homeserver, written in Python and developed by Element under AGPL-3.0, with commercial licenses also available from Element. Its latest release listed in the supplied facts is v1.163.0, published October 14, 2026. Choose it when you need scaling through worker processes backed by Redis and PostgreSQL, and when you expect to follow upstream upgrade notes closely. Check the Python and PostgreSQL minimums before each upgrade, and plan rollbacks carefully because schema changes can make them difficult.
Dendrite
Dendrite is Element's Go homeserver under AGPL-3.0, and it is in maintenance mode with only security fixes applied. Its README calls it beta software suited to small homeservers of tens or hundreds of users, with no high availability or clustering support and PostgreSQL recommended. It fits a small, lean deployment that accepts a narrow scope and a frozen feature set. Confirm the current maintenance status in the repository before you commit, because a security-only mode limits future work.
Tuwunel
Tuwunel is an Apache-2.0 homeserver written entirely in Rust. It presents itself as an alternative to Synapse and as the official successor to conduwuit, and it is primarily sponsored by the government of Switzerland. It migrates Conduit and conduwuit RocksDB databases in place on first boot, but migration from Synapse is not yet possible, so it suits new deployments or existing Conduit-family servers. Do not treat it as production-ready on the strength of this card. Check its release history, open issues and federation test results in the repository before you rely on it.
Continuwuity
Continuwuity is a Rust fork in the Conduit line, listed by Matrix.org alongside Tuwunel under Apache-2.0. Matrix.org groups it with Conduit and Tuwunel as lightweight alternatives to Synapse, so the choice here is about lineage and community direction rather than a settled production record. Verify its license file, recent commits, release tags and migration path in its repository. Confirm that its database and federation behavior match your requirements in a test environment before any user onboarding.
Migration paths from Conduit, conduwuit and Synapse
Tuwunel is designed to pick up existing data from the Conduit and conduwuit family. According to its README, it migrates Conduit and conduwuit RocksDB databases in place on first boot, so you do not export and reimport rooms and users. In-place migration is convenient but changes the only copy of your data unless you keep a backup, so treat the first boot as a one-way step for your current database.
- Test on a copy: Start Tuwunel against a copy of the RocksDB directory on a separate host before touching production, and confirm that users, rooms and media load as expected.
- Keep a restorable backup: Snapshot the database and configuration before the first boot, and confirm you can restore them if the migration fails.
- Check the server name: Keep the same
server_nameso existing user IDs and room identifiers remain valid for your community. - Review federation settings: Confirm which remote servers can still reach you after the switch, and whether your reverse proxy and DNS delegation still point to the right listener.
- Confirm client support: Test the clients your users rely on against the migrated server before you announce the cutover.
Before committing, ask your DeployOpen contact or the Tuwunel maintainers to confirm which Conduit or conduwuit versions are supported for the in-place path, since that boundary is not set out in the facts used for this page.
Migration from Synapse to Tuwunel is not yet possible, according to Tuwunel's README. If your rollout already runs on Synapse, a move to Tuwunel is not a supported in-place path today, so plan around that constraint instead of assuming a later release will close it. Any change of Matrix server also touches identity, because user IDs and room IDs are tied to the domain your server presents.
- No Synapse import path: Do not plan a Tuwunel cutover that depends on reading Synapse's PostgreSQL or SQLite data directly.
- server_name is identity: Changing the
server_namefixes a new identity for every user, so existing accounts such as @user:example.com do not carry over. - Federation identity: Remote servers and rooms reference your old domain, so moving servers affects federation history and delegation.
- Single sign-on: If you use OIDC, SAML2 or CAS with Synapse, confirm how identity mapping will work on the new server before users migrate.
- Stay on Synapse for now: If Synapse is working for you, keeping it is the lower-risk path until a supported move exists.
Before planning any move off Synapse, ask Element and the Tuwunel maintainers to confirm the current migration status in writing.
A new rollout has no existing data to carry over, so the main risks are about how you upgrade and roll back later. Synapse's upgrade notes are the most relevant reference because they describe how schema changes affect rollback, and they warn about Python and PostgreSQL support windows. Choose your database and runtime versions with those warnings in mind from the first day.
- Plan for rollback limits: Synapse's upgrade notes warn that rolling back can be difficult because of database schema changes between releases, so take a database backup before every upgrade.
- Track runtime support: Synapse drops support for Python and PostgreSQL versions once upstream support ends, so record the minimum versions for each release you intend to run.
- Set server_name early: Choose the final domain before any user registers, since changing it later creates new identities.
- Decide on federation: Use the federation domain whitelist if you need a closed deployment, and firewall the federation listener as the Synapse documentation recommends.
- Pick identity integration first: Confirm whether you need OIDC, SAML2 or CAS before onboarding users.
Before you commit, ask your implementation partner to document the upgrade and rollback procedure for the server you choose.
Database and login choices that shape the rollout
The database is the first decision that shapes a Matrix rollout, and it is hard to reverse. Synapse recommends PostgreSQL for production, with SQLite also supported, and Dendrite recommends PostgreSQL as well. The database choice drives your backup routine, your restore testing and your upgrade windows, so decide it before the first user is created. Synapse 1.143.0 and later require PostgreSQL 14 or newer, and 1.142.0 and later require Python 3.10 or newer. Check these floors against your operating system packages before you schedule an upgrade, because the Synapse upgrade notes say it drops support for Python and PostgreSQL versions once they reach upstream end of life. Tuwunel uses RocksDB for the Conduit lineage, and it migrates Conduit and conduwuit RocksDB databases in place on first boot, but the README says migration from Synapse is not yet possible. Confirm the database engine for Continuwuity with its maintainers before you assume a migration path exists.
Plan for rollback before you upgrade Synapse. The upgrade notes warn that rolling back can be difficult because schema changes land between releases. Practically, that means taking a full database backup and a test restore before each version change, and keeping the previous Synapse package available for the window in which you might need it. Treat a failed upgrade as a restore exercise, not a downgrade. If you run Synapse with workers, every worker must move to the same release, which adds coordination to the same change window.
Login is the second decision. Synapse supports single sign-on through OpenID Connect providers configured under oidc_providers, SAML2 through saml2_config using pysaml2, and CAS. If you need a broker in front of several identity providers, the Matrix Authentication Service documentation describes how it can connect to upstream identity providers. Map your directory and multi-factor requirements to the protocol each candidate supports, and confirm the login options for Dendrite, Tuwunel and Continuwuity directly with their documentation, since this topic's supplied facts do not establish them. Ask the identity team which protocol they will operate for the next five years, not only for the pilot.
How to choose and pilot a homeserver
This sequence moves a team from requirements to a tested, reversible Matrix homeserver choice, with each step producing a written decision or check that the next step depends on.
Define users, federation and data residency
Product owners and the IT lead write down the expected user count, whether the deployment must federate with other Matrix servers or stay closed, which domains must be allowed or blocked, and where message and media data may be stored. Federation choices determine the server_name, the delegation setup and whether federation_domain_whitelist will be used, so they must be settled first. The step closes when the team signs a one-page requirements note that names each constraint and its owner.
Confirm license obligations with legal
Legal counsel and the CISO review the license of each candidate: Synapse and Dendrite are AGPL-3.0 family licenses, while Tuwunel and Continuwuity are Apache-2.0. Ask whether the organization will modify the server and offer changed source to users over a network, and whether Element's commercial terms for Synapse are needed. Confirm the terms directly with the vendor or license holder, since the license is only one input. The step closes with a written license position for each candidate.
Check maintenance status and latest releases
The platform engineering lead opens the release page of each candidate repository and records the latest published version, its date, and whether the project describes itself as maintained, in maintenance mode or in beta. Dendrite's README describes maintenance mode with only security fixes, and its own README positions it for small homeservers without high availability, so that status must be weighed against the requirements from step one. The step closes with a dated comparison table that the security and operations teams both review.
Test identity provider and Element X on staging
The identity lead connects a staging homeserver to the organization's identity provider, using the OIDC, SAML2 or CAS options the candidate supports, and the client team signs in with Element X on managed and personal devices. Confirm which SSO path the candidate supports, how user provisioning and deactivation behave, and whether Element X works fully with that server. Record every login, logout and account-removal result. The step closes when a test user can sign in, sign out and be deactivated without manual database work.
Run a pilot with realistic message and media load
The platform team, with a small group of business users, runs the candidate on the database engine the production design will use, with message volume, room count and file uploads modeled on the expected peak. Watch database growth, media storage, memory use, and whether federation traffic behaves as expected if it is enabled. Ask the vendor or community which scaling approach fits the expected load, such as Synapse workers with Redis, before deciding. The step closes with a load report that states what was tested, what was not, and any gaps that block go-live.
Record upgrade and rollback steps before go-live
The operations lead writes the upgrade procedure, the backup and restore steps, and the rollback plan for the chosen server, including the database version requirements of the target release. Synapse's upgrade notes warn that rolling back can be difficult because of schema changes, so the team must confirm whether restoring a pre-upgrade backup is the only safe rollback. The security lead signs off that the runbook covers the federation listener and firewall settings. The step closes when a second engineer has walked through the runbook on staging and the signed document is stored with the platform records.
What buyers ask before running a Matrix homeserver
What does a Matrix homeserver rollout cost and what drives it?
The server software is open source for all three options, so licence fees are usually not the largest line item. Synapse is AGPL-3.0, Dendrite is AGPL-3.0 and Tuwunel is Apache-2.0, and Element also sells commercial Synapse licences if you need them. The recurring costs are hosting, a PostgreSQL database, reverse proxy and TLS certificates, backups, monitoring and staff time for upgrades. Synapse workers add Redis and more processes to run. Expect a one-time implementation quote plus ongoing operations. DeployOpen does not publish a price list, so ask for a written quote that lists hosting assumptions, database sizing, identity integration, testing, support hours and whether any Element commercial licence is included.
How long does a Matrix rollout take and what changes the timeline?
No single duration fits every rollout, so the timeline follows the scope you agree. The main drivers are identity integration, since Synapse supports OpenID Connect, SAML2 and CAS single sign-on, your federation policy, whether you need workers and Redis for scale, the bridges you want, the client and mobile testing your users require, and how many environments you need for staging and upgrade rehearsal. Federation adds its own work, including port 8448 or delegation to port 443. The server_name setting also fixes how users and rooms are identified, so settle it before anything goes live. Ask for a schedule tied to named deliverables and a written acceptance test list before work starts.
Can our own team run a Matrix homeserver without outside help?
Yes, if your team already runs PostgreSQL, a TLS reverse proxy, Linux service management and staged upgrades. Synapse is the most widely documented option and recommends PostgreSQL for production, although SQLite is also supported. Upgrades need care. Synapse's upgrade notes warn that rolling back can be difficult because of database schema changes between releases, and Synapse drops support for Python and PostgreSQL versions once they reach upstream end of life. Synapse workers add complexity, because the main process and every worker connect to Redis and traffic must reach the right worker types. Be honest about on-call coverage. DeployOpen can plan, implement, harden, back up and document a self-hosted deployment, and it offers ongoing support and upgrades as retainers.
Which Matrix homeserver supports Element X?
Confirm Element X compatibility for your exact server and client versions before you commit. Client support depends on which server features each version implements, and that changes between releases. Ask Element and each server project which versions your Element X build has been tested against, and request that answer in writing. Synapse is developed by Element and is the most widely documented server, so it is the natural first check. Test Dendrite and Tuwunel with the exact client build your users will install, covering sign-in, room features, encryption and push notifications, before any pilot begins. Record the results so your team can repeat the check before each client or server upgrade.
Is Dendrite safe to run in production?
For most production plans, Dendrite is a weak choice. Element's Dendrite is in maintenance mode, and only security fixes are applied, according to its README. The same README calls it beta software suited to small homeservers of tens or hundreds of users, with no high availability or clustering support, and it recommends PostgreSQL. A private pilot for a small group may be reasonable if you accept that features will not be added and you document an exit plan. If you expect growth, clustering or larger federation, compare Synapse, which scales with worker processes. Ask any implementer and vendor to confirm the support window and security patch process in writing before you decide.
Can we move from Synapse to Tuwunel later?
Not directly from Synapse today. Tuwunel's README says it migrates Conduit and conduwuit RocksDB databases in place on first boot, but migration from Synapse is not yet possible. A move from Synapse to Tuwunel is therefore a rebuild, with user accounts, room history, media and DNS changes planned separately. Before choosing Tuwunel for a rollout that may need to move, confirm the current migration status with the project and test an export of your data. Ask your implementer for a documented exit plan that covers identities, room history, media storage, backups and the federation changes users would notice. Making that plan early costs far less than making it during an incident.
What does a fixed-scope Matrix engagement include?
A fixed-scope engagement covers the work written into the agreed scope, and the scope, deliverables and timeline are agreed in writing before work starts. For a Matrix rollout, that can include the homeserver you select, database and reverse proxy setup, identity integration, federation policy, backup and recovery, hardening, client testing and documentation for your operators. Work outside the written scope, such as additional bridges or a later migration, would need a written change to scope and quote. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted platforms inside your own infrastructure. Ongoing support and upgrades are available as retainers. DeployOpen does not issue audit reports or certifications.
How DeployOpen scopes a Matrix homeserver selection
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including the homeserver behind a Matrix rollout. We start from the team's federation, identity and database requirements, then agree the scope in writing before any work begins.
How we scope
- Confirm whether the rollout needs federation with other servers or must stay closed to listed domains.
- Record identity requirements, such as OpenID Connect, SAML 2.0 or CAS single sign-on, before choosing a server.
- Agree in writing which homeserver, database and Element X client support the deployment will use.
How we build
- Deploy the chosen homeserver inside your cloud account, data center or air-gapped network.
- Configure the database, reverse proxy, federation listener and firewall rules to match the agreed scope.
- Test client login, federation behavior and single sign-on flows against the written acceptance criteria.
How we hand over
- Document server_name, delegation, configuration and upgrade steps so your own staff can operate the service.
- Set up backup and restore procedures and rehearse a restore before handover is signed off.
- Provide a runbook that records the version in use and the checks to run before any homeserver upgrade.
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous security testing are available as retainers.
- Ask for a written quote that lists scope, deliverables and the support terms that apply after handover.
