When to choose Synapse or Tuwunel for your Matrix homeserver
Choose Synapse when your team needs the most documented path to a production Matrix homeserver. Element develops it under AGPL-3.0, its upgrade notes and configuration manual are the reference most administrators will search first, and it has the widest set of operating guidance: PostgreSQL is the recommended production database, workers scale it out through Redis replication, and single sign-on works through OpenID Connect (oidc_providers), SAML2 (saml2_config) or CAS. If your identity provider is one of those, Synapse is the lower-risk default. Plan for the upgrade notes too, since they warn that rolling back can be difficult because of schema changes between releases, so take a database backup before every upgrade.
Choose Tuwunel when you want an Apache-2.0 homeserver written in Rust and you can accept that it is a younger project with a narrower path in. It ships Docker images, static binaries and Debian and Ubuntu packages, and it migrates existing Conduit and conduwuit RocksDB databases in place on first boot. It does not yet migrate from Synapse, so a team with a live Synapse history must either keep running Synapse or start a new server and accept that existing rooms and accounts do not carry over. Before you commit, confirm the current feature coverage for your SSO provider, your federation requirements and your bridges against the Tuwunel repository and the Matrix.org server list.
The decision turns on four things: whether you already hold Synapse data you cannot leave behind, whether your licensing policy accepts AGPL-3.0 obligations for a server you may modify and offer to users, how much federation you need and which identity protocols you must support, and how much operating experience your team has with Python services and PostgreSQL. If the answer to the first question is yes, the choice is already made. If not, write down those four answers before comparing resource use or release cadence, because they decide which measurements matter.
Which homeserver fits which scenario
This table matches common Matrix homeserver situations to Synapse or Tuwunel and states the condition behind each choice. Read each row against your own constraints, since the right answer often depends on whether you already run Synapse and whether you need features the Rust project has not yet matched.
| Scenario | Better fit | Reason and condition |
|---|---|---|
| Greenfield deployment with no existing Matrix data | Synapse, unless a single binary is a hard requirement | Synapse has the broadest documentation and the most published operating guidance. Tuwunel is a reasonable choice if you accept a younger project and confirm the feature set covers your users. |
| Existing Synapse server | Synapse | Tuwunel cannot migrate from Synapse yet, according to its README. Switching means a new homeserver, new user and room state planning, and a federation identity cutover, so staying put is usually cheaper. |
| Requirement for AGPL-compatible licensing | Synapse | Synapse is AGPL-3.0 with commercial exceptions available from Element. Tuwunel is Apache-2.0, which many organizations also accept, so confirm your own license policy before deciding. |
| Need for workers at scale | Synapse | Synapse scales with worker processes that use Redis for replication. Confirm with your own load tests whether Tuwunel's architecture meets your concurrency target before relying on it. |
| Small team wanting a single binary | Tuwunel, if you are starting fresh | Tuwunel ships static binaries, Docker images and Deb and RPM packages. Synapse can also run as a single process, but it needs a Python runtime and, for production, PostgreSQL. |
| Regulated environment needing documented upgrade paths | Synapse | Synapse publishes upgrade notes covering schema changes and dependency end-of-life. Tuwunel's migration documentation is narrower, so ask for a written upgrade and rollback procedure before committing. |
| Migrating existing conduwuit or Conduit data | Tuwunel | Tuwunel migrates Conduit and conduwuit RocksDB databases in place on first boot, according to its README. Verify the result against your own data in a test environment first. |
How Synapse and Tuwunel are built and deployed
Synapse and Tuwunel reach production by different routes. Synapse is a Python process that grows by splitting work across workers, while Tuwunel is a single Rust homeserver shipped in several packaging formats. The cards below cover the components, packaging and data decisions that determine how each one is run and how hard it is to change later.
Synapse as a Python process
Synapse is the Python reference homeserver developed by Element. A single main process handles requests on a standard install, and its configuration, plugins and upgrade path all follow the Python runtime. Each Synapse release drops support for Python and PostgreSQL versions once they reach upstream end of life, so the runtime is a recurring operating task. Check which Python version your chosen release needs before you plan the host image.
Workers and Redis for scale
Synapse scales horizontally by starting worker processes. The main process and all workers connect to Redis, which relays replication between them, and the generic worker handles client, federation and event traffic. This adds Redis, a reverse proxy that routes requests to the right worker, and more processes to monitor. Ask whether your traffic justifies that layer before you commit to it.
PostgreSQL for production, SQLite for trials
Synapse documentation recommends PostgreSQL for production and also supports SQLite. Synapse 1.143.0 and later require PostgreSQL 14 or newer, so older database servers block upgrades. SQLite suits a small test server, but moving a live server from SQLite to PostgreSQL is a planned migration, not a configuration switch. Decide the database before users arrive.
Tuwunel as a Rust binary
Tuwunel is an Apache-2.0 Matrix homeserver written entirely in Rust. It ships as Docker images, static binaries, Deb and RPM packages and an Apt repository for Debian and Ubuntu. A static binary or package removes the Python runtime from the host, which simplifies patching. Confirm the supported install paths and the service layout with the maintainers before you standardize on one.
RocksDB migration on first boot
Tuwunel migrates Conduit and conduwuit RocksDB databases in place on first boot. This means an existing Conduit or conduwuit server can move to Tuwunel without a separate data export. Migration from Synapse is not yet possible, so a Synapse deployment cannot be moved onto Tuwunel with this method. Take a full backup before any first boot, and confirm the migration path with the Tuwunel maintainers.
Scaling and database questions for Tuwunel
The published material does not establish how Tuwunel scales beyond a single process, whether it offers a worker or clustering model, or which databases it supports beyond RocksDB. Ask the Tuwunel maintainers for their supported database options, their multi-process or high availability story, and the resource profile for your user count. Get the answers in writing before you compare them with Synapse's documented worker model.
Feature and operations comparison
This table sets the Python reference homeserver against the Rust Tuwunel on the points that drive a deployment decision. Read each row as a question to answer for your own environment, and treat any cell that says to confirm as a gap to close with the vendor before you commit.
| Capability | Synapse | Tuwunel |
|---|---|---|
| License | AGPL-3.0, with commercial licenses available from Element | Apache-2.0 |
| Implementation language | Python | Rust, written entirely in Rust |
| Database options | PostgreSQL recommended for production; SQLite also supported. PostgreSQL 14 or newer required from 1.143.0 | RocksDB is the database it migrates existing Conduit and conduwuit data into; confirm other supported backends |
| Scaling with workers | Supported through worker processes, with Redis relaying replication between processes | Confirm whether a worker or clustered model exists; not covered in the supplied facts |
| Federation controls | federation_domain_whitelist restricts federation to listed domains; an empty list disables it; firewall the federation listener | Confirm the equivalent allow and deny settings before relying on them |
| Server name and delegation | server_name fixes user and room identity; delegation serves @user:example.com from another host on port 443 | Confirm how server name and delegation are configured |
| Single sign-on | OpenID Connect via oidc_providers, SAML2 via saml2_config, and CAS | Confirm supported SSO protocols in the current release |
| Docker and packaging | Confirm the official packaging options for your target platform with Element's documentation | Docker images, static binaries, Deb and RPM packages, and an Apt repository for Debian and Ubuntu |
| Latest release (as supplied) | v1.163.0, published October 14, 2026 | v1.9.4, published October 10, 2026 |
| Migration path | Upgrades follow upstream notes; rolling back can be difficult because of schema changes | Migrates Conduit and conduwuit RocksDB databases in place on first boot; migration from Synapse is not yet possible |
What AGPL-3.0 and Apache-2.0 mean for each homeserver
Synapse, the Python homeserver developed by Element, is distributed under AGPL-3.0-or-later according to the Matrix.org server listing. You can run, study and modify the code without buying a license. Element also sells commercial licenses that provide AGPL exceptions, and it sells Synapse Pro as a separate product. The AGPL sets the baseline, and the commercial options matter when your legal team cannot accept the copyleft conditions for a particular distribution or hosting model.
- Open source baseline: The code is available under AGPL-3.0-or-later, so a self-hosted deployment starts without a license fee.
- Commercial AGPL exceptions: Element sells exceptions to the AGPL terms, which can matter for proprietary modifications or distribution to third parties.
- Synapse Pro: This is a separate commercial offering, so confirm exactly what it includes, its support terms and its update policy before you budget for it.
- Upstream documentation: The Synapse documentation and upgrade notes are published by the project, which helps platform teams plan releases.
Ask Element in writing which option covers your planned distribution and whether an exception is needed for your hosting model.
On December 13, 2023, Element announced that future Synapse contributions would be licensed under AGPLv3 instead of Apache 2.0. In the same announcement it moved the repositories from matrix-org to element-hq on GitHub, began selling AGPL exceptions, and required contributors to sign a contributor license agreement. The announcement addressed future contributions, so the terms of earlier code may differ from the terms of current releases. For any version you depend on, ask counsel to confirm the provenance and license position.
- Date and scope: The licensing change was announced on December 13, 2023 and applies to future contributions, according to Element.
- Repository move: Development moved to the element-hq organization, so update clone URLs, package sources and license scanning rules that point to the old location.
- Contributor license agreement: Contributors sign a CLA, which in practice gives the project steward rights to relicense or grant exceptions. Confirm the scope of the CLA with counsel before you contribute patches upstream.
- Exceptions for sale: Element began selling AGPL exceptions at the same time, so the commercial option is part of the same licensing structure.
- Release checks: Synapse v1.163.0 was published on October 14, 2026, so read the license file in the exact version you deploy.
Check the Element announcement, the CLA text and the license headers in your target release before you approve a deployment plan.
Tuwunel is an Apache-2.0 Matrix homeserver written entirely in Rust. Its README presents it as an alternative to Synapse and as the official successor to conduwuit, and it names the government of Switzerland as its primary sponsor. Apache-2.0 is a permissive license. It allows use, modification and redistribution, and it does not impose the network source-offer obligation found in the AGPL. Whether that simplifies your review depends on your own legal position and on the sponsorship arrangements, which you should confirm directly.
- Permissive terms: Apache-2.0 carries attribution and notice conditions but no network copyleft, which many legal teams review more quickly.
- Government sponsorship: The README names Switzerland's government as primary sponsor. Ask the maintainers what that sponsorship covers, how long it is committed and whether it includes support.
- Release channel: Tuwunel v1.9.4 was published on October 10, 2026, and the project ships Docker images, static binaries, Deb and RPM packages and an Apt repository.
- Lineage: Matrix.org lists Tuwunel alongside Conduit and Continuwuity as Apache-2.0 Rust homeservers, so compare the forks' maintenance records before you choose one.
Confirm the license file in the exact release you plan to deploy and get any sponsorship or support commitments in writing.
The AGPL includes a network clause. If you modify Synapse and let users interact with the modified version over a network, the license can require you to offer those users the corresponding source of your modified version. Unmodified use creates a different set of duties than a patched or extended build. Whether a given deployment triggers these duties is a legal question for your counsel, not a question the software answers. The points below are the issues to bring to that review.
- Modification trigger: Confirm whether your build contains only configuration changes or also code changes, such as custom modules or patches.
- Network interaction: A homeserver is a service that users reach remotely, so the network clause is the usual point of review for hosted deployments.
- Internal and external users: Ask counsel whether staff-only access changes the analysis in your jurisdiction and under your contracts.
- Bundled components: Inventory Element Web, bridges, Redis and other components, since each carries its own license.
- Exception route: If the obligations do not fit your plan, ask Element about commercial exceptions before go-live.
Give counsel the exact Synapse version, a list of your modifications, your deployment topology and the user groups, then request a written view.
Why moving from Synapse to Tuwunel is not yet possible
Tuwunel cannot import a Synapse database today, so a server running Synapse cannot be moved to Tuwunel in place. Tuwunel's README says it migrates Conduit and conduwuit RocksDB databases in place on first boot, but migration from Synapse is not yet possible. Synapse stores its state in PostgreSQL (recommended for production) or SQLite, and Tuwunel has no supported path to read that schema. Any move therefore means standing up a new homeserver and bringing users across by other means, which is a different project from an upgrade or a reinstall.
The cost of a later switch falls on everything tied to the server_name you set at install. Matrix user IDs such as @user:example.com, room identifiers, and the signing keys that other servers trust all derive from that name, and federation depends on them. Users must log in again on new accounts or accounts recreated under the same name, room history from Synapse does not follow the users, and bridges, bots and clients keep pointing at the old homeserver until each one is reconfigured. Ask whether your rooms need their history preserved, which users can be re-invited, and which bridges your organization depends on. Confirm with the Tuwunel maintainers through the Tuwunel repository whether a Synapse import is on the roadmap, and what timeline they will commit to, before you rely on it.
Make the homeserver decision before go-live, not after users arrive. If your organization may later need Synapse features such as its documented workers, OIDC or SAML2 single sign-on, or Element's commercial options, choose Synapse now or accept that a future move will be a full re-platforming. If you choose Tuwunel for its resource profile and Apache-2.0 license, document the exit plan in writing: an export of users and rooms you can actually perform, a named owner for federation identity, and a test of a second homeserver using a non-production server_name. Confirm current support and roadmap statements directly with the maintainers and in the release notes for each version you deploy, since the Tuwunel README is the only source we rely on for migration status.
How to move users between Synapse and Tuwunel
This sequence sets out the order of work for a team that wants to change homeservers, from the decision before launch through account, room, DNS and client changes to notice for federated peers. It also makes clear that a direct Synapse to Tuwunel data move is not covered by Tuwunel's migration path, so the team must confirm that route before committing.
Decide the homeserver before launch
Before any user joins, the platform owner, security lead and the team that runs the Matrix service agree which homeserver the organization will operate. Record the reasons: Synapse's documented production path, its Python and PostgreSQL support rules, its workers model and its SSO options, against Tuwunel's Apache-2.0 license, Rust codebase and in-place migration for Conduit and conduwuit databases. Done means a signed decision record that names the homeserver, its version and the owner of future upgrades. If the team cannot confirm which features it needs, it should test both in a non-production environment first, using its own identity provider and bridges.
Confirm the data move path in writing
Tuwunel's README states that it migrates Conduit and conduwuit RocksDB databases in place on first boot, but that migration from Synapse is not yet possible. Synapse's upgrade notes also warn that rolling back can be difficult because of schema changes. Ask the Tuwunel maintainers and your own implementation partner to confirm, in writing, whether any supported path exists for your Synapse version and database. Do not assume a tool or script exists. Done means a written answer that either names a tested path or confirms that the move is a re-creation of accounts and rooms.
Plan DNS and server_name changes
The server_name setting fixes how user IDs and room identifiers are formed, so a new homeserver with a different server_name creates a new identity space. Decide whether the new server will serve the existing domain or a new one. If the domain stays the same, plan delegation so that user IDs such as @user:example.com continue to resolve on port 443, and check how federation on port 8448 will be reached. Write down every DNS record, delegation file and certificate change, and the rollback order. Done means a reviewed change plan with a named owner for each record and a tested resolution check from outside your network.
Export or recreate accounts and rooms
If the path confirmed in the earlier step is a re-creation, export the account list from the source server, including display names, administrator flags and the identity provider mapping for each user. Recreate rooms with their names, topics, membership and power levels from an agreed export, and record which history will not carry over. Encrypted rooms need explicit key handling, so users must confirm they hold their recovery material before cutover. Done means a reconciliation report that matches the count of accounts and rooms in the source with the count in the target, and a list of exceptions signed off by the data owner.
Reconfigure single sign-on and clients
Connect the new homeserver to the same identity provider and test each login path before users depend on it. Synapse documents OpenID Connect, SAML2 and CAS for single sign-on, so confirm which of these the target supports in your deployment and version. Update client login settings, push notification configuration and any mobile or desktop profiles that point at the old homeserver address. Test with a pilot group across the clients your users run. Done means a pilot in which each client logs in, sends and receives messages, and recovers an encrypted session on the new server.
Reconfigure bridges and integrations
Bridges and bots hold their own registrations and tokens tied to a specific homeserver. Inventory every bridge, bot, webhook and automation that connects to the current server, and check each project's documentation for support on the target homeserver before you cut over. Recreate application service registrations, rotate tokens and confirm that bridged rooms still map to the correct external accounts. Done means each integration passes a scripted test message in both directions, and the owner of each one has signed off the result.
Notify federated peers and run cutover
Tell administrators of federated servers and partner organizations about the change date, the new server_name if it differs, and any rooms that will not carry history. Keep the old server reachable for a defined transition window agreed with the owners, and disable federation on the old server only after peers confirm. Freeze new account creation during cutover, run the agreed change plan, and watch logs for failed joins and key errors. Done means a cutover record showing the change window, the peers notified, the test results and a rollback decision point that was passed or not needed.
What implementing each homeserver involves and where projects run long
Synapse is the lower-risk build for most teams because its operating path is documented in depth. A production install usually means PostgreSQL rather than SQLite, since the upgrade notes recommend PostgreSQL for production, and the Synapse upgrade notes state that 1.143.0 and later require PostgreSQL 14 or newer. Size the database host and its backups before the homeserver goes live, and confirm the Python version against the 1.142.0 requirement of Python 3.10 or newer. Reverse proxy and TLS work centers on two decisions: whether federation runs on port 8448 directly or through delegation so that users such as @user:example.com are served on port 443, and how server_name is fixed, because changing it later changes how users and rooms are identified. Plan the federation test as its own workstream, with a rehearsal against a second server before users arrive, and set federation_domain_whitelist deliberately if the deployment should not federate openly. Backups need a tested restore, since the upgrade notes warn that rolling back can be difficult because of schema changes between releases.
The identity work is where Synapse projects usually slip. Synapse supports OpenID Connect through oidc_providers, SAML2 through saml2_config and CAS, so the identity mapping (which claim becomes the Matrix localpart, how display names and admin roles are set, and what happens to existing local accounts) must be designed with the identity team before configuration starts. For Tuwunel, the identity approach still needs to be confirmed against its current documentation and the configuration it ships with, and that check belongs in the proof-of-concept phase before any commitment to an identity design. Upgrades differ in kind: Synapse releases follow a fast cadence (v1.163.0 was published on October 14, 2026), so schedule a staging upgrade for every release and track Python and PostgreSQL end-of-life dates, which Synapse drops once they reach upstream end of life. Bridges and client rollout are the other common overruns. Each bridge needs its own database, registration file and maintenance owner, and client rollout depends on which Matrix clients your users will install, so test those clients against the chosen homeserver with real rooms, encryption and a federated contact, not only a local account.
Questions buyers ask before choosing a Matrix homeserver
Can Tuwunel replace Synapse today?
Not directly. Tuwunel is an Apache-2.0 Matrix homeserver written in Rust and presented as an alternative to Synapse, but its README states that migration from Synapse is not yet possible. It does migrate Conduit and conduwuit RocksDB databases in place on first boot. If you already run Synapse with rooms and user history you need to keep, plan to stay on Synapse or start a new homeserver with a separate data-migration strategy, and confirm the current migration position with the Tuwunel project before committing.
What does the AGPL license of Synapse mean for a hosted service?
The AGPL-3.0 license of Synapse applies its source-disclosure obligations to network use, so a service that modifies Synapse and makes it available to users over a network generally has to offer those users the modified source. Element also sells commercial licenses and AGPL exceptions, which the Element blog describes as part of its move to AGPLv3 in December 2023. Tuwunel is Apache-2.0, which carries no comparable network-use obligation. Have your legal counsel review your exact use, including any internal modifications and any hosted offering, before you choose.
When are Synapse workers worth the operating effort?
Workers are worth considering when a single Synapse process no longer keeps up with your load and you can operate the extra parts. Synapse scales with worker processes, and the main process and all workers connect to Redis, which relays replication between processes. The generic worker handles client, federation and event traffic. Each worker adds configuration, reverse proxy routing and Redis and PostgreSQL dependencies. Measure your actual load, and read the Synapse workers documentation before you split a deployment that runs well as a monolith.
What skills does the internal team need to run a Matrix homeserver?
The team needs working knowledge of the homeserver, its database, a reverse proxy and TLS, and the identity setup you choose. For Synapse, the production recommendation is PostgreSQL, and recent releases require PostgreSQL 14 or newer and Python 3.10 or newer. Federation needs correct DNS, port 8448 or delegation to port 443, and a fixed server_name. Upgrades need care because the Synapse upgrade notes warn that rolling back can be difficult after database schema changes. Ask who will own upgrades, backups and on-call response before you choose.
How long does a typical Matrix homeserver rollout take?
No researched fact gives a typical duration for this rollout, so treat any figure you hear with caution. The timeline depends on the number of users, whether you need federation, the identity integration, the database and reverse proxy you already operate, whether you migrate existing data, and how many people must test clients. Ask for a schedule with named phases, the testing you expect, and the handover checkpoints, and compare it against your own change calendar.
Can our team implement a Matrix homeserver without outside help?
Yes, a team with Linux, database and reverse proxy experience can install Synapse or Tuwunel from published packages, but the harder parts are operational. Those include federation and delegation setup, single sign-on through the OpenID Connect, SAML2 or CAS options Synapse documents, backups, upgrades and security hardening. Be honest about capacity, because the effort is ongoing rather than a one-time install. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own infrastructure, so you can decide which parts to keep in house.
What should a fixed-scope quote for a Matrix deployment include?
A fixed-scope quote follows from a written scope, which DeployOpen agrees before work starts. Ask it to list the homeserver and version, the database, whether federation is enabled, the identity integration, the number of users and clients in scope, worker or single-process architecture, backup and restore testing, upgrade handling, documentation and handover, and any compliance evidence you need. Also ask what is one-time and what recurs, including any retainer for ongoing support, upgrades and testing. DeployOpen does not publish a price list, so the quote is the basis for cost.
How DeployOpen helps choose, implement or migrate a Matrix homeserver
DeployOpen plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Synapse vs Tuwunel, that means starting from your federation, retention, identity and migration requirements before any homeserver is installed.
How we scope
- Written scope fixes which homeserver, database and identity integrations are in or out before work starts.
- Scope records your expected user count, federation policy and whether Synapse history must be kept or moved.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
- Quotes follow from the written scope, so ask us to itemize each component against the scope you approve.
How we build
- We deploy the chosen homeserver in your environment, with server_name, delegation and federation settings documented.
- We configure the database backend you select and test backup and restore against it before go-live.
- We wire OIDC, SAML2 or CAS single sign-on where your chosen server supports it, and test each login path.
- We run security testing against the deployed homeserver and its reverse proxy before handover.
How we hand over
- You receive architecture notes, configuration records, runbooks and the upgrade and rollback procedure for your version.
- Handover includes a tested restore walkthrough and a list of features confirmed or still open for your use case.
- Documentation records the migration path decision, including what a Synapse to Tuwunel move would require today.
- Your team leaves with clear ownership of certificates, federation firewall rules and database maintenance tasks.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- Retainers can cover version reviews when Synapse or Tuwunel publish releases that change your deployment.
- Ask any quote to state which upgrades, patch windows and testing cycles are included and which are extra.
- Support scope is set in writing, so you know who handles database, federation and identity incidents.
