What does Matrix cost of ownership include beyond the software itself?
The software license is only one line in a Matrix cost of ownership model. The total depends on which homeserver edition you run, how the licensing applies to your use, the infrastructure that hosts it, the PostgreSQL database, media storage, and the staff time needed to run all of it. A finance reviewer or board will want each of these as a separate line with a named owner. Synapse is licensed under AGPL-3.0-or-later and developed by Element, which also sells AGPL exception licenses and includes Synapse Pro in Element Server Suite. Other homeservers, such as Dendrite (AGPL-3.0-or-later) and the Conduit forks (Apache-2.0), change the license and support picture, so the homeserver choice shapes cost before any hardware is bought.
Cost reviews usually start from one of three triggers. The first is choosing between Synapse under AGPL and a commercial edition such as ESS Pro, where the question is whether the licensing terms, support model, and bundled components justify a recurring fee. The second is a move off a SaaS chat tool, where the review compares subscription spend with self-hosted infrastructure, administration, and migration effort. The third is a security review, which may add hardening, logging, and testing work that the original estimate missed. For each trigger, ask who owns each cost line. Is the license purchased by IT, legal, or the business unit? Has the security team costed the time it will take to review the configuration?
Most teams model these costs in-house first, using their own cloud pricing and platform staff hours, and bring in a partner when the scope grows, for example into federation policy, identity integration, or high availability. Split the model into one-time and recurring costs. One-time items include planning, deployment, identity integration, client rollout, and any history migration. Recurring items include compute and storage that grow with users and media, database backups and replication, license renewals, upgrade testing, and administration time. Confirm the recurring items against the upgrade process. Synapse drops support for Python and PostgreSQL versions once they reach upstream end of life, and versions 1.143.0 and later require PostgreSQL 14 or newer, so an upgrade can force an infrastructure change.
DeployOpen does not publish prices. A quote follows from a written scope that sets out the homeserver edition, expected user count, federation policy, identity provider, clients, bridges, hosting location, and the support and upgrade model you expect. Before requesting a quote, ask your cloud or data center team for hosting and storage estimates, ask Element or your legal team whether an AGPL exception applies to your use, and ask your security team which controls they plan to test. Ask any partner to separate fixed-scope implementation from retainer-based support, and to state which assumptions would change the price. Those assumptions are where most cost overruns begin, so write them down before work starts.
What a Matrix cost of ownership review covers
A cost of ownership review turns the Matrix homeserver and edition choice into a set of costed lines with stated assumptions. Each card below covers one part of that work or one deliverable, so the buyer can check the model against their own environment and the vendor's terms.
Homeserver and edition options
The review first fixes which homeserver and license path are being costed, such as Synapse under AGPL-3.0, Element's commercial Synapse Pro or an AGPL exception, Element Server Suite editions, or another implementation such as Dendrite or Conduit forks. Each option carries different license terms, support paths and operating constraints, so each gets its own column in the model. Confirm with the vendor which license applies to your use before comparing totals.
One-time and recurring cost lines
Every cost is sorted into one-time items, such as design, initial deployment, identity integration and data migration, and recurring items, such as compute, PostgreSQL hosting, media storage, backups, license fees and support. Staff time is listed separately so internal effort is visible rather than hidden in infrastructure lines. The split matters because recurring lines drive the multi-year total.
Environment sizing assumptions
Infrastructure lines depend on assumptions about user count, concurrent activity, federation traffic, media volume and retention, and whether workers and Redis are needed. The review records each assumption with a value and the reason for it, so a change in user numbers can be traced to the cost lines it affects. Ask the vendor or your platform team to confirm the sizing inputs before accepting any total.
PostgreSQL and media storage
Synapse's production guidance favors PostgreSQL, and current releases require PostgreSQL 14 or newer, so database hosting, replication and backup are modeled as their own lines. Media storage grows with uploads and retention policy and is often the least predictable recurring cost. The model should state the retention period, the storage backend and who pays for backup copies.
Licensing questions for the vendor
The review produces a list of questions to resolve with the license holder before purchase, covering whether AGPL obligations apply to your modifications and hosting, what an AGPL exception includes, support response terms, and whether professional or government use changes the edition. These questions are written so the answers can be compared against each option. The review does not replace a written vendor quote for commercial licenses.
Upgrade re-check handover note
The handover note lists what must be re-checked at each Synapse upgrade, including Python and PostgreSQL minimum versions, license terms, schema changes that make rollback difficult, and any custom modules or worker setups affected by the release. It also records which cost lines change when a dependency version changes. Your team keeps this note current so the cost model remains accurate after the first year.
How Synapse licensing and editions change the Matrix cost picture
The license of the homeserver you choose determines which costs are avoidable and which you may have to pay. Synapse, the most widely documented Matrix homeserver, is developed by Element and distributed under AGPL-3.0-or-later, with commercial licenses also available from Element. On December 13, 2023, Element announced that its future Synapse contributions would be licensed under AGPLv3, where earlier contributions had been under Apache 2.0. The repositories moved from matrix-org to element-hq on GitHub, and Element began selling AGPL exceptions, with contributors signing a contributor license agreement. Before you budget, confirm with Element which code revisions fall under which license and whether the CLA affects your own contributions or patches. An AGPL exception is a separate commercial license for organizations that cannot or will not meet AGPL obligations. Those obligations apply when you modify the software and make it available to users, including over a network, and they can affect internal patches, custom modules and bridges. Whether you need an exception is a legal question for your counsel, not a technical one. Ask counsel to review how you will run Synapse, whether you will modify it, and who will access it. The exception fee is a recurring or one-time item that appears only in a quote from Element, so request its term, scope and renewal conditions in writing.
Element Server Suite (ESS) packages Synapse with other components and comes in three forms. ESS Community is for non-professional deployments and evaluations. ESS Pro is for professional and government use. ESS TI-Messenger is for German healthcare. According to Element, ESS includes Synapse Pro, Matrix Authentication Service (MAS), LDAP and SCIM integration, and auditing. This bundling can reduce the number of components you assemble and support yourself, but it also means that the tier you select sets the terms you operate under. A professional or government organization evaluating on the Community tier should check that the evaluation does not become production use under those terms. Tier contents, support terms and pricing change over time, so confirm them directly with Element before you compare options. Ask which components, integrations and audit features each tier includes in its current form, what support response commitments apply, whether support covers your Synapse version and dependencies, and how renewals and user-based or deployment-based fees are calculated. Ask whether a quote includes the AGPL exception if you need one. Keep the answers in your written scope so that the cost comparison between Synapse Pro, ESS Pro and an open-source-only deployment reflects the same assumptions.
ESS is deployed on Kubernetes with Helm charts, which changes the staffing profile more than the license does. A Synapse installation on virtual machines or containers can often be run by a small team that knows Synapse and PostgreSQL. An ESS deployment asks for people who can operate a Kubernetes cluster, manage Helm releases, handle persistent storage and maintain ingress, certificates and secrets. Budget for those skills, whether they come from your platform team, from training or from an outside partner. Recurring work includes applying chart updates, testing them against your Synapse version and keeping cluster components patched. Other homeservers change the picture again. Dendrite is also AGPL-3.0-or-later. Conduit and its Rust forks, Continuwuity and Tuwunel, are licensed under Apache-2.0, which may simplify the license review, but you should verify feature coverage, federation behavior and support options for the specific fork you consider. Whichever path you choose, record the license, the support terms and the staff skills required in the same cost model, because a lower license cost does not remove the operational cost of running the platform.
Which factors push Matrix cost up or down
This table lists the factors that most change the cost of running a self-hosted Matrix homeserver, why each one moves cost, and how to keep it under control. Read each row as a question to answer before requesting a quote, and use the confirmation notes to know which figures must come from the vendor or your own environment. The main takeaway is that licensing, load, media retention and identity choices shape the bill more than the software itself.
| Driver | Why it moves cost | How to keep it down |
|---|---|---|
| Homeserver edition and licensing position | Synapse is AGPL-3.0-or-later, so running it unmodified as a service carries different obligations than shipping modified code. Element's AGPL exception licenses, Synapse Pro and Element Server Suite Pro are paid licensing choices that add a recurring line item. Confirm with Element which terms apply to your use. | Decide the edition before design work starts. Ask Element in writing whether your deployment type needs an exception license, and whether ESS Community or ESS Pro fits your use case. |
| User count and concurrent load | Load sets how many worker processes and how much Redis capacity you run. Concurrent sync, sending and federation traffic matter more than total accounts. Sizing figures must come from your own load test or Element guidance, not from this page. | Measure active and concurrent users in a pilot. Start with a small worker layout and add workers only where monitoring shows saturation. |
| Media volume and retention | Uploaded files, images and voice notes accumulate in media storage, and remote media cached from federated servers can grow it further. Storage, backups and replication all scale with it. Retention rules set how fast it grows. | Set media retention and remote media cache limits early. Ask whether your storage platform bills for backups and replicas separately. |
| PostgreSQL sizing and high availability | Synapse recommends PostgreSQL for production, and recent releases require PostgreSQL 14 or newer. Database size grows with rooms and events, and a highly available database adds replicas, failover tooling and backup storage. Confirm minimum versions against the current upgrade notes. | Use a managed or well-supported PostgreSQL service where your policy allows. Plan backup retention and test restores as part of the build, not as a later add-on. |
| Federation policy (open, partner list or closed) | Open federation increases traffic, remote media and moderation effort. A partner list (federation_domain_whitelist) or no federation reduces load and review work, but limits who your users can reach. Closed setups still need firewalling of the federation listener. | Choose the policy with legal and security owners. Start with a partner list if the user base is known, and review the list on a fixed cadence. |
| Identity integration (OIDC, SAML through a bridge, LDAP) | Synapse supports OIDC, SAML2 and CAS directly. Matrix Authentication Service uses upstream OIDC providers and does not support SAML itself, so SAML requires a bridge such as Dex. LDAP and SCIM provisioning may be included in ESS or need separate work. Each extra component adds build and run effort. | Prefer one OIDC path if your identity provider supports it. Confirm with Element which SAML, LDAP and SCIM options apply to your edition before scoping. |
| Number of environments (production, staging, test) | Each environment repeats the homeserver, database, Redis, storage and identity wiring. Staging is needed to test Synapse upgrades, since rollback can be hard after schema changes. Cost scales with every copy, including backups. | Keep staging small but representative. Use the same configuration templates across environments, and automate deployment so extra environments stay cheap to run. |
| Bridges to other platforms | Bridges to Slack, IRC, WhatsApp, Telegram, Signal or email each run as separate services with their own upgrades, credentials and data handling review. Some bridges need ongoing maintenance as third-party platforms change. | Limit bridges to the migration period or to named use cases. Confirm each bridge's maintenance status and licensing before adding it to scope. |
| Compliance evidence requirements | Assessors expect logs, access reviews, change records, backup tests and patch evidence. Producing and retaining this evidence takes internal and partner time every cycle. DeployOpen prepares evidence but auditors and certification bodies issue any attestation. | Agree the evidence list with your assessor before build. Automate log export and configuration capture so evidence is produced as a side effect of operations. |
| Kubernetes or bare-metal hosting choice | Element Server Suite is deployed on Kubernetes with Helm charts, which adds cluster platform cost and skills. A bare-metal or VM layout avoids that platform layer but needs custom process management and upgrade procedures. Confirm which layout your edition supports. | Use the hosting platform your team already operates. Ask for the hosting assumptions in any quote, so platform costs are visible and not buried in the application scope. |
One-time Matrix costs you pay to reach go-live
The one-time costs start before any server exists, with the decisions that determine what gets built. Discovery covers which homeserver and edition you run, whether the AGPL-3.0 terms of Synapse fit your obligations or you need a commercial exception from Element, and whether Element Server Suite Pro is worth its cost for your support and integration needs. Internal architecture staff and your legal team carry most of this work, and the effort rises when several compliance regimes apply or no one owns licensing decisions. Sizing follows from user count, concurrent activity, media volume and expected federation traffic, which together set the number of worker processes, the Redis deployment and the PostgreSQL capacity. Ask any partner for written sizing assumptions so the quote can be checked against your own estimates.
The environment build is usually the largest one-time line. It includes the homeserver installation, a PostgreSQL database on a version that meets the current Synapse minimum (Synapse 1.143.0 and later require PostgreSQL 14 or newer), a media store, a reverse proxy, and the federation listener, whether that runs on port 8448 or is delegated to port 443. Each component needs its own configuration, certificates, backups and firewall rules. Costs rise when you add worker processes with Redis, when media must go to a separate storage backend, or when the network is air-gapped and packages and container images must be mirrored first. In a fixed-scope quote, each component should be named, and the quote should state whether federation is open, limited through federation_domain_whitelist, or disabled.
Identity integration, client rollout and bridges add scope that teams often underestimate. For single sign-on, you pay for the connection to your identity provider. Synapse supports OIDC, SAML2 and CAS directly, while Matrix Authentication Service works with upstream OpenID Connect providers and does not support SAML, so an estate built around SAML may need a bridge such as Dex. Client rollout covers Element configuration, branding, packaging for managed devices and user guidance. Each bridge to Slack, IRC, WhatsApp, Telegram, Signal or email needs its own setup, credentials and data handling review, and the effort multiplies with each platform. Confirm with your identity team which protocol your provider supports before the scope is fixed, because a later change means rework.
Security review and testing, migration of users or history, and documentation with staff training complete the list. The review covers registration controls, admin API exposure, federation restrictions, backup restore tests and patch procedures. Your security team or an independent tester can perform it, and the effort grows with the number of bridges and clients in scope. History migration is often the least predictable line, so decide early whether history moves at all. Training covers the administrators who run upgrades and the users who need to understand encryption and key backup. A one-time line is only one-time if the scope is fixed in writing. Changing federation policy or switching editions after go-live reopens design, configuration and testing work, so those decisions belong in the signed scope.
Recurring Matrix costs after go-live
This table lists the recurring cost lines of a self-hosted Matrix deployment, what each one covers, and what to ask a quote to include. Read it as a checklist: every row keeps running after launch, and the upgrade and staffing rows are the ones most often left out of early budgets. Pay particular attention to the upgrade cycle, because Synapse dependencies change on the vendor's schedule.
| Cost line | What it covers | What to ask a quote to include |
|---|---|---|
| Compute and hosting for homeserver, workers and Redis | Virtual machines or containers for the main Synapse process, worker processes and the Redis instance that relays replication between them | Instance counts and sizes for each worker type, scaling assumptions for your user count, and whether Redis is managed or self-run |
| PostgreSQL hosting, backups and replication | Database servers, storage growth, scheduled backups, restore testing and any standby replica | Backup retention period, restore test frequency, replica placement, and who owns database patching |
| Media storage growth and retention | Storage for uploaded files and images, which grows with usage and continues until retention rules or deletion remove it | Expected growth model, retention and purge policy, storage tier, and how backups of media are handled |
| Load balancing and TLS certificates | Reverse proxy or load balancer in front of client and federation listeners, plus certificate issuance and renewal | Certificate renewal method, who is responsible for renewal failures, and whether federation on port 8448 or delegation on port 443 is included |
| Monitoring and logging | Metrics collection, dashboards, alerting and log retention for the homeserver, workers, database and proxy | Alert routing, log retention period, storage costs for logs, and whether monitoring is included in support or billed separately |
| Edition or subscription fees | Fees for Element's commercial offerings, such as Synapse Pro or Element Server Suite Pro, where your organization needs them. The community edition of Synapse is AGPL-3.0 licensed and carries no license fee from its authors | The exact edition and license terms as stated by Element at the time of quote, whether fees are annual or per user, and what an AGPL exception would change for your organization |
| Upgrade cycle and regression testing | Applying Synapse releases, updating Python and PostgreSQL where needed, and testing workers and clients after each release. Synapse 1.143.0 and later require PostgreSQL 14 or newer, and 1.142.0 and later require Python 3.10 or newer. Synapse drops support for versions past upstream end of life. Plan for releases such as v1.163.0, published October 14, 2026 | Expected upgrade frequency, test environment cost, who performs rollback planning given schema changes between releases, and how dependency end-of-life dates are tracked |
| Staff time for administration and on-call | Internal or partner time for user administration, incident response, capacity reviews and reading upgrade notes before each release | Named roles, hours of on-call coverage, escalation path, and which tasks the vendor or partner handles versus your own team |
| Partner retainer, if used | Ongoing support, upgrades and testing delivered under a retainer agreed in writing | Scope of covered tasks, response expectations, what is excluded, and how out-of-scope work is quoted |
| Bridge hosting, if used | Servers and maintenance for bridges that connect Matrix rooms to Slack, IRC, Telegram, WhatsApp, Signal or email during coexistence or migration | Hosting location, bridge upgrade responsibility, data handling terms, and when bridges are planned to be retired |
How a Matrix cost model gets built, step by step
This sequence turns an open-source Matrix deployment into a cost of ownership model that separates one-time build spend from recurring running costs, with each assumption signed off before the model is handed over.
Define scope and user population
Start by agreeing which users, teams and rooms the deployment must serve, how many accounts are expected at launch and how that number is likely to change, and whether guests, contractors or external partners will hold accounts. The team responsible for chat operations, the business owner of the messaging service and the security lead should all confirm the population. The output is a written scope statement with user counts at launch and expected growth, signed by the business owner. Ask the same questions of any partner you consider, because every later cost line depends on this number.
Confirm edition and license position
Decide which homeserver and distribution the organization will run, such as community Synapse under AGPL-3.0-or-later, Element's commercial options, or another implementation, and record what each option permits. Legal counsel should review whether AGPL obligations apply to any changes you plan to make and whether a commercial exception or support subscription is needed. Confirm with Element or the relevant vendor what their current licensing terms, support tiers and contributor agreements require, since these change. The output is a license memo, signed by legal and the technology owner, that names the edition and the cost lines it creates.
Draw the reference architecture
Map the components the deployment needs: the Synapse main process, any worker processes for client, federation and event traffic, Redis for replication between processes, PostgreSQL as the production database, media storage, the load balancer and the federation listener. Note which components run in the organization's own cloud accounts or data centers and which are managed by a third party. Confirm the supported PostgreSQL and Python versions for the chosen release before sizing anything. The output is a diagram with a component list, signed off by the platform engineering lead, who will carry the running cost of each piece.
Build the one-time cost estimate
Price the work needed before go-live: infrastructure provisioning, the installation and configuration effort, identity integration, client rollout, backup and monitoring setup, security testing and any customization. Separate what your own staff will do from what an implementation partner will be paid to deliver, and state the basis for each estimate. Ask every partner for a fixed-scope quote built from this written architecture, so the lines can be compared directly. The output is a one-time cost table with a named owner and basis for each line, approved by the finance lead.
Build the recurring cost estimate
Model the costs that repeat each year: compute and database hosting for each component, storage for media and backups, licensing or support subscriptions, monitoring tools, and the staff time needed to run, patch and upgrade the platform. Include the upgrade cycle explicitly, covering how often Synapse, Python and PostgreSQL move to new versions, the test effort each upgrade needs, and the effect of schema changes that make rollback difficult. Ask vendors and partners which parts of support and upgrades are included in a retainer. The output is an annual recurring cost table with the upgrade assumptions written out, approved by the operations owner.
Run a sensitivity check on growth and media
Recalculate the model under higher and lower values for user growth, the number of federated servers and rooms, and media upload volume, since these usually drive database, worker and storage costs. Also test the effect of enabling federation with a partner list or opening it widely, because that changes traffic and monitoring needs. Record which inputs move the total most and which ones need a monitored threshold before the cost changes. The output is a sensitivity table with the drivers ranked, reviewed by the platform engineering lead and the security lead.
Sign off and hand over assumptions
Bring the scope, license memo, architecture, one-time and recurring tables and sensitivity results together into one model, and confirm each assumption with its owner in writing. Mark the assumptions that need vendor or legal confirmation before a decision, and set a review point when user numbers or licensing change. Hand the model to the budget holder and the operations team, and keep a copy with the architecture so future estimates start from the same basis. The output is a signed cost model with a dated assumptions register that the business owner, finance and operations have each approved.
Where Matrix cost estimates go wrong
Synapse's license terms are only one line in a Matrix budget. The cards below cover the failure modes that most often make a first estimate too low or too short-lived: infrastructure left out, license assumptions left untested, upgrade and dependency work underestimated, and federation or bridge choices that change after budgets are set. Each card names the check that prevents the error.
Counting the full Synapse stack
Synapse is free to license, but running it is not free. The estimate needs lines for PostgreSQL (the Synapse documentation recommends it for production), media storage that grows with uploads, worker processes and Redis for scaled deployments, plus load balancing and backups. Ask your internal team or partner to list the hosts, storage and backup retention these components need in your environment, and mark which costs recur each month.
Assuming the AGPL position
Element announced on December 13, 2023 that future Synapse contributions would be licensed under AGPLv3, and it sells AGPL exceptions, so the license question has commercial consequences. If your organization modifies Synapse, distributes it, or runs it as a service for users, have counsel confirm what the AGPL requires and whether an exception is needed. Budget that legal review as a one-time line, and confirm the contributor CLA terms if you plan to upstream changes.
Underestimating upgrade and rollback effort
The Synapse upgrade notes warn that rolling back can be difficult because database schema changes between releases may not reverse cleanly. Plan a staging environment restored from production data, a verified database backup before each upgrade, and time to retest clients, workers and bridges after every release. This testing cycle recurs for the life of the deployment, so it belongs in the annual estimate. Request the upgrade runbook in writing before you sign.
Ignoring Python and PostgreSQL end-of-life dates
Synapse 1.142.0 and later require Python 3.10 or newer, and Synapse 1.143.0 and later require PostgreSQL 14 or newer. Synapse also drops support for Python and PostgreSQL versions once they reach upstream end of life, so your operating system and database packages age on their own schedule. Check the support windows for your base OS and PostgreSQL against the Synapse release you plan to run, and budget the dependency upgrades as a recurring item.
Budgeting one federation policy
Teams often size hosts, certificates and support hours for a single federation setting, then change it when a partner asks to connect or a security review objects. Synapse's federation_domain_whitelist limits federation to listed domains, and an empty list disables it. A policy change can also touch server_name, delegation, the choice between port 8448 and port 443, and firewall rules on the federation listener. Decide the policy first, and estimate the rework for a later change.
Forgetting bridges and their data review
Bridges to Slack, IRC, WhatsApp, Telegram, Signal and email run as additional software that needs hosting, credentials, monitoring and upgrades. Each bridge also moves message content between Matrix and a third-party platform, which needs its own data handling review and a check of who maintains the bridge. Ask who will run each bridge, where it runs, what it stores, and how long coexistence is expected to last, then add those hours and reviews to the estimate.
How the cost shape changes by edition and hosting choice
Running the AGPL-3.0 build of Synapse on your own cloud account with in-house operations removes the license line from the estimate, so cost is driven by infrastructure and people. Most of the build cost is one-time: architecture, initial deployment, the database and media design, and the first runbooks. The recurring costs are compute for the homeserver and workers, PostgreSQL, Redis, media storage and the staff time needed to upgrade.
- Licensing: Synapse is distributed under AGPL-3.0, so there is no separate vendor license fee for this path. Ask counsel how the AGPL obligations apply if your team modifies the code.
- PostgreSQL: PostgreSQL is recommended for production, and Synapse 1.143.0 and later require PostgreSQL 14 or newer. Size the database as a recurring line.
- Upgrades: Schema changes between releases can make rollback difficult, so budget staff time for each upgrade cycle and test in a staging copy first.
- Workers and Redis: As concurrency grows, adding workers and Redis adds compute, monitoring and on-call effort.
Check whether your team can keep Python and PostgreSQL current, since Synapse drops support for versions that reach upstream end of life.
Element sells AGPL exceptions and Synapse Pro, so an organization that cannot meet AGPL obligations or wants vendor-backed terms adds licensing as a separate recurring line. The infrastructure, PostgreSQL, media storage and staffing lines keep roughly the same shape as the AGPL path. What changes is the contract, which sets the fee, the support scope and the renewal terms.
- License fee: This is recurring. Ask whether the fee is annual, per deployment or tied to a user band, and what happens to pricing at renewal.
- Legal review: Reviewing the exception terms against your modifications and distribution plans is a one-time cost.
- Support scope: Confirm whether the agreement includes vendor support, response expectations and security advisories. Do not assume these are included.
- Packaging: Confirm whether Pro packaging changes the supported PostgreSQL or Python versions, since that can shift the database and runtime lines.
- Exit: Estimate the cost of returning to AGPL-only operation or moving to another homeserver if the terms change.
Get the license scope in writing before you budget the first renewal, and confirm the renewal date against your planned upgrade calendar.
Element Server Suite deploys on Kubernetes with Helm charts and includes Synapse Pro, Matrix Authentication Service, LDAP and SCIM integration and auditing. ESS Community is free for non-professional deployments and evaluations, while ESS Pro is the edition for professional and government use. The estimate moves from building the homeserver to running a platform, so the cluster and the skills to operate it become recurring costs.
- Cluster: Node pools, storage classes, ingress, monitoring and control plane support are recurring costs. Your platform team may already carry some of these, so confirm what is shared.
- Skills: Staff who manage Helm releases, cluster upgrades and secrets need to be on the team or contracted. This is a recurring people cost.
- Subscription: Confirm which ESS components the ESS Pro terms cover, including any you plan to enable later.
- Identity components: MAS, LDAP and SCIM reduce custom integration work but add services to monitor, patch and back up.
- Upgrades: Chart updates should be tested in a non-production cluster before they reach users.
Check which ESS components your subscription covers and name the team that owns the cluster before you size the platform roles.
Setting federation_domain_whitelist to a list of domains restricts federation, and an empty list disables it. For an air-gapped or closed deployment, this removes federation traffic, public listener work and partner coordination from the estimate. Internal support and offline update procedures rise, because packages, container images and database migrations must reach the isolated network through a controlled process.
- Federation listener: Fewer public-facing listeners and certificates are needed, but the documentation recommends firewalling the federation listener, which still requires configuration and testing.
- Offline updates: A staged transfer process, verified artifacts and a rehearsal for each release are recurring staff time.
- Internal support: Without external federation peers, your team carries all troubleshooting, so plan on-call coverage for users.
- Dependency mirrors: Internal package and image mirrors, and internal identity providers, need their own maintenance.
- Backups: Local backups and restore tests carry the full recovery load because no other server holds copies.
Ask who owns offline update rehearsals and how often they run, since that effort recurs with every release.
Dendrite is licensed under AGPL-3.0-or-later and is developed by Element. Conduit and its Rust forks Continuwuity and Tuwunel are licensed under Apache-2.0. The license line is usually zero, so the cost question moves to feature fit, support and maintenance. Verify those before budgeting, because your SSO setup, bridges, modules or admin workflows may not match what the server provides.
- Feature fit: Check the features your users need, such as SSO options, scaling with workers, admin APIs and federation settings, against project documentation and your own test results.
- Support: Confirm who answers production issues and how security advisories are published for the project you choose.
- Ecosystem: Bridges, clients and integrations may be built for Synapse. Verify compatibility before you commit.
- Proof of concept: Plan a longer evaluation than you would for Synapse, since feature gaps often appear late.
- Migration: A later move to Synapse would require data and configuration work, which belongs in the estimate as a possible one-time cost.
Get written answers on feature coverage and support before you size the platform team or commit to the homeserver.
Matrix cost questions buyers ask before hiring outside help
What drives the cost of running a Matrix homeserver?
Recurring infrastructure, database, media storage and staff time drive most of the cost of running Matrix. The homeserver software is only one line item. Compute depends on user count, message volume, federation traffic and whether Synapse runs with workers and Redis to handle scale. PostgreSQL needs compute, storage, backups and a version that is still supported. Media storage grows with file sharing and your retention policy. Staff time covers administration, upgrades, testing of clients and bridges, monitoring and incident response. One-time costs include design, identity integration, the initial build, load testing and migration. Ask any partner to split quotes into one-time and recurring groups so you can see what continues after go-live.
Does Synapse have a license fee, and when do we need an AGPL exception?
Synapse is distributed under AGPL-3.0, and its documentation notes that commercial licenses are also available from Element. Whether you need an AGPL exception or a commercial edition is a legal and procurement question, not a technical one. The answer depends on how you modify and distribute the software, whether users interact with a modified version over a network, and your internal policies. Element announced on December 13, 2023 that future Synapse contributions would be licensed under AGPLv3 and that it had begun selling AGPL exceptions. Confirm current terms, scope and any fees in writing with Element, and have your counsel review the obligations before you decide.
How long does it take to build a Matrix cost model?
The duration depends on scope, and this page does not give a duration figure. A model for one deployment profile takes less time than one that compares several homeservers, federation options and hosting locations. The number of user groups, identity integration choices, hosting constraints and the number of cost scenarios all change the effort. Ask for a phased plan that lists the inputs, the assumptions register, the vendor quotes that will be checked and the written deliverables. Fixed-scope engagements have their scope, deliverables and timeline agreed in writing before work starts, so the schedule should follow from the scope you approve.
What information must we give a partner before a Matrix cost estimate?
Provide user counts, federation policy, identity provider, hosting constraints and named owners. User counts should separate groups, show expected growth and describe peak concurrent use. Federation policy determines whether you run closed, with partner domains, or open, which changes traffic, exposure and data control. The identity provider decides whether you use OIDC, SAML, CAS or LDAP and whether Matrix Authentication Service is part of the design. Hosting constraints include the cloud account, data center or air-gapped network, data residency rules and backup location. Owners should be named for approvals, on-call coverage, data retention and bridge decisions, because these roles drive the staff time in the model.
Can our own team build a Matrix cost model without outside help?
Yes. A team with infrastructure, database and security skills can build a cost model using a written checklist and vendor quotes. Start by listing one-time and recurring cost groups, then collect quotes for compute, PostgreSQL, storage, support and staff time. Build at least two scenarios, such as a small closed deployment and a larger deployment with federation, and record every assumption. An engineer should review worker, database and media sizing, since those estimates are often the least certain. Your own load tests and vendor quotes replace the assumptions in the model. Outside help can shorten the work and bring experience from other deployments, but the model remains yours to approve.
What recurring work follows a Matrix go-live?
Recurring work covers upgrades, dependency changes, testing, administration and incident handling. Synapse releases change often, and the upgrade notes warn that rolling back can be difficult because database schemas change between releases. Synapse also drops support for Python and PostgreSQL versions once they reach upstream end of life, so you need a schedule for dependency updates. Each upgrade requires testing workers, federation, clients, bridges and any custom modules. Administration covers user lifecycle, room and media policy, backup verification, monitoring and capacity reviews. Security patching and periodic review of registration and federation settings also recur. Assign named internal owners for these tasks, and confirm in writing what any support retainer covers.
How does Element Server Suite Pro change staffing compared with running Synapse directly?
Element Server Suite Pro packages Synapse Pro, Matrix Authentication Service, LDAP and SCIM integration and auditing, and it is deployed on Kubernetes with Helm charts. Running Synapse directly means your team assembles and operates the homeserver, PostgreSQL, workers, Redis, identity configuration and media settings, and tracks each upgrade yourself. ESS Pro moves more of the integration and packaging into the product, but your team still runs the cluster, the data, the identity setup and the users. Staffing needs therefore shift toward Kubernetes operations and on-call coverage, while the licensing terms with Element determine what is included. Confirm in writing which tasks Element supports, which tasks you operate, and the skills and hours your side requires.
How DeployOpen works on this
DeployOpen approaches Matrix cost of ownership and editions as a written, fixed-scope review of the license, infrastructure, database, media storage, and staffing lines that your own environment will carry. The output is a cost model you can check against vendor quotes and your internal budget before any build work starts.
How we scope
- Confirm which homeserver options are under review, such as Synapse, Dendrite, or a Conduit-family server, and the licensing terms that apply to each.
- Agree in writing which cost lines are in the model: infrastructure, PostgreSQL, media storage, support, and internal staff time.
- Record the assumptions the model depends on, including expected user count, federation policy, and hosting location, so each figure can be traced.
How we build
- Build a one-time and recurring cost table that separates license purchases, implementation labor, and ongoing operations for each option.
- Check the model against the platform requirements in the current Synapse upgrade notes, including supported PostgreSQL and Python versions.
- Document where Element Server Suite or an AGPL exception license would change the license line, and what it would not change.
How we hand over
- Deliver the cost model as a spreadsheet and a written summary that your finance and IT leads can review and adjust.
- Provide a list of questions to ask each vendor for a quote, covering support tiers, license scope, and upgrade terms.
- Walk your team through the assumptions and the drivers that move each cost up or down, so the model stays usable after handover.
How we support
- Offer ongoing support as a retainer if you want the cost model refreshed when Synapse releases, license terms, or your user count change.
- Re-run the model before major upgrades, since database and runtime requirements can change the infrastructure line.
- Keep the scope fixed for each review, and agree any follow-on work, such as an implementation plan, in a separate written scope.
