Matrix for the public sector

Why Matrix for the public sector starts with data control

Public bodies need internal chat that they can run, audit and restrict to approved parties. Self-hosted Matrix answers that need because the homeserver, its database, media store and logs run in infrastructure the agency or its operator controls, and the agency decides which other servers its users can reach. This page covers two routes. The first is Element as the chat client inside openDesk, the Kubernetes-based workplace suite for public administration. The second is ESS Pro, the Element Server Suite edition for professional and government use. The route you pick shapes how much of the surrounding stack you adopt, so decide it early rather than after the pilot.

Self-hosting changes who owns three decisions that a hosted service would otherwise make for you: the federation policy, the identity integration and the operating model. Federation comes first. In Synapse, the federation_domain_whitelist setting restricts federation to listed domains, and an empty list disables federation entirely. An agency that needs only internal chat may choose the empty list, while one that works with partner bodies will list those domains explicitly. Either way, the decision must be written down, approved by the data owner and matched by network rules, since the Synapse documentation recommends also firewalling the federation listener. Changing the list later changes which conversations are possible, so treat it as a governed change.

Identity is the second decision. Users should sign in with the agency's existing directory rather than with local Matrix passwords, so that account creation and removal follow the same process as other systems. Synapse accepts OpenID Connect, SAML2 and CAS for single sign-on. Matrix Authentication Service, the OAuth 2.0 and OpenID provider for Matrix, uses upstream OpenID Connect providers and does not support SAML directly, so a SAML or LDAP estate needs a bridge such as Dex. In openDesk, identity is handled by Nubus, and the openDesk documentation covers federation with an external identity provider. Confirm which path fits your directory, and name the owner of deprovisioning when a staff member leaves.

The third decision is the operating model: who runs the homeserver, PostgreSQL, Redis, workers, backups and upgrades, and who is on call when a conversation fails. The Synapse documentation recommends PostgreSQL for production, and its upgrade notes warn that rolling back can be difficult because of schema changes between releases. Upstream also drops support for Python and PostgreSQL versions once they reach end of life, so platform upgrades arrive on a schedule the agency does not set. In openDesk, only the latest minor version is supported, and in-place upgrades between major versions are not guaranteed. Before assuming a internal team can absorb this work, ask Element or ZenDiS what support the ESS Pro or openDesk Enterprise Edition contract includes.

Before a pilot, write four things down: the federation list and its approver, the identity source and deprovisioning owner, the named upgrade and on-call owner, and the evidence the agency will need to show an assessor how chat data is controlled. Mapping those decisions to the control catalog the agency already uses, such as the NIST SP 800-53 Rev. 5 controls in its baseline, gives reviewers a concrete starting point. DeployOpen can prepare the configuration and evidence for that review, but the assessment itself is performed by the agency's independent auditors or certification bodies. These four records determine whether self-hosting gives the agency control or simply moves its risk somewhere less visible.

Public sector requirements that shape a Matrix build

This table lists the public sector requirements most likely to shape a Matrix build, one row each, with the source, the deployments it reaches and what it means for hosting, encryption, identity and accessibility. Read each row as a question for your authorizing official, legal team or assessor, since applicability depends on the body's mandate, data and contracts. The main takeaway is that where data is stored, who can reach it and what the clients expose will decide most of the design.

Requirement	Source and where it applies	What it means for the Matrix build
NIST SP 800-53 baselines	Federal control catalog. SP 800-53B sets low, moderate and high baselines of 149, 287 and 370 controls.	Set the baseline with the authorizing official before design. It drives access control, audit logging and encryption for the homeserver, MAS and database.
FISMA oversight	Applies to federal agency systems. Inspectors General independently assess agency security and report to OMB.	Expect independent reviews of control evidence. Keep configurations, access reviews and logs exportable from day one.
FedRAMP scope	FedRAMP Authorization Act (Pub. L. 117-263) and OMB M-24-15. Covers cloud services handling federal information.	Deployed for one agency in its own cloud account, it may be out of scope. A shared service is in scope. Confirm with the agency.
CJIS Security Policy	FBI CJIS Security Policy v6.1, effective 26 June 2026. Applies to systems handling criminal justice information.	Encrypt CJI at rest and in transit outside physically secure locations with FIPS 140-3 modules or AES-256. Scan for vulnerabilities at least monthly.
CUI safeguards under NIST SP 800-171	32 CFR 2002.14(h)(2) requires NIST SP 800-171 for CUI on non-federal systems unless the category prescribes other safeguards.	Chat that may carry CUI brings the homeserver, clients, bridges and admin paths into scope. Document each one in the system security plan.
WCAG 2.1 for web and mobile content	ADA Title II rule (28 CFR 35.200): WCAG 2.1 A and AA from 26 April 2027 for entities serving 50,000 or more people.	Test Element clients and custom widgets against WCAG 2.1 AA before rollout. Include any mobile app the body provides through a contract.
NIS2 for public administration	Directive (EU) 2022/2555. Covers central government entities of any size. Member States may extend it to local administration.	Adds risk management and incident reporting duties. Check whether the body's functions fall under the exclusion for defense, security and law enforcement.
GDPR transfer rules	GDPR Articles 44 to 49 and EDPB Guidelines 05/2021. Any transfer outside the EU counts, including remote access from a third country.	Keep data, backups, logs and support access inside the EU or an approved destination. Put remote support from third countries into the transfer assessment.
CLOUD Act exposure	18 U.S.C. 2713, added 23 March 2018. Requires US providers to preserve or disclose data in their control, wherever it is stored.	Relevant if a US-headquartered provider hosts, operates or supports the stack. Assess that exposure before engaging the provider.

How openDesk fits Matrix for the public sector deployments

If your public body plans to run Matrix through openDesk, the chat component arrives inside a larger stack. openDesk bundles Element with Nordeck widgets for chat, alongside Nextcloud for files, OX App Suite for groupware, XWiki, OpenProject, Jitsi and Collabora as the web office. The Helmfile and Helm automation deploys these components together, so the Matrix design cannot be settled in isolation. Decide early whether you will adopt the full suite or only the Element component, because the cluster prerequisites, identity model, external services and upgrade cadence apply to the whole stack. Confirm with ZenDiS or your integrator which Matrix settings openDesk sets for you and which ones your team must own, such as retention, media handling and federation policy.

Start the platform check before the Matrix design. openDesk requires a CNCF-certified Kubernetes cluster at v1.33 or later, an ingress controller (haproxy-ingress, or the deprecated Ingress nginx), cert-manager, an RWO volume provisioner, Helm 3.17.3 or later below v4 and Helmfile 1.0.0 or later. The stack is tested on kubespray clusters and not on OpenShift, so an OpenShift estate needs a decision before any Matrix work begins. The evaluation minimum of 12 x64 CPU cores, 32 GB of RAM and more than 10 GB of disk is a starting point for a test environment only. Production sizing depends on your user count, call volume and retention targets, and you should ask for that sizing guidance in writing.

For production, openDesk expects external services that you must run, back up and patch under your own controls. The list includes PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. The TURN server matters for calls, and the database versions must be checked against your existing database standards and support windows. Ask the openDesk maintainers which of these services each bundled component uses directly, because Matrix may depend on only a subset. Record the owner, backup method and restore test for each service before the platform is accepted, since a missing service will block the chat component even when the Kubernetes layer is healthy.

ZenDiS recommends openDesk Enterprise Edition for production. It keeps the open-source core licenses but adds closed-source modules, an Enterprise-only registry and license file, and SLA-backed 2nd and 3rd level support and patches, sold as SaaS or for on-premises installation. The Enterprise-only features that touch Matrix include Element AdminBot, GroupSync and the Admin Console, which bear on user administration and directory alignment. License and support fees recur, while the platform build and integration work is usually a one-time effort. When requesting a quote, ask for the license, support, SaaS or on-premises hosting, and any integration work as separate lines, and confirm which Matrix features the Enterprise tier changes.

Plan upgrades before go-live, not after. openDesk plans major releases annually in Q3, minor releases monthly and patch releases on demand. Only the latest minor version is supported, in-place upgrades between majors are not guaranteed, and skipping several minor versions may require intermediate steps. The latest release at research time was v1.19.1, published on 2026-10-06, but the team must confirm the current release and its upgrade path with ZenDiS or your Enterprise Edition provider before any planning. Because the Synapse component also has its own upgrade constraints, record both upgrade paths in one calendar and test them in a non-production environment first.

Which Synapse settings matter most for government messaging

Government Matrix deployments depend on a small set of Synapse settings that are costly to change after launch. The cards cover the identity and network decisions made at install time, the database and worker choices that set operating limits, and the Element Server Suite components that add directory sync, SSO and audit support. Each card names what to decide and what to verify before go-live.

Fix server_name before any user joins

The server_name setting becomes part of every user ID, such as @user:example.com, and it is embedded in room identifiers. Once accounts and rooms exist, changing it means rebuilding identities and history, so treat it as a permanent decision. Agree the value with your DNS, certificate and domain owners before the first install. Verify that the configured name matches the domain your users will sign in with, and that it matches the names used in your delegation records.

Choose delegation over port 8448

Synapse federates on port 8448 by default. Delegation lets the server that answers for your domain run on a different host and still serve user IDs through port 443, so federation traffic can follow the same reverse proxy and firewall rules as your web services. Decide with your network team whether port 8448 can be opened at all. Verify delegation with a federation test run from outside your network, and confirm that the federation listener is firewalled as the Synapse documentation recommends.

Run PostgreSQL at a supported version

Synapse documentation recommends PostgreSQL for production, and SQLite is also supported. Synapse 1.143.0 and later require PostgreSQL 14 or newer, and 1.142.0 and later require Python 3.10 or newer. Decide the database version together with the Synapse release you plan to run, and plan for upstream end-of-life dates, because Synapse drops support for versions that reach end of life. Verify the version before each upgrade and test that a backup restores cleanly, since rolling back after schema changes can be difficult.

Scale with Redis and workers

Synapse spreads its load across worker processes. The main process and every worker connect to Redis, which relays replication between them, and the generic worker handles client, federation and event traffic. Decide whether you need workers from measured load on a pilot, not from projected user counts alone. Size Redis for the replication traffic your layout creates. Verify that every worker can reach Redis and the main process, and test what happens when Redis fails, since it becomes a shared dependency for the whole deployment.

Restrict federation with a domain allowlist

The federation_domain_whitelist setting limits federation to the domains you list, and an empty list disables federation entirely. Decide whether the deployment needs federation at all, and if it does, which partner domains belong on the list and who approves changes to it. Verify the list in the live configuration, not only in the source files, and firewall the federation listener so the restriction holds at the network layer as well as in Synapse.

Add Element Server Suite components

ESS Pro is Element's edition for professional and government use, deployed on Kubernetes with Helm charts. It includes Synapse Pro, Matrix Authentication Service, LDAP and SCIM integration, and auditing. Decide which directory is the source of truth for accounts and how leavers are removed. Matrix Authentication Service works with OpenID Connect providers but does not support SAML directly, so plan a bridge such as Dex if your identity provider offers only SAML or LDAP. Verify that SCIM and LDAP changes reach Matrix and that audit records are retained for your policy period.

Restricting federation to trusted domains in Synapse

The first decision is which servers the agency will federate with at all. Synapse's federation_domain_whitelist setting allows federation only with the servers whose names are listed, and an empty list disables federation entirely. Treat the list as a governed record, not a configuration detail: each entry should name a partner organization, the business reason for the connection, an accountable owner inside the agency and the exact server_name the partner uses. Ask the partner to confirm that name, because delegation can serve user IDs from another host on port 443 while server_name fixes how users and rooms are identified. Before relying on the setting, confirm in the configuration manual for your Synapse release how it applies to inbound and outbound federation traffic.

Synapse federates on port 8448 by default, and the Synapse documentation recommends firewalling the federation listener in addition to the application setting. Apply the restriction at two layers: the homeserver allowlist, and a network rule that admits federation traffic only from the addresses of listed partners. If the agency runs a reverse proxy or load balancer in front of the homeserver, confirm which address Synapse sees on each hop and place the rule where it inspects the real source. A rule applied at the wrong hop gives false assurance. Where federation is disabled entirely, close the port at the network layer as well, and keep the firewall rules and the Synapse configuration in the same change record so reviewers see both together.

Test both layers before go-live and after every change, using a server that is not on the list. From that server, attempt to join a room hosted on the agency's homeserver, and attempt to send an event into a room that it could otherwise reach through a shared partner. Expect the attempt to fail, then check the homeserver logs for the refusal instead of assuming it. Repeat the same tests from a listed partner to confirm the permitted path still works. Include a case for a domain that was recently removed, because it may still appear in room membership, and confirm that it no longer receives new events. Store the test commands, timestamps and results with the change record so the evidence survives staff changes.

Changes to the list affect relationships that users already depend on. Removing a domain can cut off partner members who share rooms with agency staff, and adding one opens a new path for events and membership. Require a documented approval process for every addition or removal. A request should state the business reason, the classification of the data that will be shared, the planned change window, the rollback step and the security owner's sign-off. Record who approved each entry, review the full list on a fixed schedule, and ask partners to notify you of changes on their side. Check how existing memberships behave after a removal in your Synapse version before the change is approved.

Choosing between Synapse SSO and MAS for government identity

Synapse can accept sign-in directly from an OpenID Connect provider through its oidc_providers setting. The homeserver acts as the relying party, so no separate authentication service is added. This path suits agencies whose directory already exposes OIDC, because the directory stays the source of identity while Synapse handles the Matrix account.

Directory: Confirm the provider can supply the claims Synapse maps to a Matrix user ID and display name, and that the agency controls the claim used for the localpart.
Lifecycle: Accounts are created on first sign-in. Confirm whether a disabled directory account also blocks new Matrix logins, and whether existing sessions end at that point.
Deprovisioning: Plan a deactivation step for leavers, through the Synapse admin API or a directory export, and test it against a staging account.
Clients: openDesk bundles Element, so confirm which clients and workplace components must reach the same provider.

Ask the identity team who owns the leaver process and whether that owner can approve the claim mapping before the build starts.

Compliance obligations that shape the build

Matrix for the public sector falls under several compliance regimes at once, and each one reaches into homeserver, identity, storage and client choices. The six obligations below set the control baseline, the authorization boundary and the evidence an assessor will request. DeployOpen prepares systems, configuration and evidence for these reviews, but it does not issue audit reports, attestations or certifications. Independent assessors and authorizing officials make those decisions.

NIST SP 800-53 baseline selection

NIST SP 800-53 Rev. 5 is the federal control catalog, and SP 800-53B defines low, moderate and high baselines that select 149, 287 and 370 controls and enhancements respectively. The categories of information the messaging system will carry drive the choice of baseline, and the agency then tailors it in writing with its authorizing official. Confirm the current catalog release (Release 5.2.0 of 27 August 2025 at research time) and document each tailoring decision before the build starts.

FISMA and Inspector General assessment

NIST lists FISMA among the laws behind SP 800-53, and under FISMA, Inspectors General independently assess agency system security and report to OMB. For Matrix, the homeserver, Matrix Authentication Service, clients, database, Redis and media storage all fall inside the agency's boundary, so an IG sample can reach their configuration, logs and retention settings. Check that the system security plan, boundary diagram and plan of action records match the deployed components and versions.

FedRAMP scope for hosted services

The FedRAMP Authorization Act of 2022 (Pub. L. 117-263, section 5921) placed FedRAMP within GSA, and OMB memo M-24-15 of 25 July 2024 sets its current scope. Cloud products that create, collect, process, store or maintain federal information on behalf of an agency are in scope, while a system used only for one agency's operations on cloud infrastructure and not offered as a shared service is out of scope. Ask whether a provider will host Matrix for more than one customer, because that changes the answer.

CJIS Security Policy v6.1 controls

CJIS Security Policy version 6.1 took effect on 26 June 2026. For criminal justice information in transit and at rest outside physically secure locations, it requires FIPS 140-3 certified modules or FIPS 197 AES with at least 256-bit keys, up from 128-bit, and vulnerability scanning at least monthly under SC-13, SC-28 and RA-5. Confirm TLS settings on the client, federation and admin listeners, encryption of PostgreSQL, object storage and backups, and whether the cryptographic modules in your build are FIPS validated.

CUI handling under NIST SP 800-171

Under 32 CFR 2002.14(h)(2), federal agencies use NIST SP 800-171 when setting requirements for controlled unclassified information on non-federal systems, unless the CUI category's authority prescribes other safeguards. Decide which rooms may carry CUI, then set federation, retention, export and access rules to match that decision. Defense contractors face a separate cloud rule under 32 CFR 170.17(c)(5), which asks for FedRAMP Moderate or equivalent authorization for cloud services that store CUI.

WCAG 2.1 deadlines for public content

The ADA Title II rule at 28 CFR 35.200 requires state and local government web content and mobile apps to meet WCAG 2.1 Level A and AA. The deadline is 26 April 2027 for entities serving 50,000 or more people and 26 April 2028 for smaller entities and special districts, and it covers apps provided through contracts or licenses. Confirm which clients and branded builds the public will use, then include accessibility testing of the client build and any theming in the project scope.

Data transfer and foreign access risk in a Matrix deployment

Before choosing a hosting provider or support model, assess where personal data in your Matrix deployment can leave the EEA. Three routes matter most for an Element and Synapse estate inside openDesk or Element Server Suite Pro: remote support sessions in which an engineer in a third country views a screen, logs or a database, storage of homeserver data or backups in a cloud region outside the EEA, and administrative access by a provider's staff. EDPB Guidelines 05/2021 treat remote access from a third country as a transfer even when data is only displayed, and they treat cloud storage outside the EEA the same way. GDPR Article 44 applies Chapter V to every such transfer, including onward transfers. Infringements of Articles 44 to 49 can attract fines of up to EUR 20 million or 4% of worldwide annual turnover under Article 83(5)(c).

The exposure does not depend on where the servers sit. The CLOUD Act provision at 18 U.S.C. 2713, added on 23 March 2018, requires electronic communication and remote computing service providers to preserve or disclose data in their possession, custody or control, wherever that data is located. A Synapse instance in an EU data center run by a provider subject to that law can still be reached. The EDPB's Example 12 in the same guidelines says that using an EU processor subject to third-country law is not itself a transfer, but complying with a third-country authority request would be one. Ask each provider which of its staff can read message content, who holds the database and backup keys, and whether any support tooling sends logs or database extracts outside the EEA.

EDPB Recommendations 01/2020 also limit what technical measures can do. Where a provider needs access to data in the clear and the destination's public authority powers go beyond what is necessary and proportionate, the EDPB cannot envision an effective technical supplementary measure. Encryption of the Synapse database therefore helps little if the provider holds the keys or must see plaintext to run support. The transfer tool also matters. The EU-US Data Privacy Framework rests on Commission Implementing Decision (EU) 2023/1795, which covers only US organizations on the Data Privacy Framework List. An appeal against the General Court's September 2025 judgment upholding it is pending as Case C-703/25 P. Confirm whether each US-linked supplier is listed, keep standard contractual clauses under Decision (EU) 2021/914 as a fallback, and plan for the case where the framework is set aside.

The EU Data Act adds two duties that affect exit planning. Article 32 of Regulation (EU) 2023/2854 requires providers of data processing services to take technical, organizational and legal measures to prevent third-country governmental access to non-personal data held in the Union where that access would conflict with Union or national law. The switching rules in Articles 25, 29 and 50 give customers the right to move to another provider or to on-premises ICT infrastructure, with a maximum two-month notice period and a 30-day transition, and they ban switching charges from 12 January 2027. The Act has applied since 12 September 2025. Write notice periods, data export formats and transition support into the support contract, and confirm with counsel which of your services fall under the Act's definition of a data processing service.

Rollout phases for Matrix for the public sector

The sequence moves a public body from policy decisions to a supported production homeserver, with each phase closing named decisions and leaving evidence an assessor can review. Phase order matters because federation scope and identity choices shape the test environment, the hardening work and the cutover plan.

Scope the federation list and identity model
Decide which domains may federate with your homeserver, whether the list stays empty, and how users sign in. Record the server_name, the allowed domains and the identity provider chain. If the organization requires SAML, plan a bridge such as Dex, because Matrix Authentication Service does not support SAML directly. Your security, legal and platform leads sign off these decisions in writing. The step closes when every open decision has a named owner. Evidence to keep: the signed scope, the federation policy as a versioned configuration file and an identity data flow diagram.
Check prerequisites for the chosen release
Confirm the openDesk or ESS release line before any build starts. For openDesk, compare your Kubernetes version, ingress controller, cert-manager, storage provisioner and Helm and Helmfile versions against the published requirements. Also confirm the external production services, such as PostgreSQL, Redis, an SMTP relay and object storage. Decide between community and enterprise editions, and check that the release you plan to use is still supported. For Synapse, confirm the PostgreSQL and Python floors for your target version. Ask the vendor to confirm current minimums. Evidence to keep: a version compatibility matrix, pinned version list and a gap register.
Build the test environment
Build a test environment in infrastructure you control, using the same release, version pins and external services planned for production. Deploy with the release's Helm or Helmfile tooling from a version-controlled repository, and configure DNS, certificates and the federation listener. Test federation against an isolated peer domain so you can prove that domains outside the allowed list are refused. Evaluation hardware minimums are documented, but production sizing needs its own assessment. The step closes when a clean rebuild from the repository reproduces the environment. Evidence to keep: the repository, deployment logs and a build record with version pins.
Harden clients and test accessibility
Apply the hardening baseline to the homeserver, identity integration and Element clients, then test each control. Confirm that the federation allow list blocks unlisted domains, that the federation listener is firewalled, and that administrative access is limited to named roles. Run an accessibility evaluation of the web client and any mobile apps against WCAG 2.1 Level A and AA. Under the ADA Title II rule, state and local government web content and mobile apps must meet this standard from 26 April 2027 for entities serving 50,000 or more people, and from 26 April 2028 for smaller entities and special districts. Confirm with counsel which date applies to your body. Evidence to keep: security test reports, an accessibility conformance evaluation and an exceptions register.
Run a pilot with a limited group
Select a limited pilot group and the rooms they will use, and keep bridges and external federation disabled unless the written scope approves them. Run real sign-in, messaging, file and call tests, along with an incident drill and a backup restore test. Collect user feedback through a named support channel and log every defect with an owner and a disposition. Confirm that the retention and export settings match the approved policy. The pilot closes when exit criteria in the written scope are met or each exception has an accepted risk owner. Evidence to keep: the pilot exit report, defect log, restore test result and support records.
Cut over and hand over operations
Run the production cutover under an approved change window, with a data plan, a DNS switch and a documented rollback path. Take a verified database backup before every upgrade, because Synapse upgrade notes warn that rolling back can be difficult after schema changes. Hand the runbooks, monitoring, on-call rota and upgrade procedure to the operations team, and record their acceptance. If support is needed after handover, agree the retainer terms in the written scope. The step closes with signed acceptance by the operations owner. Evidence to keep: the signed cutover record, runbooks, the handover acceptance and a restore test log. DeployOpen prepares this evidence, while independent assessors decide compliance.

What public bodies ask before hiring a partner for Matrix

What drives the cost of a Matrix deployment for a public body?

Scope, the number of integrations, identity complexity, hosting, compliance evidence and the support model drive cost most. Scope sets how many homeservers, clients, bridges and worker processes are built, and whether Element sits inside a wider suite such as openDesk, which adds its own Kubernetes platform and deployment requirements. Each integration with a directory, identity provider or third-party network adds configuration, testing and an owner who must approve changes. Identity complexity matters because Matrix Authentication Service connects to upstream OpenID Connect providers, so a directory that offers only SAML or LDAP needs a bridge and extra testing. Hosting determines how much production infrastructure you pay for, since openDesk expects external PostgreSQL, Redis, object storage, an SMTP relay, a virus scanning service and a TURN server. Ask for a quote that lists each cost line, marks which items are one-time and which recur, and states the support level it assumes.

How long does a fixed-scope Matrix engagement usually take?

The timeline comes from the written scope, and no standard duration applies to every public body. The main drivers are the number of integrations, the identity setup, the hosting platform and how many approval gates your governance process requires. Work on a Kubernetes platform, such as an ESS or openDesk-based deployment, depends on cluster readiness, so your platform team must confirm that before build begins. Federation and retention decisions also need early sign-off, because changing them after configuration can mean rework and retesting. Ask for a plan with named milestones, the dependencies on your side, the acceptance tests for each milestone and the date each decision is due. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so the schedule in that document is the one to measure progress against.

What must our agency provide before a Matrix build starts?

Before build starts, the agency should provide a directory with named users and groups, network access to the hosts and the federation listener, and DNS names and certificates for the chosen server name. Several decisions are also required: whether federation is off, restricted to a list of trusted domains through the federation_domain_whitelist setting, or open; how long messages, media and logs are retained; and whether bridges to third-party networks are permitted. You will also need an identity provider owner who can register applications, a Kubernetes or virtual machine platform with storage and backup targets, an SMTP relay if email is used, and a named approver for production changes. Missing inputs usually delay the schedule more than the build itself, so list each one in the scope document with an owner and a due date.

Can our own platform team deploy Matrix without an outside partner?

Yes, if the team already runs the required platforms and can carry the upgrade work for the life of the system. Synapse 1.143.0 and later require PostgreSQL 14 or newer, and 1.142.0 and later require Python 3.10 or newer, so the team needs database and runtime skills. Larger deployments use worker processes with Redis, which adds replication to operate. Identity integration through Matrix Authentication Service requires working knowledge of OpenID Connect clients and upstream providers. An openDesk deployment requires a CNCF-certified Kubernetes cluster at v1.33 or later, with Helmfile and Helm. The Synapse upgrade notes warn that rolling back can be difficult because of schema changes, so every release must be planned and tested. Ask a partner or internal lead to review these requirements against your team's current skills, and decide early whether a support retainer covers the gaps.

What recurring work follows a Matrix go-live on a public sector platform?

Recurring work falls into three groups: upgrades, operations and support. For Synapse, the team must read the upgrade notes for every release, plan background database updates, and retire Python and PostgreSQL versions once they reach upstream end of life. For openDesk, ZenDiS plans major releases annually in Q3, minor releases monthly and patch releases on demand, supports only the latest minor version, and does not guarantee in-place upgrades between majors. Skipping several minor versions may need intermediate steps. Operations include backup and restore tests, certificate renewal, access reviews and monitoring. For production support, openDesk Enterprise Edition offers SLA-backed second and third level support and patches, and DeployOpen offers ongoing support, upgrades and continuous testing as retainers. Ask for a quote that separates these recurring items from the one-time build.

Should federation be limited to trusted domains on a government Matrix server?

A restricted list of trusted domains is a conservative starting point for many public bodies, but the decision belongs to the agency's policy owners. In Synapse, the federation_domain_whitelist setting limits federation to the listed domains, and an empty list disables federation entirely. The Synapse documentation also recommends firewalling the federation listener, which uses port 8448 by default unless delegation is configured to serve it on port 443. The server_name setting fixes how user IDs such as @user:example.com and room identifiers are formed, so it must be chosen before any users are created. Document the approved domain list, the person who may change it, and the test that proves blocked domains cannot reach the server. Review the list whenever a partner organization changes its own infrastructure.

Which identity providers work with Matrix for public sector single sign-on?

The answer depends on the protocol your directory uses and the Matrix components you deploy. Synapse can authenticate through OpenID Connect providers, SAML2 and CAS, according to its configuration manual. Matrix Authentication Service works with upstream OpenID Connect providers such as Keycloak, Microsoft Entra ID, Google and Authentik, but it does not support SAML. The MAS documentation recommends a bridge such as Dex for SAML or LDAP sources. Element Server Suite Pro includes LDAP and SCIM integration and auditing, which matters for user provisioning and removal. For openDesk, the deployment documentation describes federation with an external identity provider. Confirm your directory's protocols, the version of each component in your design, and who owns client registration before you commit to an architecture.

How DeployOpen scopes and delivers Matrix for the public sector

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For Matrix in the public sector, that means a written scope covering the homeserver, federation policy, identity and clients before any build starts. Most engagements are fixed-scope, with ongoing support available as a retainer.

How we scope

Written scope that names the homeserver, Element clients, identity provider and federation policy before work starts
Federation policy written down: an empty allowlist keeps the server closed, listed domains open it to named partners
Confirm with your procurement and security owners which openDesk or ESS edition fits your support terms

How we build

Homeserver built on PostgreSQL, with Redis and worker processes sized only if your load requires them
Identity wired through MAS to your OpenID Connect provider, with SAML handled by a bridge such as Dex
openDesk or standalone Element deployment on a CNCF-certified Kubernetes cluster you control, with Helm-based automation

How we hand over

Upgrade runbook covering every Synapse upgrade note, since rolling back can be difficult after schema changes
Documented federation settings, firewall rules for the federation listener and the reasoning behind each domain on the list
Evidence pack of configuration, access and backup records, prepared for review by your independent auditors

How we support

Optional retainer for ongoing support, upgrades and continuous security testing of your Matrix deployment
Upgrade planning that follows the Synapse release line, with platform floors checked before each change
Periodic security testing of applications, APIs and infrastructure around the homeserver and clients