Synapse vs Dendrite: which homeserver to deploy for a new Matrix service
If you are choosing a Matrix homeserver for users you must support, deploy Synapse. It is the homeserver Element actively develops, and it is the right default for any new service. Dendrite is in maintenance mode with only security fixes applied, so it should not be the foundation of a service you expect to grow, change or depend on for years. Start from the assumption that Synapse is the answer and only move away from it if one of the narrow conditions below clearly applies. Dendrite still fits a small homeserver of tens or hundreds of users, run by a team that accepts beta-grade software, with no high availability requirement and no need for clustering. Its README recommends PostgreSQL and states that it lacks high availability and clustering support. Its README also states it does not support MSC4186 simplified sliding sync or MSC3861 next-generation OIDC auth, so Element X cannot be used against it. If your users expect Element X, Dendrite is ruled out regardless of user count.
Four conditions decide the choice. First, user count: if you expect growth beyond a small community, Synapse's worker model, which uses Redis replication between processes, is the path that scales. Second, Element X: confirm whether your users need it, since Dendrite cannot provide it. Third, high availability: Dendrite offers no clustering, so any availability requirement points to Synapse. Fourth, identity integration: Synapse supports OpenID Connect, SAML2 and CAS through its configuration, and you should confirm which of these your identity provider needs. Map each condition to a written requirement before you pick. Before you commit, check the licence and support terms for your use. Synapse is AGPL-3.0, with commercial licences available from Element, and the Matrix.org ecosystem page lists the homeserver options. Ask Element and your implementation partner what a supported Synapse deployment costs in your environment, and what the upgrade path looks like, because Synapse's upgrade notes warn that rolling back can be difficult after schema changes.
Which homeserver fits which scenario
This table maps common Matrix deployment scenarios to the homeserver that fits better, with the supplied reason for each choice. Read each row against your own user count, growth plans and client requirements, and treat any row marked for confirmation as a question to settle with Element before you commit.
| Scenario | Better fit | Reason and what to confirm |
|---|---|---|
| Small team or community homeserver of tens or hundreds of users | Either, with Dendrite viable if Element X is not needed | Dendrite's README describes it as beta software suited to small homeservers of tens or hundreds of users. Confirm that Dendrite's current beta status fits your risk tolerance. |
| Company rollout that needs Element X | Synapse | Dendrite does not support MSC4186 simplified sliding sync or MSC3861 next-generation OIDC auth, which Element X depends on. Confirm the exact client and auth features your rollout requires. |
| Growing federated service | Synapse | Synapse is actively developed and scales with worker processes. Dendrite's README lists no high availability or clustering support, so growth beyond a single node is a poor match. |
| Deployment that must scale with workers | Synapse | Synapse's main process and workers connect to Redis, which relays replication between processes. Dendrite has no clustering support. Plan for PostgreSQL and Redis operating effort if you choose this path. |
| Proof of concept or lab evaluation | Dendrite for a quick functional test, Synapse if the PoC must match production | A PoC on Dendrite tests basic Matrix behavior at small scale. If the PoC needs Element X or workers, test on Synapse so the results carry over. Confirm which features the PoC must prove. |
| Long-lived production service | Synapse | Dendrite is in maintenance mode with only security fixes applied, and its latest release in the supplied facts is v0.15.2 from August 15, 2025. Synapse has active development, with v1.163.0 published October 14, 2026. Confirm the support expectations for your organization with Element before you commit. |
| Federation with other servers on the public network | Synapse | Synapse federates on port 8448 by default and supports delegation, and its federation_domain_whitelist setting can restrict federation to listed domains. Confirm federation behavior in your own network before rollout. |
| Single sign-on with an existing identity provider | Synapse | Synapse supports OpenID Connect providers, SAML2 and CAS according to its configuration manual. Confirm which of these your identity provider and client versions support before you plan the rollout. |
How Synapse and Dendrite are built and what that means for operations
Both homeservers speak the same Matrix protocol, but they are built very differently. The differences in process model, database, high availability and federation setup decide how much operating work each one places on your team. Read each card with your expected user count and uptime requirement in mind.
Synapse main process and workers
Synapse can run as one main process, or split into workers that share load. The main process and all workers connect to Redis, which relays replication between them. The generic worker handles client, federation and event traffic, so a split deployment adds Redis, worker configuration and reverse proxy routing to your scope. Check whether your expected traffic justifies that extra moving part before you commit to it.
Dendrite as a Go service
Dendrite is written in Go and is a separate codebase from Synapse, not a configuration of it. Its README recommends PostgreSQL as the database. Because it is a single service with its own release cycle, your team operates a different implementation with its own configuration, upgrade path and bug history. Confirm that your staff can support a Go service and that Element's current maintenance status fits your plans.
Dendrite without high availability
The Dendrite README states it has no high availability or clustering support, and it describes the software as beta for small homeservers of tens or hundreds of users. If your service needs failover across nodes, Dendrite cannot provide it from its own design. Plan for a single-instance recovery procedure, tested backups and a clear outage budget, or choose Synapse with the worker design if horizontal scaling is a requirement.
Synapse PostgreSQL for production
Synapse supports SQLite, but its documentation recommends PostgreSQL for production. Synapse 1.143.0 and later require PostgreSQL 14 or newer. Your team must run, back up and upgrade the database server, and Synapse upgrade notes warn that rolling back can be difficult because of schema changes between releases. Budget database administration time in addition to the homeserver itself.
Federation on port 8448 with delegation
Synapse federates on port 8448 by default. Delegation lets user IDs such as @user:example.com be served from another host on port 443, so your public DNS and TLS setup can differ from the federation listener. The server_name setting fixes how users and rooms are identified, so choose it carefully before first use. Confirm that your firewall, reverse proxy and certificates cover the chosen ports, and consider federation_domain_whitelist if you need to restrict federation.
Operating effort by architecture
A single Synapse process with PostgreSQL is the smallest supported production footprint. Adding workers adds Redis, more services and routing rules. Dendrite has fewer documented components but limited scaling and no clustering. Ask for the expected user count, uptime target, staff skills and upgrade cadence in your scope, then match the architecture to those inputs. Hosting cost depends on your infrastructure, so confirm it with your own environment rather than assuming it.
Synapse and Dendrite compared on capability and support
This table compares Element's two Matrix homeservers on maintenance status, release cadence, architecture, Element X compatibility, federation controls, single sign-on and upgrade risk. Read the rows as a checklist: where Dendrite shows a limitation, that limitation is a deciding factor for production, while the rows marked to confirm need a check against current upstream documentation before you commit.
| Capability | Synapse | Dendrite |
|---|---|---|
| Maintenance status | Actively developed by Element, with workers and regular releases | In maintenance mode, receiving only security fixes |
| Latest release cited | v1.163.0, published October 14, 2026 | v0.15.2, published August 15, 2025 |
| Language and license | Python, AGPL-3.0 | Go, AGPL-3.0 |
| Scaling model | Worker processes coordinated through Redis replication | No clustering or high availability support per its README |
| Intended deployment size | Production homeservers, scaled with workers as load grows | Beta software suited to small homeservers of tens or hundreds of users |
| Element X via MSC4186 and MSC3861 | Supported by the current codebase (confirm feature status for your release) | Not supported, so Element X cannot be used against Dendrite |
| Federation controls | federation_domain_whitelist restricts federation; an empty list disables it; firewall the federation listener | Confirm the equivalent controls in the Dendrite configuration before relying on them |
| SSO options | OpenID Connect, SAML2 and CAS through its configuration manual | Confirm supported SSO methods in current Dendrite documentation |
| Database requirements | PostgreSQL recommended for production; SQLite supported; PostgreSQL 14 or newer from 1.143.0 | PostgreSQL recommended per its README |
| Upgrade and rollback | Rollback can be difficult because of schema changes; back up before each upgrade | Confirm upgrade and rollback guidance with Element before any migration |
What the license and paid options cover for each homeserver
Synapse is Element's Python homeserver and is distributed under AGPL-3.0, the license that governs the codebase Element maintains. For most self-hosting teams the license is the starting point. You can run, modify and redistribute Synapse under the AGPL, provided you meet its conditions. The Synapse documentation describes the AGPL distribution and notes that commercial licenses are also available from Element.
- Open distribution: Synapse is licensed AGPL-3.0 and developed by Element, so the source for the homeserver you deploy is publicly available.
- Network copyleft: If you modify Synapse and users interact with the modified service over a network, the AGPL requires you to offer them the corresponding source of your changes. Plan for this with any custom module or patch.
- Commercial alternative: Element sells commercial licenses for Synapse for organizations that cannot meet AGPL conditions. The supplied facts do not list their terms, so ask for them.
- Version-level labels: Matrix.org's ecosystem page lists Synapse as AGPL-3.0-or-later. Check the license file and headers of the exact release you plan to deploy.
Confirm with your counsel how the network clause applies to any change you make, and keep the license file for each release in your change records.
Element's commercial position for Synapse rests on two parts: AGPL exceptions that Element began selling after its licensing change, and Synapse Pro, which Matrix.org lists among the homeserver options in its ecosystem. The change matters for procurement because it altered how contributions reach the codebase and how Element funds development. Element's announcement gives the background.
- December 13, 2023 change: Element announced that future Synapse contributions would be licensed under AGPLv3 instead of Apache 2.0, moved the repositories from matrix-org to element-hq on GitHub, and began selling AGPL exceptions.
- Contributor agreement: Contributors sign a contributor license agreement. Review its terms if your team plans to send patches upstream, because the agreement governs how Element may license accepted code.
- Synapse Pro: Matrix.org lists Element's commercial Synapse Pro among its homeserver implementations. The supplied facts do not describe its features or support levels, so request them in writing.
- Separate cost lines: The license or exception, any support subscription and your own operating staff are distinct costs. Ask which of these a quote includes.
Ask Element for the exact license text, the support scope and the contract term before you assume a commercial license covers your deployment.
Dendrite is Element's homeserver written in Go. Matrix.org lists it under AGPL-3.0-or-later with Element as the maintainer, so its license obligations follow the same structure as Synapse's. The license is not what separates the two homeservers. The difference lies in maintenance status and feature coverage, which the next tab covers. The Dendrite repository is the place to check the license file for the code you intend to run.
- License identifier: Matrix.org lists Dendrite as AGPL-3.0-or-later, which permits use under version 3 of the AGPL or any later version the license allows.
- Maintainer: Element maintains the element-hq Dendrite repository, so the same company governs both Element homeservers.
- Network clause applies: Changes to Dendrite that users reach over a network carry the same source-offer duty as changes to Synapse.
- No support offer in the facts: The supplied facts do not show a Dendrite support contract or a commercial exception. Do not assume either exists until Element confirms it in writing.
Verify the license file in the exact Dendrite release you plan to use, and ask Element whether any commercial terms apply to Dendrite at all.
A license tells you what you may do. It does not tell you whether fixes or features will arrive. Dendrite's README says the project is in maintenance mode with only security fixes applied. That status changes the cost picture for any team that expects to run the homeserver for several years, because the feature roadmap is no longer the source of future capability.
- Security fixes only: Dendrite receives security fixes, so feature gaps stay open unless you fund and maintain the change yourself.
- Beta and small scale: The README calls Dendrite beta software suited to small homeservers of tens or hundreds of users, and it lists no high availability or clustering support.
- Element X gap: Dendrite does not support MSC4186 simplified sliding sync or MSC3861 next-generation OIDC auth, which limits the use of Element X.
- Release history: The supplied facts list v0.15.2, published on August 15, 2025, on the GitHub releases page. Check the releases page for anything published after that date before you plan.
Ask for the maintenance commitment, the security response expectations and a migration path in writing before you choose Dendrite for anything beyond a pilot.
The written answers matter more than the license label. Use these questions to compare both homeservers on the same terms, and record each answer in the contract or statement of work, tied to the version it covers. Your auditors and your future migration planning will both depend on those records.
- License scope: Which license and version apply to the exact binaries and container images you receive, and whether any commercial exception covers your modifications.
- Source obligations: How you will meet the AGPL source-offer duty for patched or custom modules, and who reviews the published source.
- Support and maintenance: Which support tiers exist for each homeserver, the stated response expectations, and whether security fixes are committed for a stated period.
- Upgrade and rollback: What the vendor says about schema changes between releases, since the Synapse upgrade notes warn that rollback can be difficult.
- Feature dependencies: Confirm sliding sync, OIDC, SSO and worker support against the clients and identity provider you plan to use before signing.
Keep each answer with its version and date in the file you give your auditors and your platform team.
How identity and federation choices affect a Matrix rollout
The identity path is the first decision that separates these two homeservers in practice. Synapse supports single sign-on through OpenID Connect providers configured under oidc_providers, SAML2 through saml2_config (using pysaml2), and CAS, so an organization can connect its existing directory without changing how users sign in. Matrix Authentication Service can also connect to upstream identity providers, which is the route Element's current OIDC direction relies on. Dendrite does not support MSC3861 next-generation OIDC auth, and it does not support MSC4186 simplified sliding sync, which is the reason Element X is not available on it. If your sign-in requirement is OIDC-based and you want Element X users, that single gap is enough to rule Dendrite out for a new deployment. Confirm the identity provider options Dendrite offers directly with Element before you assume any of Synapse's SSO methods carry over.
The server name is the second decision, and it is much harder to reverse than the identity provider. The server_name setting fixes how users and rooms are identified, so an address such as @user:example.com is tied to that domain from the first account onward. Once users and rooms exist, changing it means you are effectively building a new identity namespace. Delegation solves the hostname problem without changing that identity: user IDs can stay on the primary domain while the homeserver runs on another host, with federation served on port 443 instead of the default port 8448. Plan the DNS and delegation records before the first user signs up, and test them from outside your network as part of the rollout checklist.
Federation scope is the third decision. The federation_domain_whitelist setting restricts federation to listed domains, and an empty list disables federation entirely. The Synapse documentation recommends also firewalling the federation listener, so the whitelist is not the only control on who can reach the server. For a regulated organization that needs an internal-only chat service, the practical choice is an empty list plus a firewall rule, and that decision should be recorded in your change process. Whichever way you go, ask Element and your own security team to review the federation settings together with your identity configuration, because a permissive federation policy combined with weak sign-in controls is the combination most likely to be questioned in an assessment.
What drives the running cost of each homeserver
Running either homeserver costs more in people and upgrade discipline than in licenses, since both are AGPL-3.0 and neither has a license fee for the core code. The cards below cover the infrastructure, skills, upgrade cadence, vendor support and future migration decisions that shape the bill, along with what to request in a written quote.
Synapse worker count and Redis
A single Synapse process is the simplest footprint, but larger deployments split traffic across workers. Every worker connects to Redis, which relays replication between processes, so Redis becomes a service you must size, monitor and keep highly available. Ask the implementer to model worker count against your expected user and room load before committing to infrastructure. Dendrite has no equivalent worker model to plan around.
PostgreSQL sizing and version floor
Synapse documentation recommends PostgreSQL for production. From 1.143.0, PostgreSQL 14 or newer is required, so an older database cluster forces a database upgrade before a Synapse upgrade. Database sizing, backups and replication are recurring line items that scale with message volume and retention. Dendrite also recommends PostgreSQL, so this cost category applies to both, but Synapse's load profile is the one to size carefully.
Python and PostgreSQL upgrade discipline
Synapse drops support for Python and PostgreSQL versions once they reach upstream end of life, and from 1.142.0 it requires Python 3.10 or newer. Operators therefore need a standing process to track runtime and database lifecycles and to schedule upgrades. The upgrade notes also warn that rolling back can be difficult because of database schema changes between releases, so each upgrade needs a tested backup and a rehearsal in a staging environment.
Go operations for Dendrite
Dendrite is written in Go, so it ships as a compiled binary, and its operating skill set centers on Go-based services, PostgreSQL and the Matrix protocol. Dendrite is in maintenance mode with only security fixes, so the team carries the risk that feature work stops and that any gap in functionality must be handled in-house or by a partner. Ask who will own security patches and how long the current release line will receive them.
Vendor support from Element
Synapse is developed by Element and distributed under AGPL-3.0, with commercial licenses available from Element, so a paid support or license relationship is an option that Dendrite cannot offer on the same terms. Dendrite's maintenance-mode status means a support contract would be buying security fixes on a stalled codebase. Confirm with Element what support tier, response commitments and license terms apply before you budget.
Cost of a future migration
Choosing Dendrite for a small deployment and later needing clustering, Element X support or high availability means migrating users, rooms and history to Synapse. The upgrade notes already warn that rollback is hard, so a migration is a planned project with its own rehearsal, cutover window and client re-testing. Ask the implementer to price the migration path as a separate line item in the written scope, including data export, federation identity handling and downtime.
Moving from Dendrite to Synapse without losing rooms or identities
This sequence moves a Dendrite homeserver to Synapse while keeping the server name, user identities and federation intact, and it ends with users cut over to a tested target. It does not promise a lossless migration, so each step closes with a check you can verify before moving on.
Confirm the server_name and identity model
Before anything else, record the server_name your Dendrite deployment uses, because it defines how every user ID (for example @user:example.com) and room identifier is anchored. Synapse fixes this value in its configuration, and changing it later means existing identities no longer match. Decide whether the Synapse instance will keep that name, and whether any login provider will issue the identities. Your platform team and the identity owner should sign off in writing. The output is a one-page record of the server_name, the user ID format and the identity source, which every later step checks against.
Back up the Dendrite PostgreSQL database
Dendrite recommends PostgreSQL, so take a full, consistent backup of its database and store it outside the server, with a restore test on a separate host. Stop or quiesce writes if your Dendrite setup allows it, and record the exact Dendrite version in use, since the latest tagged release referenced here is v0.15.2 and your running build may differ. Keep the media store and signing keys in the same backup set. The check that closes this step is a restore that starts on a scratch database and returns the expected user and room counts. Because rollback from Synapse can be difficult, this backup is your only clean return point.
Stand up Synapse with PostgreSQL and Redis
Install Synapse on a fresh host or container with a new PostgreSQL database, not the restored Dendrite one, because Synapse uses its own schema. Synapse recommends PostgreSQL for production, and recent Synapse releases require PostgreSQL 14 or newer and Python 3.10 or newer, so confirm those versions against the upgrade notes for the release you choose. If you plan to add workers later, provision Redis now so the replication path is ready. Set the same server_name as step one. The output is a Synapse instance that starts cleanly, reports a healthy database connection and accepts a test local account.
Plan the identity provider and reverse proxy
Choose how users will sign in to Synapse. Synapse supports OpenID Connect providers through oidc_providers, SAML2 through saml2_config and CAS, so map your existing directory or identity provider to one of these. Confirm with the identity provider owner which claims will become the Matrix localpart, because a mismatch creates new accounts rather than linking existing ones. Plan the reverse proxy that serves client traffic on port 443 and, if you federate, the federation listener on port 8448 or delegation through port 443. Note that Dendrite does not support MSC3861 next-generation OIDC or MSC4186 sliding sync, so client compatibility for Element X should be retested on Synapse rather than assumed. Write the decision down with the owner's approval.
Test federation and delegation on a staging name
Before pointing real users at Synapse, test federation with a second homeserver you control, using a staging hostname that is not the production server_name. Verify that the federation listener is reachable on port 8448 or that .well-known delegation returns the expected target on port 443. If you need to limit exposure during testing, use federation_domain_whitelist, where an empty list disables federation, and firewall the federation listener as the Synapse documentation recommends. Confirm that a room created on one server can be joined and messaged from the other in both directions. Keep the test results in your change record. You are done when both directions work and the whitelist matches your intended federation policy.
Import or rebuild accounts and rooms
Decide what carries over. Based on the researched facts, the reliable path is to keep the server_name and identity mapping, then recreate accounts through the chosen identity provider so users sign in to Synapse with their existing credentials, and invite or rejoin rooms as needed. Do not assume that Dendrite room state, message history, device keys or media can be copied directly into Synapse's schema. Ask Element or the Matrix community whether a supported data migration tool exists for your Dendrite version and your data volume, and do not run any unofficial script against production data until that answer is in writing. The output is an inventory listing what transferred, what was rebuilt and what users must redo, such as re-verifying devices.
Cut over users and keep the Dendrite backup
Announce a cut-over window to users, point the production client and federation endpoints to Synapse, and sign users in through the agreed identity provider. Watch logs and client errors during the first sessions, and confirm with a sample of accounts that login, room access and sending messages work. Keep Dendrite and its verified backup available until the team agrees the migration is stable. Because Synapse schema changes can make rollback difficult, treat the Dendrite backup as the recovery path and record the decision point in advance. The sequence is complete when the sample checks pass, the inventory is signed off and the rollback owner has confirmed who may restore the backup.
Where Synapse and Dendrite projects usually run long
Most of the overrun in a Matrix homeserver project comes from decisions made late, not from the software itself. Start the database work early: Synapse recommends PostgreSQL for production, and recent releases require PostgreSQL 14 or newer and Python 3.10 or newer, so confirm the versions your platform team can supply before any install. Check the Synapse upgrade notes against your database provisioning, because rolling back can be difficult after schema changes. Dendrite also recommends PostgreSQL, so the same provisioning and version checks apply to both candidates.
The second source of delay is the edge. Both homeservers need a reverse proxy and TLS that serve port 443 for clients and either port 8448 or delegation for federation, and the server_name value fixes how user IDs and room identifiers look for the life of the deployment, so a wrong domain is expensive to correct. Decide federation scope before go-live: federation_domain_whitelist can restrict federation to listed domains, an empty list disables it, and the docs recommend firewalling the federation listener as well. Teams that postpone this question often rework proxy rules, firewall policy and user expectations at the same time.
Identity mapping is the most common late surprise. Synapse can use OpenID Connect, SAML2 or CAS, and mapping directory attributes to Matrix user IDs, display names and admin roles usually takes more discussion than the configuration itself. Worker sizing and Redis, if you scale Synapse out, add another layer to plan, and testing must cover Element X and Element Web against the same build, since Dendrite does not support the sliding sync or next-generation OIDC authentication that Element X relies on. Effort depends on user count, federation scope and integration depth, so ask for each of these to be scoped in writing before estimating the timeline.
Questions buyers ask before choosing or hiring help
What does a Synapse deployment cost to run?
Synapse itself is AGPL-3.0 licensed and free to download, so the recurring cost is the infrastructure and the people who run it. Plan for a PostgreSQL database (Synapse 1.143.0 and later require PostgreSQL 14 or newer), a reverse proxy, storage that grows with media and history, and staff time for upgrades and monitoring. If you add workers, you also pay for Redis and more compute. Element sells commercial Synapse licenses, which carry their own fees and are a separate line item. Ask any quote to split one-time setup from recurring hosting, support and upgrade work, and to name the Synapse version and PostgreSQL version it assumes.
Can our team run a Synapse homeserver ourselves?
A team with Linux, PostgreSQL and reverse proxy experience can run a single-process Synapse, but the work does not stop at installation. Your team must handle TLS, federation settings (port 8448 by default, or delegation to port 443), backups, and each upgrade. Synapse's upgrade notes warn that rolling back can be difficult because of schema changes, so test upgrades on a copy first. Also plan for dropping support when Python or PostgreSQL versions reach upstream end of life. If no one on your team owns these tasks, a fixed-scope implementation or retainer from DeployOpen can cover part of that work, with the split agreed in writing.
How long does a Matrix homeserver implementation take?
No timeline in this page's sources applies to every environment, so treat any duration as a question for the written scope. The main variables are the number of users, whether you need federation, the identity provider you connect (Synapse supports OpenID Connect, SAML2 and CAS), storage and backup requirements, and whether you need workers. DeployOpen works on fixed-scope engagements, so scope, deliverables and timelines are agreed in writing before work starts. Ask for the milestones, the acceptance tests and what happens if the environment differs from the assumptions.
Does Dendrite support Element X?
No. Dendrite's README states that it does not support MSC4186 simplified sliding sync or MSC3861 next-generation OIDC authentication, and both affect the ability to use Element X. Dendrite is also in maintenance mode, with only security fixes applied, and its README describes it as beta software suited to small homeservers of tens or hundreds of users, without high availability or clustering. Its latest release in the sources, v0.15.2, was published on August 15, 2025. If Element X is part of your requirements, confirm this with Element and check the current Dendrite README before you commit.
Can we switch from Dendrite to Synapse later?
Moving from Dendrite to Synapse is possible in principle because both are Matrix homeservers, but the cost depends on your data, your identity setup and your clients. Message history, room state, media and user accounts all need a plan, and the two implementations use different databases and configuration. Keep server_name stable from the start, since it fixes how users and rooms are identified, and document your federation settings, such as federation_domain_whitelist. Ask any partner to state in writing what data they will migrate, what they will not migrate, and how they will verify the result. Test the move on a copy before any user cutover.
What should we ask a partner before hiring help?
Ask for a written scope that names the Synapse or Dendrite version, the PostgreSQL version, the identity provider, the federation policy and the number of users. Then ask what the engagement delivers: installation, configuration, hardening, backups and restore tests, upgrade procedures and documentation. Ask who is responsible for each upgrade after handover, how support is billed, and whether ongoing support is a separate retainer. DeployOpen does not publish a price list, so ask for a quote that follows from that scope, and confirm what is excluded, including client apps, bridges and any commercial Synapse license.
When is Synapse with workers worth the extra effort?
Workers make sense when a single Synapse process cannot keep up with your load, and they add operating work. Synapse scales with worker processes that connect to Redis, which relays replication between processes, so you must run and monitor Redis and route traffic through your reverse proxy. Confirm with your own load tests that the single-process setup is the bottleneck before you split it. For a small, single-server deployment, Dendrite's documentation points to small user counts, while Synapse is the actively developed option, so the decision is usually about how much operating effort you can sustain.
How DeployOpen helps teams choose and implement a Matrix homeserver
DeployOpen helps teams decide between Synapse and Dendrite by first mapping user counts, client requirements and federation needs to the homeserver that fits them. Where the choice is made, we plan, build, document and support the deployment inside your own infrastructure.
How we scope
- Written scope lists the homeserver, database, reverse proxy, identity provider and clients in your environment.
- Scope records which Element clients users need, including whether Element X access is required.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We deploy the chosen homeserver in your cloud account, data center or air-gapped network.
- Federation settings such as server_name, delegation and domain whitelisting are configured and tested.
- Single sign-on wiring to your OIDC, SAML2 or CAS provider is built and verified against test accounts.
How we hand over
- Handover documents the configuration, backup and restore steps, and upgrade procedure for your team.
- Runbooks cover the database schema changes that make rolling back a release difficult.
- Your staff receive a walkthrough so they can operate the deployment without us.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover tracking of Synapse and Dendrite releases and the patching they require.
- Ask any provider to confirm the support window for the homeserver version you choose.
