Why federated team chat with external organizations is a different build
Federated chat with outside organizations is a different build because federation moves control of identity, retention and moderation for shared rooms out of your single tenant and into a set of server-level decisions. If you must exchange messages with partners, agencies or subsidiaries that run their own servers, the question is not whether the product can talk to them but which servers you accept, whose accounts can join, who keeps the copy of each message, and who can remove a participant. On Matrix, the open protocol behind Synapse, the Matrix homeserver maintained by Element, those answers come from configuration on your server and on theirs. Mattermost and Rocket.Chat are built around a single server per organization and do not federate in the same way, so cross-organization work usually means shared guest accounts, bridges or separate instances rather than a federation layer you can govern.
Synapse is licensed under AGPL-3.0, with commercial licenses available from Element, and that licensing choice matters when a partner asks whether you can host a homeserver for them or modify it. Federation is controlled by server configuration rather than a product checkbox. The federation_domain_whitelist key restricts federation to listed domains, and an empty list disables federation entirely, so the allow-list is a decision you record and review, not a default you inherit. Confirm with your architect how the listener is firewalled, because the Synapse configuration manual recommends firewalling the federation listener in addition to the allow-list. Also confirm which Synapse release and PostgreSQL version your environment will run, since the upgrade notes tie supported versions to upstream end-of-life dates.
The decisions that federation creates are the ones to make before any room is opened. Identity for a federated user is established by the partner's homeserver, so you need to agree which identity provider vouches for their accounts and how you will revoke them when an engagement ends. Retention applies on each server separately, which means a message sent to a partner may be kept by their server under rules you do not control. Moderation of a shared room requires agreed roles and an escalation path across both organizations. Write these decisions into a federation agreement with each partner, and test a removal of a partner domain in a non-production environment before go-live.
Requirements federation creates and what each means for the build
This table maps each requirement that federation with outside organizations raises to the supplied source, the build consequence for a Matrix deployment, and what to confirm with counsel or the regulator. Read it as a checklist: the technical settings only solve part of the problem, and the retention and audit decisions depend on the rules that apply to your organization.
| Requirement | Build consequence | What to confirm |
|---|---|---|
| SEC Rule 17a-4(b)(4) preservation (17 CFR 240.17a-4) | Federated messages with partners can be communications relating to the business. Retention must cover the federated rooms and the copies your side sends and receives, for not less than three years. | Whether counsel treats partner conversations as business communications, and which retention and export features your chosen edition provides. |
| HIPAA transmission security (45 CFR 164.312(e)(1)) | Where ePHI may cross to an outside organization, the federation link must be protected in transit, and only approved partner domains should be reachable. | Whether any partner exchange involves ePHI, and whether a business associate agreement or similar terms are needed before federating. |
| HIPAA audit controls (45 CFR 164.312(b)) | Log federation activity, including which remote servers connect, which rooms are joined and administrative changes, and keep those logs for review. | Which events your compliance team must record, how long logs are kept and who reviews them. |
| Domain allow-list (federation_domain_whitelist) | Listing only approved partner domains restricts federation to them. Changes to the list must go through change control and be recorded. | Which partner domains are approved, who owns each approval and how removals are handled when a partnership ends. |
| Empty allow-list behavior | An empty list disables federation entirely. Use this as the default for isolated deployments and add domains only after approval. | Whether the organization needs any federation at all, or whether a bridge or guest account would meet the need. |
| Federation listener exposure (port 8448 and delegation) | Synapse federates on port 8448 by default. Firewall the listener to approved partner addresses and, if delegation serves user IDs on port 443, confirm the delegation record points only to your intended host. | Who approves firewall rules for the federation port, and whether partners can reach you through a shared gateway or must be placed in a dedicated network zone. |
| Identity of external users (server_name and SSO) | The server_name fixes how users and rooms are identified, so it cannot be changed casually. Partner accounts remain on their own server, so your access decisions must cover what those users can join. | Which identity source is authoritative for partner users, and whether your policy allows guests from other domains in internal rooms. |
Which platforms fit cross-organization chat and why
Cross-organization chat depends on whether the platform can federate with servers you do not run, and on how it handles identity, retention and moderation across those boundaries. The options below differ in federation model, licensing and edition gating, so each needs confirmation against the specific product and edition before purchase.
Synapse as the Matrix reference server
Synapse, developed by Element and licensed under AGPL-3.0, is the most widely documented Matrix homeserver and the default choice when open federation with partner servers is a requirement. Federation is controlled through the federation_domain_whitelist setting, and an empty list disables federation entirely. Confirm the allow-list behavior, the federation listener firewalling and the server_name decision with your architect before go-live, because the server name is hard to change later.
Other Matrix implementations
Matrix.org lists several homeserver implementations besides Synapse, including Dendrite (Go, AGPL-3.0-or-later), Conduit (Apache-2.0) and its Rust forks Continuwuity and Tuwunel (Apache-2.0). These are alternatives for smaller or specialized deployments, but feature coverage, admin tooling and federation behavior with other servers differ from Synapse. Test interoperability with each partner's server version before committing to a non-Synapse homeserver.
Synapse Pro and AGPL exceptions
Element sells Synapse Pro and commercial licenses that serve as exceptions to AGPL-3.0, and it announced in December 2023 that future Synapse contributions would be AGPLv3 with a contributor license agreement. For organizations that cannot accept AGPL obligations on a modified server, the commercial license is a procurement question, not a technical default. Ask Element and your counsel what the exception covers, what support is included and how it changes upgrade obligations.
Mattermost for teams without open federation
Mattermost releases are licensed under MIT when compiled by Mattermost, Inc., while the source may be used under AGPL-3.0 subject to listed exceptions, and v12.0.0 was published on October 14, 2026. Mattermost suits internal teams that need a strong channel model and integrations but do not need Matrix-style federation with outside servers. For partner collaboration, plan guest accounts and shared channels, and confirm which of these are available in your edition.
Rocket.Chat for closed partner communities
Rocket.Chat is licensed under MIT except for content in its ee directories, which uses a separate enterprise license, so the license boundary sits inside the code tree. It fits organizations that want team messaging with external guest access in a closed community rather than open federation. Before purchase, confirm which features you need sit in the open-source core, which sit in the enterprise directories and whether federation-style connections are offered in your target edition.
Identity, retention and moderation questions federation raises
The server_name setting is the first decision to lock down, because it fixes how user identifiers such as @user:example.com and room identifiers are created. Those identifiers are what partners see in every conversation and what other servers store in their own records, so changing the name later is not a configuration tweak. Choose the domain that will still be correct in five years, confirm that it matches the DNS and delegation design in the Synapse federation documentation, and agree the naming with every partner before the first external room is opened. Federation also depends on the federation listener on port 8448 by default, so confirm with your network team how that port is exposed and restricted.
Identity is the second decision. Synapse can accept single sign-on through OpenID Connect providers configured under oidc_providers, through SAML2 using saml2_config, or through CAS, as described in the Synapse configuration manual. Decide whether partner staff sign in through their own organization's identity provider, through a guest account you issue, or through a brokered flow, and confirm with your identity team how a departing guest or partner account is disabled on your side. Synapse does not decide that on its own. Record who owns each deprovisioning step, because an account that is removed from your identity provider but still holds active sessions or room memberships on your server is a common gap.
Retention and moderation are where federation changes the compliance picture. Each homeserver keeps its own copy of room history, so a shared room has one copy per participating server, and each copy follows that server's retention policy and legal hold process, not the other party's. Confirm with your records and legal owners whether your obligations require preserving messages that partners sent into your copy, and whether partner servers can meet the same requirement. Moderation has the same split: kicking a user, redacting a message or changing room permissions is performed by admins of the server that holds the relevant power level, so agree in writing which organization acts on which room and how incidents are escalated across the boundary.
How the rollout moves from pilot partner to production federation
This sequence takes federation from a single agreed partner domain to a controlled allow-list, with each phase ending in a signed-off artifact that the client, the partner and the compliance owner can review before the next step starts.
Agree naming and server_name with each partner
The client's security lead and the partner's administrator agree on the server_name, the domain that appears in every user ID (for example, @user:example.com) and in every room address, and on how delegation will point that name to the homeserver. Because server_name is fixed at setup and is hard to change once users and rooms exist, this decision is made before any server is built. The output is a signed-off domain record listing the server_name, the owning organization, the named technical contacts on both sides and the agreed certificate and DNS owner. The step is done when both parties have approved that record in writing.
Deploy a pilot homeserver pair on PostgreSQL
DeployOpen builds one Synapse homeserver for the client and a matching test homeserver for the partner, each in the environment that the respective owner controls. The Synapse documentation recommends PostgreSQL for production, so both sides run PostgreSQL rather than SQLite, and the version must meet the minimum listed in the upgrade notes for the chosen release. Each side sets federation_domain_whitelist to the single partner domain, so no other server can federate in. The output is a running pair with a documented configuration file set and a build record that names the Synapse release, the PostgreSQL version and the Python runtime in use.
Validate delegation and federation port exposure
The team confirms that the partner's server name resolves to the correct host, that federation traffic reaches the listener (Synapse uses port 8448 by default unless delegation redirects it), and that the federation listener is reachable only from the partner's address range. The Synapse documentation recommends firewalling the federation listener in addition to the allow-list, so this step tests both layers. Test rooms are created, invitations are sent in both directions, and messages are confirmed to arrive. The output is a connectivity test report with each check, the result and the person who ran it. The step is complete when messages flow in both directions and a connection from a non-listed server is shown to be refused.
Test retention and export on federated rooms
Before any real business traffic is allowed, the compliance owner tests how retention settings apply to events that originate on the partner's server and events that originate locally. The test covers message deletion, redaction, media retention, and whether each side's export tooling produces a complete record of a shared room. The result depends on the local retention policy and on what the partner's server keeps, so each side must record its own settings. The output is a retention and export test report that states what is kept, for how long and where, and that the compliance owner has accepted or returned for correction. Regulated organizations should check this report against their own recordkeeping rules rather than assume that federated copies are covered.
Add single sign-on to the pilot
The pilot moves from local accounts to the client's identity provider. Synapse supports OpenID Connect through oidc_providers, SAML2 through saml2_config and CAS, so the team selects the protocol that the identity provider already supports and maps the attributes that set the user's display name and identity. The team confirms that deprovisioning in the directory stops a user from signing in, and records which accounts on each side are guests and which are staff. The output is a tested login matrix covering staff, guest and removed accounts, and a list of accounts with their identity source. The step is done when a disabled directory account can no longer sign in to the pilot.
Open the allow-list in controlled steps
Once the pilot passes its tests, the client adds further partner domains to federation_domain_whitelist one at a time, with a rollback plan and a short monitoring window after each addition. Each new partner repeats the naming, connectivity and retention checks for its own domain, because a shared allow-list hides the fact that every partner carries its own risk. The output is a change log showing each domain added, its approval date, the test evidence attached and the person who authorized the change. The step is done when every planned partner is either live with its evidence on file or has been formally deferred.
Document and rehearse removal of a partner
DeployOpen writes a runbook for removing a partner, covering removal of the domain from the allow-list, restart procedures, handling of existing rooms and memberships, the retention position for messages already exchanged, and the steps to revoke the partner's identity access. The runbook is rehearsed on the pilot pair, so the team knows the effect before it is needed. Upgrades and schema changes can make rollback difficult, so the runbook also notes the backup point taken before any change. The output is a tested removal runbook and a rehearsal record, reviewed by the security owner and filed with the federation change log. The step is done when a removal has been carried out end to end on the pilot without unplanned effects.
When bridges to Slack or Teams are the right answer
When should we bridge Matrix rooms to Slack or Teams instead of asking partners to switch?
Bridge when a partner's staff cannot or will not move off Slack or Teams during the engagement, and the shared work justifies carrying their messages into your environment. A bridge makes sense for a short migration window, a supplier that is contractually bound to its own tenant, or a joint project where forcing a new client would stall delivery. If the partner can join a Matrix room directly, a bridge adds a component you must run and govern for little benefit. Treat the bridge as an exception with a stated end date, not as a permanent architecture decision.
What does a Slack or Teams bridge actually hold that we need to govern?
A bridge is a separate service that reads message content from both sides and maps identities between them. It therefore holds message bodies, attachments or links, user and room identifiers, and the credentials it uses to act in each platform. Matrix.org lists bridges for Slack, IRC, WhatsApp, Telegram, Signal and email, but each one is its own software project with its own data handling. Before go-live, document what the bridge stores, where those stores live, and who can read them, because it may hold copies of conversations your retention policy covers.
How do we host and secure bridge credentials for Slack or Teams?
Run the bridge inside your own infrastructure, on the same network segment and change control as your homeserver, and keep its tokens out of configuration files in plain text. The bridge needs an application or bot identity in the external platform, which typically requires admin approval on the partner's tenant. Agree in writing who owns that identity, how its scopes are limited, how secrets rotate, and how access is revoked when the engagement ends. Confirm the exact scopes and token types with the bridge maintainer and the external platform's current documentation, since these change.
Will bridged messages keep their retention and audit trail?
Not automatically, and you should assume they will not without testing. Retention on your Matrix side covers only what reaches your homeserver, while the Slack or Teams side keeps its own copy under the partner's policies. Edits, deletions, reactions, threads, files and reactions may not map one to one, and deletions may not propagate. Test each of these cases in a staging bridge and record which events are captured in your audit logs. Where regulation requires a complete record, the bridge is part of the evidence scope and must be documented as such.
How mature are Matrix bridges for Slack and Teams, and what should we test?
Bridge maturity and feature coverage vary by platform, by bridge and by release, so no general claim should replace a test against your own use cases. Confirm for each bridge whether it supports the features your partner relies on, such as threads, file transfer, message edits, reactions, user presence and guest accounts. Check the bridge's release activity, open issues on identity mapping and its handling of Matrix version changes. Run a pilot with real workflows from the partner's side, including reconnection after an outage, and record what breaks before you commit.
What does it cost to run a bridge, and who pays for it?
The main cost is engineering and operations time, not licenses for most open-source bridges, though you should confirm each bridge's license terms. You pay for the hosting, the setup and testing of identity mapping, monitoring, credential rotation, upgrades that follow both Matrix and external platform changes, and the audit work to document bridged data flows. The partner pays for its own tenant administration and any app approval on its side. Costs recur because platform APIs and bridge releases change over time, so ask a partner to quote setup separately from ongoing support.
Can DeployOpen build, test and operate a bridge for us?
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, which includes a bridge deployed alongside your homeserver. It also runs security testing of applications, APIs and infrastructure, which can cover the bridge's exposed services and credential handling. Most engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, and ongoing upgrades and support are available as retainers. Ask for the bridge's data flows and retention behavior to be written into the scope.
When is the better answer to skip the bridge and migrate the partner?
Skip the bridge when the partner's staff will use the shared rooms for an extended period, when the bridged content is regulated, or when the partner can onboard as a federated guest with a managed account. Each added bridge multiplies the places where messages live and the credentials to protect, so long-term coexistence is usually a weaker design than a planned cutover. Set a sunset date at the start, track which partners still depend on the bridge, and decommission it once the last shared room has moved. Confirm with the partner's administrators whether they can provision guest access at all.
Evidence auditors and regulators ask for in federated chat
This table maps each piece of evidence an assessor is likely to request to the component that produces it, such as the homeserver configuration, firewall rules, SSO settings, retention logs and change records. Read it as a checklist of what to collect and retain from day one. DeployOpen prepares this evidence, but auditors and regulators decide whether it is sufficient for your obligations.
| Evidence | Component that produces it | What an assessor typically checks |
|---|---|---|
| Federation allow-list | Synapse homeserver configuration (federation_domain_whitelist) | Which partner domains are listed, who approved each entry, and whether an empty list was set where federation is not permitted |
| Federation listener controls | Host and network firewall rules for the federation listener (port 8448 by default) | Only approved partner addresses can reach the listener, and rule changes are logged and reviewed |
| Delegation and server identity | server_name setting and well-known delegation records | Which domain identifies users and rooms, and that delegation points only to the intended homeserver |
| Identity and SSO configuration | OIDC, SAML2 or CAS settings in the homeserver and upstream identity provider | How external users are authenticated, whether accounts map to a directory, and how deprovisioning reaches federated accounts |
| Cross-domain room join and invite logs | Homeserver logs and any log export to a central SIEM | Which remote users joined which rooms, when, and whether guest access was approved under policy |
| Bridge activity logs | Bridge service logs for Slack, Teams or other connected platforms | Which bridged rooms exist, which identities they relay, and who administers the bridge credentials |
| Retention and export records | Retention policy settings, database backups and export job logs | Whether messages from federated rooms follow the same retention rules as internal ones, and whether exports can be produced on request |
| Upgrade and change records | Change tickets, release notes and database migration logs for each Synapse upgrade | Who approved each release, what was tested, and whether a rollback path existed, given that rollback can be difficult after schema changes |
Questions to ask an implementation partner before federating
Start with identity. Ask the partner how they will set server_name before any user or room exists, because it fixes how every account and room is identified, and changing it later is effectively a migration. Ask them to explain how they will publish delegation so that a user ID such as @user:example.com can be served from a separate host on port 443 while federation traffic still reaches port 8448, and which DNS and certificate records they will create and who owns them. Ask who approves a new federation peer and whether that approval is written into the change record.
Then test the controls. Ask how they will populate federation_domain_whitelist in the Synapse configuration, and whether they will prove the setting works by attempting federation with a domain that is not listed, not just by reading the file. The Synapse configuration manual recommends also firewalling the federation listener, so ask who writes those rules, how they are reviewed, and how a blocked attempt is logged. Ask for the list of partner domains and the process for removing one. Ask how they handle Synapse upgrades, because the upgrade notes warn that rollback can be difficult after schema changes, and that PostgreSQL and Python versions are dropped once upstream support ends. Ask which PostgreSQL version your environment will run and how they will rehearse an upgrade on a copy of the database first.
Finally, settle scope and commercial terms. Ask how any bridge to Slack or Teams is hosted, which network it runs on, what data it stores, and how its message retention is set separately from the homeserver's. Ask for the written partner onboarding and offboarding procedure, including how a partner's accounts, rooms and bridged history are disabled. Ask which Synapse license they recommend: the AGPL-3.0 community code, or a commercial license from Element, and what each means for your obligations and support. Ask them to state in writing which features your compliance evidence depends on and whether those require a paid option.
How much effort, time and input does federated chat take?
What drives the effort of federated chat with external organizations?
The main drivers are the number of partner organizations, how their identities are trusted, the retention rules that apply to shared rooms, and whether bridges to Slack or Teams are needed. Each partner adds a domain to review, a trust decision and a set of users to map. Identity integration is often the largest single piece, because Synapse supports single sign-on through OpenID Connect, SAML2 and CAS, and each provider has to be configured and tested against the way your directory works. Retention and moderation rules multiply the work when partners have different recordkeeping duties. Bridges add a separate system to operate, patch and monitor. Ask any partner to size these four drivers in writing before agreeing a scope, since the same platform can be a small or a large project depending on them.
Which parts of federated chat are one-time work and which recur?
Setup is one-time work: the homeserver deployment, database and network design, single sign-on configuration, the initial federation allow-list, retention policy and testing. Recurring work is continuous. Synapse releases are frequent, and the upgrade notes warn that rolling back can be difficult because of database schema changes, so each upgrade needs a tested plan. Allow-list reviews should happen whenever a partner is added, removed or changes its hosting. Python and PostgreSQL versions also reach end of life on upstream schedules, which forces periodic platform work. Operations such as monitoring, backup verification, certificate renewal and access reviews recur as well. Ask for the recurring tasks, their frequency and who performs each one, and separate those from the one-time build in the quote.
What input do we need from our own team for federated chat?
Federation touches policy and identity more than software, so the client supplies most of the decisions. You need named technical contacts at each partner who can confirm server names, network paths and the federation listener configuration. Policy owners in legal, compliance or the business must approve which domains are trusted, what may be shared, and how long messages are kept. Identity administrators must confirm how users are provisioned, which directory or identity provider is authoritative, and how guests or partner accounts are deprovisioned when a relationship ends. A security or network owner should review firewall rules, since Synapse's documentation recommends firewalling the federation listener in addition to the allow-list. Agree these owners and their turnaround times before the design starts, because most delays come from waiting for decisions.
Can an internal IT team run federated chat without outside help?
A capable internal team can run it, provided it has people with Matrix and Synapse experience, PostgreSQL administration skills and a clear on-call process. The hard parts are less the installation than the ongoing judgment: deciding which domains to trust, handling a compromised partner server, planning upgrades without breaking federated rooms and proving retention to an auditor. Teams that build this for the first time often underestimate the testing burden of federation with a second organization, where both sides must agree on server names, delegation and certificates. A practical test is whether two or three people can perform an upgrade and a restore from documentation alone. If not, a fixed-scope engagement can fill the gap for the build, the runbooks and knowledge transfer, while your team keeps ownership.
How is a DeployOpen federated chat engagement scoped and agreed?
Most DeployOpen engagements are fixed-scope, so the scope, deliverables and timeline are agreed in writing before work starts. For federated chat, the written scope typically lists the platform and components, the partner domains to be configured, the identity integrations, the retention and export requirements, any bridges, the testing to be performed and the handover documents. DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports the self-hosted platform inside your own infrastructure. DeployOpen does not publish a price list, so the quote follows from the written scope. Ask for the scope document to name each partner, each integration and each recurring service separately, so you can see which items are one-time and which fall under a support retainer. DeployOpen does not issue audit reports or certifications; it prepares the systems and evidence for your assessors.
What does ongoing support for federated chat usually include?
Ongoing support covers the work that keeps federation safe after go-live. Typical items include patching and upgrading Synapse, PostgreSQL and the supporting components, reviewing the federation allow-list when partners change, verifying backups and restores, monitoring federation health, and handling access requests from partner staff. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, so the scope and frequency of each service should be written into the retainer. Ask the provider how it handles emergency changes, such as blocking a partner domain within a defined window, and who authorizes that action on your side. Because Synapse upgrades can change database schemas, confirm that upgrade testing against a staging copy is included in the retainer rather than billed separately.
What does federated chat cost to run each year?
Recurring cost comes from four sources: the infrastructure that hosts the homeserver, database, storage and any bridges; the staff or provider time for upgrades, reviews and operations; the licensing that applies to the chosen edition or commercial Synapse license, if you buy one; and retention storage that grows with the volume of shared messages. Synapse itself is licensed under AGPL-3.0, and commercial licenses are available from Element, so confirm with Element whether your use requires one. Ask any provider to split its quote into one-time setup, annual support and pass-through costs such as hosting. Compare that split with your own estimate of administrator hours. The main reducers are fewer partner domains, a single identity source and a retention policy that matches each partner's obligations.
How long does it take to set up federation with a partner?
The supplied facts do not give a duration for federation setup, and the time depends on the factors already discussed: how many partners there are, how quickly each partner's technical contacts respond, and how complex the identity and retention decisions are. Federation with a partner that already runs Matrix and has a clear DNS and certificate process is usually faster than one that must be set up from scratch on both sides. Ask any provider for a written timeline tied to the agreed scope and to dependencies on your policy owners and partners. Do not accept a timeline that assumes partner decisions will arrive on a fixed date without a named contact responsible for them.
How DeployOpen scopes and supports federated chat
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source chat platforms inside your own infrastructure, whether that is your cloud accounts, data centers or an isolated network. For federated chat, that means the homeserver or chat server, its database and media storage, the federation listener, reverse proxy and DNS delegation, and the single sign-on connection all run where you decide they run. We start by agreeing the scope in writing: which partner domains are in scope, which identity provider each side uses, who may create rooms that cross the boundary, and which operational runbooks you need before go-live. Most engagements are fixed-scope, so the deliverables and timelines are settled before work begins.
Federation adds an attack surface that internal chat does not have, so DeployOpen runs security testing against it as part of delivery. Testing can cover the exposed federation endpoints, the allow-list configuration (for example, the federation_domain_whitelist setting in Synapse), rate limits on remote traffic, and the way bridges and bots authenticate. Each finding is reported with a fix, and retests confirm the fix. We also prepare compliance evidence for the controls your assessors will ask about, such as configuration baselines, change records, access reviews and audit log samples. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, and we will tell you which of your claims need their review.
After go-live, ongoing support, upgrades and continuous testing are available as optional retainers, which matter for federated chat because partner servers change their versions and policies on their own schedule. Ask any implementation partner, DeployOpen included, to confirm in writing what it does and does not own, including who approves a new partner domain, who handles a federation incident at 2 a.m., and how upgrades are tested against a partner server before they reach production. DeployOpen is not an official partner, reseller or certified provider of Matrix, Element, Mattermost or Rocket.Chat, so confirm the vendor relationship and the license edition your scope needs directly with the vendor.
