Matrix implementation plan and cost

Matrix implementation at a glance

A Matrix implementation puts an open communication protocol, a homeserver, identity, and client applications inside infrastructure you control. The first decision is which homeserver to run. Synapse is the most widely documented option and is developed by Element under AGPL-3.0, with commercial licensing also available from Element. Dendrite and the Conduit family are alternatives, but their feature coverage and operational tooling differ, so confirm each against the features your users need before the project is scoped.

Most projects start with a trigger. Common ones are replacing a consumer or commercial chat tool, meeting a compliance requirement that calls for controlled message storage, or meeting a data residency mandate that rules out hosted services outside a given jurisdiction. The trigger shapes the rest of the plan: it determines which user groups move first, whether federation is needed at all, and how much retention and audit evidence the project must produce. Write the trigger down in the scope before choosing a homeserver.

Teams usually split the work between their own staff and a partner, and the answer depends mainly on existing skills. Running Synapse well means operating Kubernetes or another container platform, PostgreSQL, and an identity provider that your users already sign in through. If those skills are strong in-house, a small internal team can often build it. If any of them is thin, a fixed-scope partner engagement usually covers the gaps faster. Ask your team to rate each skill before deciding.

What the implementation includes

A fixed-scope Matrix engagement is split into work packages, each with a named deliverable. The written scope fixes which packages apply to your environment before any build work starts.

Requirements and homeserver decision record

We document user counts, data residency, federation expectations, retention and client needs, then record the homeserver choice in a decision record. Synapse, Dendrite, Conduit-family servers and Element's commercial options differ in licensing and support, so the record should state why the choice fits your obligations. Deliverable: a signed decision record.

Architecture for homeserver and database

We design the topology for the chosen homeserver, including the database layout, media storage, reverse proxy, DNS and certificates, and whether workers are needed from the start. Synapse documentation recommends PostgreSQL for production, and recent Synapse releases require PostgreSQL 14 or newer, so confirm your database platform early. Deliverable: an architecture document with diagrams.

Deployment and configuration

We install the homeserver in your infrastructure and set server_name, registration controls, media limits and listener configuration to match the decision record. The work covers the configuration files, secrets handling and a tested start-up sequence. Deliverable: a running environment in your accounts or data centers with documented configuration.

Identity integration at the integration level

We connect the platform to your existing identity provider using the method chosen in the decision record, such as OIDC through Matrix Authentication Service or Synapse's SSO options. This package covers the integration points, claim mapping and test sign-ins, not a redesign of your directory. Deliverable: a tested sign-in flow and integration notes.

Client rollout plan

We define which clients your users run on each platform, how they are configured and how users are onboarded, including any branding or policy settings agreed in scope. The plan covers pilot groups, support paths and rollback steps for client changes. Deliverable: a rollout plan with a pilot checklist.

Bridge decision (in or out of scope)

We record whether bridges to Slack, Teams-era channels, IRC or other platforms are in scope, and if so, which bridge and which rooms it touches. Bridges move message content into third-party systems, so the record must state the data handling terms. Deliverable: a bridge decision record, with build work only where it is marked in scope.

Monitoring and backup baseline

We set up health checks, log collection, alert rules and a backup schedule for the database and media store, then test a restore. Synapse upgrade notes warn that rollback can be difficult after schema changes, so backups taken before upgrades matter. Deliverable: a monitoring dashboard, alert list and a tested restore record.

Handover

We transfer runbooks, configuration, credentials handling, admin procedures and the upgrade approach to your team, then walk them through the operational tasks. Ongoing support, upgrades and testing are available as separate retainers rather than included by default. Deliverable: a handover pack and a recorded admin walkthrough.

What drives cost and duration

This table lists the decisions that most change Matrix implementation effort, why each one matters, and how to keep it manageable, so you can ask a partner for a quote that reflects your actual scope.

Driver	Why it changes effort	How to keep it down
Homeserver choice	Synapse has the most documentation and operational guidance, and Dendrite and the Conduit family (Conduit, Continuwuity, Tuwunel) have different feature coverage, tooling and upgrade histories. Each choice changes testing, runbooks and the skills your team needs.	Pick the homeserver against your feature list before design starts. Confirm current feature support and release status with each project rather than assuming parity.
Expected user count and concurrency	Higher user counts and busier rooms push work into worker processes, Redis, PostgreSQL tuning, media storage and load balancing. Capacity testing and high availability design grow with these numbers.	Agree a realistic initial user population and growth plan in writing. Start with a single-site layout and add workers only when load testing shows the need.
Federation policy	Open federation needs public DNS, delegation, port 8448 or 443 handling and abuse controls. Restricted federation with a domain allowlist or no federation needs firewalling and documented partner lists, which are simpler to test but still need design.	Decide the policy in the first phase. Keep it closed or allowlisted unless users truly need external contact, since changing it later affects server naming and trust settings.
Identity integration	OIDC through Matrix Authentication Service or Synapse's built-in OIDC support is well documented. SAML needs a bridge such as Dex because MAS does not support SAML, and LDAP adds directory mapping, provisioning and attribute rules.	Use your existing OIDC provider where possible. Ask for a written list of attributes, group mappings and deprovisioning rules before build.
Client platforms and branding	Each client platform (web, desktop, iOS, Android) needs testing, configuration, distribution and branding work. Custom Element builds add build pipelines and update cadence.	Limit the initial set of supported platforms. Use standard Element clients with configuration changes before custom builds.
Bridges to third-party platforms	Bridges to Slack, IRC, WhatsApp, Telegram, Signal or email each run as separate services with their own accounts, data handling and upgrade cycles, and often need legal and policy review.	Limit bridges to the transition period or to named use cases. Confirm each bridge's maintenance status and data flows before committing.
Number of environments	Each environment (test, staging, production, disaster recovery) repeats installation, configuration, backups and upgrade rehearsals. Keeping them aligned is ongoing work.	Use infrastructure as code and one configuration source for all environments. Agree how many environments you truly need.
Compliance evidence needs	Assessors may ask for access reviews, change records, encryption and key backup settings, logging, retention and patch evidence. Collecting this evidence adds design and documentation time.	Define the controls and evidence formats at kickoff. Note that DeployOpen prepares evidence but auditors issue any assurance reports.
Edition choice: community or Element Server Suite	Community deployments rely on your team for packaging, support processes and licensing review. Element Server Suite brings Kubernetes charts and integrations such as LDAP and SCIM, with its own licensing and support terms.	Compare the editions against your identity, support and license needs. Ask Element to confirm current licensing terms and eligibility in writing.

Project phases and outputs

The sequence moves from agreed requirements to a tested Matrix deployment that users, administrators and the internal team can run after handover.

Confirm requirements and federation stance
DeployOpen and your team define user count, sites, retention needs, clients, bridges and whether the server will federate openly, with partner domains only, or not at all. Your security and compliance leads confirm data residency and identity requirements. The output is a written requirements list that the rest of the plan references, and the phase closes when your sign-off is recorded in the scope document.
Choose the homeserver and edition
Using the requirements, the team compares Synapse with other Matrix homeservers and decides whether to use the AGPL-licensed community distribution or a commercial option, including whether Element Server Suite components are needed. The output is a short decision record covering licensing, support obligations and the upgrade path, reviewed by your legal and procurement contacts before any build begins.
Design architecture and size the platform
The team sets the topology: single process or workers with Redis, PostgreSQL placement and backups, media storage, load balancing and the reverse proxy. For current Synapse releases, confirm PostgreSQL 14 or newer and Python 3.10 or newer against the version you select. Sizing follows user count, activity and media use. The output is an architecture document and a sizing sheet reviewed by your platform team.
Build the environment
Infrastructure is provisioned in your cloud accounts, data centers or private network, with DNS, certificates, server_name and delegation set, and the federation listener firewalled according to the stance chosen earlier. Backups are configured and a restore is tested. The output is a running non-production environment with a documented build and a passing restore test.
Configure and integrate identity
Synapse or Matrix Authentication Service is configured for your identity provider, with registration controls, admin accounts, retention settings and any bridges enabled. Provisioning and deprovisioning steps are tested with test accounts. The output is a configuration baseline in version control and a test log showing sign-in, role assignment and account removal working as designed.
Run a pilot with a small group
A limited group of real users works through agreed scenarios on the chosen clients, including encrypted rooms, file sharing, notifications and mobile use. Issues are logged, fixed and retested. The length of the pilot depends on how many scenarios are in scope and how quickly your users can test. The output is a signed pilot report listing open defects and accepted risks.
Cut over to production and hand over
The production environment is promoted from the tested baseline, users are onboarded, and monitoring and alerting are switched on. DeployOpen then transfers runbooks, admin procedures, upgrade notes and the support model to your team, and records what remains with you or a retainer. The output is a live service, a handover pack and a completed acceptance record.

What to keep in-house and what to outsource

This table compares each Matrix work package with the skills it needs and whether your team can cover them today, with notes on where a partner adds value and where your organization must own the decision.

Work package	Skills needed and who usually carries it	Can your team cover it today?	Where a partner adds value or you must decide
Architecture and decisions	Homeserver choice, server_name, federation policy, identity model and data residency decisions; usually an architect with security and compliance input	Often partly. Confirm someone owns the written decision record before build starts	Partner: fixed-scope design workshop and options paper. You must own: federation policy, retention and who is an admin
Container or Kubernetes platform	Kubernetes operations, Helm charts, ingress, persistent volumes and Redis for workers; usually a platform engineering team	Depends on existing cluster experience. Confirm whether an on-call rota already covers the cluster	Partner: second pair of hands during first deployment. You must own: cluster ownership and upgrade windows
PostgreSQL administration	Schema management, backups, point-in-time recovery, connection handling and major version planning; usually a DBA or platform team	Check whether your DBAs have run PostgreSQL 14 or newer for Synapse specifically	Partner: sizing and backup restore test. You must own: backup retention and restore sign-off
Identity administration	OIDC or SAML client registration, group mapping, provisioning and deprovisioning of users; usually the identity team	Often yes for OIDC. SAML and LDAP paths need confirmation against your identity provider	Partner: integration build and test accounts. You must own: which groups may join rooms and who may register
Client packaging	Element or other client builds, branding, distribution to managed devices and version pinning; usually endpoint or desktop engineering	Usually limited. Confirm how clients reach staff devices today	Partner: packaging and rollout guide. You must own: which clients are approved and the update policy
Bridge operation	Bridge hosting, credentials for third-party platforms, data handling review and bridge upgrades; usually an application owner with security review	Rarely. Bridges add a separate service with its own failure modes	Partner: bridge build and data flow review. You must own: whether any bridge is allowed and which rooms it may reach
User communication	Onboarding guides, support channel, change notices and training; usually internal communications with the service owner	Often yes, if a service owner is named	Partner: draft guides and rollout checklist. You must own: messaging about data retention and what users may share
Day-two operations	Monitoring, patching, Synapse release tracking, incident response and user support; usually a service team with on-call coverage	Confirm named owners and an on-call rota before committing to a go-live date	Partner: retainer for upgrades and testing. You must own: patch approval, incident authority and the support scope you pay for

What usually goes wrong

Most Matrix projects that stall or need rework trace back to a small set of early decisions made under time pressure. Each card names the pattern and the check that prevents it.

Choosing a homeserver too early

Teams often pick Synapse, Dendrite or another homeserver before they know their user count, retention needs or federation policy. Those inputs shape database sizing, worker layout and licensing, so a choice made first can force a rebuild later. Confirm user numbers, federation stance and support needs in writing, then select the homeserver against them.

Setting server_name without a plan

The server_name fixes how user IDs such as @user:example.com and room identifiers are formed. Changing it after users and rooms exist is effectively a new identity space, so it is hard to undo. Confirm the domain with the naming and DNS owners, decide on delegation for port 443 or 8448, and document the value before any account is created.

Leaving federation on by default

Federation is a policy decision about who your users can talk to and what data leaves your network, not a technical detail. Leaving it enabled without a decision exposes the deployment to traffic and servers you did not approve. Record whether you will federate openly, with listed partner domains, or not at all, then set the allowlist and firewall the federation listener to match.

Picking an identity provider before SSO is confirmed

Selecting Keycloak, Entra ID or another provider before checking which login path the chosen Matrix component supports can leave SAML-only or LDAP-only directories without a route. Matrix Authentication Service does not support SAML directly. Confirm the protocol your directory offers, then verify the Synapse or MAS path with a test login before committing.

Underestimating admin time after go-live

Launch is not the end of the work. Account lifecycle, room administration, moderation requests, client updates and homeserver upgrades all draw on internal staff. Budget named admin hours per month during the planning phase and agree who handles tier-one requests, so the cost appears in the plan rather than as an unplanned burden on the platform team.

No staffed owner for clients and bridges

Element clients, mobile apps and any bridges to Slack, Teams or other platforms each need someone responsible for their versions, configuration and failures. Bridges in particular carry data handling questions and their own upgrade cycles. Assign a named owner for each component during planning and include their time in the operating model.

Upgrades that cannot be rolled back

The Synapse upgrade notes warn that rolling back can be difficult because releases change the database schema, and that support for Python and PostgreSQL versions ends with upstream end of life. Before each upgrade, take a tested database backup, read the release notes for schema and dependency changes, and rehearse the upgrade on a copy of production.

How the work changes by starting point

Illustrative case: a team leaving a commercial chat product that already has a corporate identity provider. Identity design shrinks because the provider exists, while migration and onboarding grow.

Grows: migration planning, bridges during the transition, and decisions on history import or archive.
Shrinks: identity design, once you confirm the provider supports OIDC or SAML and which path (Synapse SSO or Matrix Authentication Service) fits.
Main drivers: how many users move in each wave and how much history must stay searchable.
Confirm: whether your provider can supply display names and whether deprovisioning reaches the homeserver.

What you need to provide

Before implementation starts, the client supplies a short list of named decisions, accounts and access. The most important is a named business owner who accepts the Matrix rooms, user population and retention rules as their responsibility, and an accountable technical owner who approves the homeserver choice, the database standard and the production change process. Without both names in writing, scope questions stall because nobody can sign for them.

Federation policy and user numbers are the decisions that shape the build most. The business owner signs off whether the server federates openly, with a list of partner domains via federation_domain_whitelist, or not at all. The technical owner signs off the target user count, a growth forecast for the next two to three years, and the expected number of concurrent rooms and media uploads. Confirm the server name and whether port 8448 or delegation on port 443 is allowed through your network, because changing server_name later is difficult.

Provide identity provider details and admin access early: the OIDC or SAML metadata, the claim names used for user IDs and display names, and a service account for Matrix Authentication Service or Synapse configuration. Also provide cloud or data center accounts, DNS zone control, and certificate authority access for the server name and any delegation record. Name the team that holds a database and backup standard, including retention and restore test frequency, and give the security team a review slot before go-live.

Plan internal admin time before go-live rather than assuming it appears later. Daily user support, room governance questions and client updates usually fall to a small group, and that group should be named, trained on the admin tools and given written escalation paths. Ask the implementation partner to quote training and handover hours separately, and confirm with your own HR and governance leads how much weekly time those roles can give during the first months.

Frequently asked questions

What drives the cost of a self-hosted Matrix deployment?

The main cost drivers are the homeserver you choose, the number of users and rooms, your federation policy, identity integration, client customization and bridges. Each one changes the infrastructure, the PostgreSQL sizing, the media storage and the amount of design and testing work. Build labor is one-time, while administration and upgrades recur. Ask every quote to split these items, state the user count and federation choice in writing, and separate one-time build work from ongoing support.

How long does a Matrix implementation take, and what changes the timeline?

Scope sets the duration. A single homeserver with one OIDC provider and default clients is a much smaller job than a deployment with workers, SAML through a bridge, custom Element branding and a bridge-based migration. Timelines belong in the written, fixed-scope plan once the open decisions are closed. Ask for the phase list, the dependencies between phases and the decisions that must be made before the build begins. Treat any duration given without a scoped plan as an estimate to verify.

Can a small IT team run Matrix without outside help?

A small team can run a basic homeserver alone, but the ongoing work is mostly PostgreSQL care, upgrades, backups and identity. Synapse upgrade notes warn that rollback can be difficult because of database schema changes, and that support is dropped when Python or PostgreSQL reach upstream end of life. Teams without these skills in-house, or teams planning workers, high availability or strict federation controls, usually benefit from a partner for the design and the first upgrade cycles. Confirm your team's skills before deciding.

How much internal administration time should we budget for Matrix?

Name one administrator who owns upgrades, user lifecycle, moderation policy, backups and monitoring, with a clear on-call path for outages. The effort varies with user count, identity provisioning, the number of clients and bridges, and how often you apply releases. Synapse publishes regular releases, so schedule a recurring upgrade window and rehearse it in staging with a copy of the database. Ask the partner to show administration effort as a separate line in the quote, based on your environment.

Why does the choice of homeserver affect cost?

The homeserver determines the license terms, the database model, the scaling approach and the support options you can buy. Synapse is the most widely documented option, is licensed under AGPL-3.0-or-later, and has commercial licenses and Element Server Suite editions available from Element. Dendrite and the Conduit-family servers differ in feature coverage, documentation and operating experience. An option that looks inexpensive at install can cost more later if a feature you need is missing or your team cannot find the knowledge to run it. Compare candidates against required features, license obligations and support before the build starts.

Do bridges add scope to a Matrix project?

Yes. Each bridge to Slack, IRC, WhatsApp, Telegram, Signal or email adds its own hosting, credentials, data handling review and user communication, and it needs testing during and after migration. Bridges can support coexistence while teams move, but they also copy messages into a second platform, which raises retention and confidentiality questions. Ask the partner to list each bridge, its runtime, the rooms in scope and the planned end of coexistence before agreeing on a fixed scope.

How DeployOpen scopes and delivers Matrix work

DeployOpen plans and delivers Matrix work as a fixed-scope engagement in infrastructure you control, with the homeserver choice, federation policy and identity design settled in writing before any build starts. The same written scope then sets what gets built, tested, documented and handed over.

How we scope

We confirm the homeserver candidate, such as Synapse, Dendrite or Conduit-family servers, against your licensing and support requirements.
We record expected user count, federation policy and identity source so the cost drivers are visible in the written scope.
We list clients, bridges and internal administration roles, and state which items are out of scope for the engagement.

How we build

We deploy the chosen homeserver with PostgreSQL, media storage and reverse proxy configuration in your cloud accounts or data centers.
We wire single sign-on through your identity provider and test user provisioning, logins and account deactivation end to end.
We configure federation controls, listener firewalling and registration settings, then test them against the policy you approved.

How we hand over

We document the deployed architecture, configuration decisions, backup and restore procedures, and the upgrade path for your team.
We run a handover session with your administrators covering routine tasks, user onboarding and incident steps.
We deliver the written record of what was built, tested and left for your team to operate after the engagement closes.

How we support

We offer ongoing support, upgrades and testing as a retainer, scoped separately from the implementation work.
We plan Synapse and dependency upgrades with you, including checks on PostgreSQL and Python version requirements before each change.
We confirm with you which support tasks stay internal and which move to the retainer, so the recurring cost is known up front.