Rocket.Chat vs Matrix: which to choose

Rocket.Chat vs Matrix: when each platform fits

Choose Rocket.Chat when one organization needs a self-hosted chat platform from a single vendor and expects to buy enterprise controls on a paid plan. Choose Matrix when the chat must reach people in other organizations over an open federation protocol, end-to-end encryption is a core requirement, and your team is prepared to operate a homeserver itself. Rocket.Chat is maintained by Rocket.Chat Technologies Corp., and its repository is MIT licensed except the enterprise directories, which fall under a separate license. Matrix is a protocol with several homeserver implementations, so the vendor question shifts from one company to a choice of server software and the organizations you federate with.

Rocket.Chat fits a single-tenant deployment where staff, contractors and internal teams sit in one identity domain. The Starter plan adds LDAP and Active Directory authentication, single sign-on, multi-factor authentication and end-to-end encryption, but multi-instance designs, high availability, tamper-evident audit trails and air-gapped deployment belong to the paid Commercial, Government or Defense plans. Rocket.Chat 8.x requires MongoDB 8.0 or later as a replica set, so budget for a database team that can keep that replica set healthy alongside the chat platform. Confirm with Rocket.Chat which plan covers the audit and failover controls your auditors will ask about.

Matrix fits when messages must cross organizational boundaries, for example between a public agency and the external bodies it works with. Synapse, the most widely documented homeserver, is AGPL-3.0 licensed and developed by Element, with commercial licenses available, and it federates by default on port 8448. Its federation_domain_whitelist setting can restrict federation to listed domains, and an empty list disables it. Synapse supports OpenID Connect, SAML2 and CAS for sign-in, and its upgrade notes warn that rollback can be difficult, so plan for PostgreSQL and worker processes with Redis. The decision turns on three questions: how far federation must reach, what identity and audit evidence the regulator expects, and whether your team can run Synapse or a Rocket.Chat deployment with MongoDB in production.

Which scenario favors Rocket.Chat or Matrix

This table maps common chat scenarios to the platform that usually fits better, with the reason and the condition that would flip the choice. Read each row against your own identity, network and partner model, since the answer changes with who must talk to whom.

Scenario	Better fit and reason	Where the other platform becomes better
Single-agency internal chat	Rocket.Chat. One vendor-backed workspace with LDAP, Active Directory, SSO and MFA on the free Starter plan (up to 50 users) keeps identity and administration in one place.	Matrix becomes the better option if the agency wants its own homeserver, open clients and a federation-ready design from day one, and has staff to run Synapse.
Multi-agency or cross-organization chat	Matrix. Federation over the open protocol lets separate organizations run their own servers and exchange messages, with federation limited through the federation_domain_whitelist setting.	Rocket.Chat fits when all parties can share one workspace and a single administrator, since cross-organization access is simpler without running federation.
Air-gapped networks	Rocket.Chat on a paid plan. Air-gapped deployment is a paid-plan capability and is not available on Starter, so budget for that plan before design.	Matrix suits air-gapped sites when the homeserver and its dependencies can be installed from internal mirrors. Confirm the packaging and update path with your own environment first.
Small teams on free tiers	Rocket.Chat. The Starter plan includes SSO, MFA and end-to-end encryption at up to 50 users, and the Community workspace allows up to 100 concurrent users with core messaging.	Matrix becomes the better choice for small teams that need to join external rooms or bridge to other networks, since federation is part of the protocol.
Partner or community networks	Matrix. Members on different servers can join shared rooms, and each partner keeps control of its own data and retention.	Rocket.Chat suits a partner group that accepts one host and one set of admins in exchange for simpler moderation and a single user directory.
Public sector with strict data residency	Depends on the operating model. Rocket.Chat keeps data in one workspace under one administrator, which simplifies audit trails on paid plans.	Matrix fits when each agency must hold its own data and federation between agencies is required. Confirm the federation and retention policy with your assessor.
Regulated teams that must block outside domains	Rocket.Chat. Chat stays inside one tenant, so the attack surface is the single workspace and its admin accounts.	Matrix works when federation is restricted to a listed set of domains. An empty federation_domain_whitelist disables federation entirely, and the federation listener should also be firewalled.
Organizations that need the widest client choice	Matrix. The protocol supports several clients, and Synapse can be deployed behind an operator-controlled homeserver name.	Rocket.Chat fits teams that want the vendor's official mobile and desktop clients and do not need interoperability with other Matrix servers.

How Rocket.Chat and Matrix are built and deployed

Rocket.Chat and Matrix both run as self-hosted servers, but they store data, scale and upgrade in very different ways. The cards below set out the database, scaling path, component layout and day-two operating burden of each, so you can match the design to your user count, your team and the number of organizations you need to reach.

Core data store

Rocket.Chat 8.x requires MongoDB 8.0 or later running as a replica set, and a three-member replica set is strongly recommended for high availability. Synapse recommends PostgreSQL for production, with SQLite also supported, and recent Synapse releases require PostgreSQL 14 or newer. Check whether your database team already runs MongoDB or PostgreSQL, since that shapes backup, restore and support skills before any chat server is installed.

Rocket.Chat scaling path

A single Rocket.Chat instance with a MongoDB replica set is the reference design up to 500 concurrent users. Above that, multiple load-balanced instances linked by NATS are suggested, and microservices on Kubernetes with the official Helm chart are suggested above 5,000. The multi-instance and microservice designs require a paid plan, so budget for that tier before you size the cluster.

Matrix worker processes

Synapse scales by splitting work 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. This means your Redis availability and worker layout become part of the chat service. Ask whether your team can operate Redis alongside Synapse and PostgreSQL, because a single-process install is simpler but has a lower ceiling.

Client and server components

A Rocket.Chat deployment is one product, with its web app, server, database and official mobile and desktop clients built from one vendor's release line. A Matrix deployment is a homeserver plus a separate choice of client, such as Element, and optional bridges to other networks. Each extra component is another version to track, another certificate to manage and another party to support when a client breaks after a server upgrade.

Day-two upgrade discipline

Rocket.Chat standard releases are supported for 6 months and LTS releases for 12 months, and an out-of-date version can lose the ability to connect with official mobile and desktop clients. Synapse warns that rolling back can be hard because schema changes between releases are not always reversible, and it drops support for Python and PostgreSQL versions at upstream end of life. Plan a tested upgrade path and a pre-upgrade database backup for either platform.

Federation as an operating decision

Synapse federates on port 8448 by default and can publish user identifiers on port 443 through delegation, and the federation_domain_whitelist setting can restrict or disable federation entirely. Rocket.Chat workspaces are not designed as federated servers in this sense. Decide early whether your chat must reach other organizations, because that choice changes firewall rules, DNS, server naming and who you must trust.

Rocket.Chat vs Matrix side by side on features

This table sets Rocket.Chat against Matrix with Synapse as the homeserver on the capabilities that drive a chat decision. Read each row as a question to answer for your own environment, and treat the cells marked for confirmation as items to verify with the vendor or in a test deployment before you commit.

Capability	Rocket.Chat	Matrix (Synapse)
Core licensing	MIT core, with apps/meteor/ee and ee directories under a separate Rocket.Chat enterprise license	Synapse is AGPL-3.0, with commercial licenses also available from Element; Matrix itself is an open protocol with several homeserver implementations
Paid tiers	Free Starter (up to 50 users) and Community workspace (up to 100 concurrent users); Commercial, Government and Defense plans priced by quote	Element sells Synapse Pro and commercial Synapse licenses; confirm current support and license terms with Element before you budget
Identity integration	LDAP and Active Directory, SSO and MFA on Starter; LDAP and SAML user group mapping on paid plans	Synapse supports OpenID Connect (oidc_providers), SAML2 (saml2_config) and CAS; LDAP support depends on modules, so confirm it for your directory
Federation	Supplied facts do not cover federation between Rocket.Chat workspaces; confirm with Rocket.Chat before assuming it	Federation is built in, on port 8448 by default with delegation to port 443; federation_domain_whitelist can restrict or disable it
End-to-end encryption	Listed as included on the free Starter plan; confirm coverage for channels, direct messages and mobile clients	Matrix defines end-to-end encryption for rooms; confirm how key verification and device management work in the clients you plan to use
Client ecosystem	Official mobile and desktop clients; unsupported versions may lose connection to them, so upgrades are required	Client depth varies by implementation; confirm which Matrix clients and features your users need in a pilot
Import paths	Full Slack workspace exports, Slack users from CSV and a CSV importer; Mattermost data converts to CSV	Supplied facts do not cover a bulk import tool for chat history; confirm migration options with Element or the community
Database requirement	MongoDB 8.0 or later as a replica set; three members recommended for high availability	PostgreSQL recommended for production, SQLite supported; Synapse 1.143.0 and later require PostgreSQL 14 or newer
Scaling model	One instance up to 500 concurrent users; load-balanced instances with NATS above 500 and Kubernetes microservices above 5,000 on paid plans	Worker processes coordinated through Redis, with the generic worker handling client, federation and event traffic

Rocket.Chat vs Matrix licensing and paid editions

Rocket.Chat's repository is MIT licensed, but the apps/meteor/ee and ee directories fall under a separate Rocket.Chat enterprise license. That split matters if you plan to modify code, because the enterprise directories carry their own terms. Free access is also limited by user count, so the tier you choose depends on the size of your workforce and the features you need from day one. Read the Rocket.Chat plans documentation before you size a deployment.

Core code: MIT licensed outside the enterprise directories, so the core can be run, modified and redistributed under MIT terms. Confirm which directories your build includes.
Starter plan: Free for up to 50 users, with LDAP and Active Directory authentication, single sign-on, multi-factor authentication, end-to-end encryption, retention and read receipts.
Community workspace: Free for up to 100 concurrent users with core messaging only.
Maintainer: Rocket.Chat Technologies Corp. maintains the project and the enterprise code, so licensing decisions for both sit with one vendor.

Confirm whether the Community limit counts concurrent sessions or registered accounts, and confirm the current Starter feature list with Rocket.Chat before you commit.

Rocket.Chat vs Matrix on federation and encryption

Federation is the point where Matrix and Rocket.Chat differ most in governance. A Rocket.Chat workspace is one server run by one organization, and the people who can talk to it are the users that organization provisions. A Matrix homeserver, such as Synapse, is also run by one operator, but it can exchange messages with other homeservers, so each operator decides which remote servers its users may reach. Identity follows the server: the server_name setting fixes how users and rooms are named (for example, @user:example.com), so that name is effectively permanent and should be chosen before the first user is created. Renaming it later is a migration project, not a configuration change. Confirm how your chosen deployment handles server_name before you commit to a domain.

Federation is controlled by a small set of Synapse settings. federation_domain_whitelist restricts federation to the domains you list, and an empty list disables federation entirely, which is the posture many public sector and single-agency deployments start from. Because the Synapse documentation recommends also firewalling the federation listener, treat the allow list as one control among several, not the only one. For a cross-organization design, the decisions to record are which partner domains are listed, who approves additions, how a partner is removed, and what happens to rooms and history shared with a server that is later cut off. Confirm with the Synapse configuration manual how the whitelist interacts with the listener settings in your version.

End-to-end encryption needs its own scope check on both sides. Rocket.Chat lists end-to-end encryption among the features included in its free Starter plan, but the features that are covered, the clients that support them and the handling of files should be confirmed against the version you intend to run. On the Matrix side, encryption is a property of rooms and devices, so your review should cover key verification and how users recover keys when they change devices. The operational cost of federation is ongoing: someone must decide which partner servers to trust, respond to abuse coming from a federated server, review blocked or allowed domains as relationships change, and keep the federation listener firewalled and monitored. Plan that as a recurring duty with a named owner, because a whitelist that nobody reviews becomes a silent policy.

What drives the running cost of each platform

Both platforms cost more to run than their license terms suggest, because the bill is made up of infrastructure, people, support and upgrades. The cards below separate what you pay vendors from what your own team absorbs, and what you should request in writing before comparing totals.

Database and runtime footprint

Rocket.Chat 8.x requires MongoDB 8.0 or later running as a replica set, and a three-member replica set is strongly recommended for high availability. Synapse recommends PostgreSQL for production and, from 1.143.0, requires PostgreSQL 14 or newer. Above the single-instance tier, Synapse adds Redis and worker processes. Ask each vendor or partner to price the database tier, backups and failover testing as separate line items, and confirm how many hosts each reference design needs at your user count.

Staff skills and on-call load

Operating a MongoDB replica set is a different skill set from operating PostgreSQL, Redis and a Synapse worker topology. Matrix federation adds port 8448 handling, delegation and server_name planning that most chat teams have not done before. Rocket.Chat keeps the stack more uniform but still needs someone who can handle replica set failover. Estimate the on-call rota you need, and confirm whether your existing database staff can own the chat database without retraining.

Vendor support and retainers

Rocket.Chat support sits inside its paid plans, which are priced by quote, and the Commercial, Government and Defense plans are the route to features such as multi-instance designs and air-gapped deployment. Element sells Synapse commercial licenses and Element Server Suite, and partners such as DeployOpen can provide implementation and ongoing support under a written, fixed scope. Ask whether support covers both the software and your hosting, what response times are contracted, and whether a retainer is needed for upgrades.

Upgrade cadence and rollback risk

Rocket.Chat standard releases are supported for 6 months and LTS releases for 12 months, and unsupported versions can lose connection to the official mobile and desktop clients, so upgrades are recurring work. Synapse warns that rolling back can be difficult because of database schema changes, and it drops support for Python and PostgreSQL versions once they reach upstream end of life. Plan a test environment, a rollback path from backups, and a dated upgrade calendar for each platform.

Paid edition triggers

The cost of a paid edition is set by the features you need, not by user count alone. On the Rocket.Chat side, high availability, LDAP and SAML group mapping, tamper-evident audit trails and air-gapped deployment sit in paid plans. On the Synapse side, the AGPL-3.0 license already covers the core code, and the cost question is whether you need an Element commercial exception or support. Before you ask for a quote, list each required feature and check which plan or license includes it.

Moving from Rocket.Chat to Matrix or back

This sequence moves users, rooms and identities between Rocket.Chat and a Matrix homeserver without losing track of what transfers automatically, what must be rebuilt and who signs off on each step. The output is a cut-over that both sides can audit.

Inventory users, rooms and retention rules
The workspace administrator exports a list of active users, public and private channels, direct message groups, integrations and the retention settings in force for each room. Mark which rooms hold records that must be kept, and which are safe to leave behind. Done means every room has an owner, a membership count and a retention decision recorded in writing. Confirm with Rocket.Chat support or your own admin records which export formats your workspace version can produce, since the import tooling depends on them.
Map identities and authentication sources
Map each Rocket.Chat account to its source of truth, such as LDAP, Active Directory or SAML, and decide how the same person will be identified on the Matrix side. Matrix user IDs take the form of an address on your server name, so a Rocket.Chat username will not carry over unchanged. Synapse supports OpenID Connect, SAML2 and CAS, so confirm which of these your identity provider can serve. Done means a written table links every source account to a target identifier and an authentication method.
Decide federation scope and server_name
Before any Matrix server is built, decide whether it will federate, and with which domains. The server_name setting fixes how users and rooms are identified permanently, so changing it later is a rebuild, not a configuration edit. Synapse's federation_domain_whitelist can limit federation to listed domains, and an empty list disables it entirely. Done means a signed-off federation policy and a final server_name, with the security owner confirming the federation listener will be firewalled as the Synapse documentation recommends.
Stand up the target platform
The platform team installs the target platform in your own environment. For Rocket.Chat, that means MongoDB 8.0 or later running as a replica set. For Synapse, it means PostgreSQL 14 or newer for production, with Redis if workers are used. Synapse 1.143.0 and later require PostgreSQL 14 or newer, and 1.142.0 and later require Python 3.10 or newer. Done means a test instance passes a login, a message and a file upload from a client, and the backup and restore path has been rehearsed. Confirm with the vendor which versions are current for the release you plan to run.
Plan the import path for history
Rocket.Chat's import tools accept full Slack workspace exports, Slack users from CSV and a CSV importer for other sources, and Mattermost data is converted into CSV first. Moving into Matrix generally relies on bridges from the bridges catalog, which carry messages across as they arrive rather than importing an archive in one batch. Expect that some history, reactions, threads or attachments will not transfer cleanly in either direction. Done means a written list of what will be imported, what will be bridged, and what will be archived as a read-only export, each tested on a sample room.
Migrate rooms, members and retention records
Load the in-scope rooms and their member lists into the target, then verify that membership, room visibility and admin roles match the inventory. Retention records should be copied to an archive that your records team controls, because the target may not enforce the same retention rules. Done means a reconciliation report shows the room count, member count and archived records against the inventory from step one, with each difference explained. Ask the vendor or your own compliance owner which records must be kept and for how long before you delete anything from the source.
Cut over clients and communications
Move users in named groups rather than all at once, and publish the official client to install for each platform. Rocket.Chat warns that unsupported versions may lose the ability to connect with the official mobile and desktop clients, so confirm which client builds support your target and your source version. Keep the source workspace read-only during the transition window, and tell users where new conversations happen. Done means each group has signed in, sent and received messages, and the help desk has a written rollback path.
Retire the source workspace
Once cut-over is confirmed and the archive is verified, disable integrations and bots on the source, revoke service accounts, and shut the instance down on a dated decision. Keep the final backup under the retention policy from step one, and confirm that deletion of the source database does not conflict with any legal hold. Done means the source is offline, the archive restores in a test environment, and the decision record names who approved the retirement.

What implementing each platform involves and where projects run long

A Rocket.Chat deployment starts with the database, not the chat server. Rocket.Chat 8.x requires MongoDB 8.0 or later running as a replica set, and a three-member replica set is strongly recommended for high availability, so the team needs someone who can own MongoDB backups, failover tests and version upgrades. Next, choose the reference architecture before sizing hardware: the vendor's guidance points to a single instance with a replica set up to 500 concurrent users, load-balanced instances linked by NATS above that, and Kubernetes with the official Helm chart above 5,000. The multi-instance and microservice designs require a paid plan, so that choice changes the licence budget as well as the infrastructure. Identity and MFA come next. LDAP or Active Directory group mapping, SSO and MFA policies must be agreed with the identity team before users arrive, because retrofitting them after onboarding is where Rocket.Chat projects usually slip. Plan for upgrades as a recurring task: standard releases are supported for 6 months and LTS releases for 12 months, and unsupported versions can lose connection to the official mobile and desktop clients, so client rollout and server upgrades must be scheduled together.

A Synapse deployment has more moving parts, and the team should expect the overrun risk to sit in federation policy and identity mapping. Synapse recommends PostgreSQL for production, and Synapse 1.143.0 and later require PostgreSQL 14 or newer, so confirm the database version and backup plan first. The reverse proxy and delegation design comes next: Synapse federates on port 8448 by default, and delegation lets a user ID such as @user:example.com be served from another host on port 443, so the server_name value is effectively permanent and must be decided early. Federation policy is the most common source of rework. Settings such as federation_domain_whitelist decide whether the server talks to anyone, and an empty list disables federation, so the policy should be signed off by legal and security before the listener is opened. For SSO, Synapse supports OpenID Connect through oidc_providers, SAML2 through saml2_config and CAS, and attribute mapping must be tested against the real directory. Workers are needed when load grows, and they add Redis as a replication dependency. Finally, bridges and clients need named owners, since client support and bridge compatibility change with each release and the upgrade notes warn that rolling back after schema changes can be difficult.

The team must provide several inputs before either quote can be accurate. For Rocket.Chat, supply the expected concurrent user count, the identity directory structure, the target hosting platform, and the names of the people who will run MongoDB and perform upgrades. For Synapse, supply the list of partner domains that will federate, the federation policy owner, the DNS and certificate process, the identity provider configuration, and a decision on which clients and bridges staff will use. Ask the implementation partner to list which items are one-time work (installation, identity integration, federation design, migration) and which recur (upgrades, client testing, bridge maintenance, backup restore tests). The largest overruns usually come from three places: federation scope that expands after launch, identity mappings that were never tested with real groups, and client upgrades that were not planned alongside server upgrades. Agree on written acceptance tests for each of these before the work starts, and confirm current version support windows with each vendor, since the facts used here reflect the published release and support pages at the time of writing.

Questions buyers ask before choosing Rocket.Chat or Matrix

How much ongoing effort does Rocket.Chat take to run compared with Matrix?

Rocket.Chat is the lighter operational model for most teams, but it still needs regular upgrades. Rocket.Chat 8.x requires MongoDB 8.0 or later running as a replica set, and a three-member replica set is strongly recommended for high availability. Rocket.Chat standard releases are supported for 6 months and LTS releases for 12 months, and unsupported versions can lose connectivity with the official mobile and desktop clients. A Matrix deployment means running a homeserver such as Synapse, which needs PostgreSQL for production, Redis once you add workers, and careful handling of upgrades, since rolling back can be difficult because of database schema changes. Ask your team which database and upgrade cadence it can sustain before choosing.

Can our internal team deploy and run either platform without outside help?

A team with Linux, database and container experience can deploy either platform alone, but the first deployment is rarely the hard part. The harder work is identity integration, high availability design, backup and restore testing, and a repeatable upgrade routine. Rocket.Chat's multi-instance and microservice designs require a paid plan, so a team that expects to grow past 500 concurrent users should confirm licensing before building. Matrix requires designing server_name, federation policy and the federation listener before users arrive, because those choices are hard to change later. Decide which of those tasks your staff will own and which you want to hand to an implementation partner.

What work must stay with internal staff after an outside rollout?

Internal staff should keep ownership of upgrades, user lifecycle, access policy, backup verification and incident response, because those tasks recur. For Rocket.Chat, that means tracking the supported version lines and applying patch releases on schedule. For Matrix, it means monitoring Synapse upgrade notes, Python and PostgreSQL support windows, and federation settings such as federation_domain_whitelist, which should be reviewed whenever partner organizations change. Identity administration, including SAML or OIDC group mapping, also stays in house. An implementation partner can document these routines and train the staff who run them, but the day-to-day responsibility should be named in writing.

How long does a typical rollout take for Rocket.Chat or Matrix?

Rollout duration depends on scope, and the timeline is agreed in writing before work starts. The main drivers are the number of users, the identity provider to connect, whether federation is needed, whether the deployment is air-gapped, the volume of history to import, and how many environments must be validated. Rocket.Chat supports imports from full Slack workspace exports, Slack user CSV files and a generic CSV importer, while Mattermost data requires conversion to CSV, so migration scope can shift the schedule. Matrix rollouts often include a longer design phase for federation and bridge decisions. Ask any provider for a scope document with milestones and acceptance criteria rather than a single headline duration.

Can Matrix replace Rocket.Chat in a public sector deployment?

Matrix can meet some public sector needs, but it is not a drop-in replacement without checking several points. Matrix is an open federation protocol, and Synapse federates on port 8448 by default, so an agency must decide whether cross-organization federation is allowed or whether the homeserver should be restricted to listed domains or disabled. Rocket.Chat offers a single-vendor model with a paid Government plan and air-gapped deployment on paid plans, which many procurement teams find easier to evidence. Confirm with the agency's accreditation authority whether the chosen licenses, such as AGPL-3.0 for Synapse and separately licensed commercial terms, meet its policy, and confirm which identity, logging and retention controls each option supports in the target environment.

What should a quote for a Rocket.Chat or Matrix engagement include?

A quote should follow from a written scope and list the deliverables, not only hours. Ask for the architecture being built, the number of users and environments, the identity integrations, the data migration plan, the backup and restore tests, the documentation handed over, and the training included. Separate one-time work such as design, deployment and migration from recurring work such as upgrades, patch windows and support. For Rocket.Chat, ask whether the quote assumes a paid plan, since Commercial, Government and Defense plans are priced by quote and are required for some high availability and audit features. For Matrix, ask whether federation testing, bridge work and Synapse worker scaling are included. Fixed-scope deliveries make it easier to compare offers.

Which identity and login features are free with each option?

Rocket.Chat's free Starter plan, limited to 50 users, includes LDAP and Active Directory authentication, single sign-on, multi-factor authentication, end-to-end encryption and retention. Its paid plans add LDAP and SAML user group mapping and tamper-evident audit trails. Synapse supports single sign-on through OpenID Connect providers, SAML2 and CAS in its configuration, and the license for Synapse itself is AGPL-3.0, with commercial exceptions available from Element. Confirm with your identity team which group mapping, multi-factor and session controls you need, then check the current plan documentation or the Synapse configuration manual before finalizing the design.

How DeployOpen helps choose, implement or migrate chat

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For the Rocket.Chat vs Matrix decision, we start from your user population, identity sources, federation needs and operating model, then build only the option that fits.

How we scope

Written scope covers which platform, edition, user count and identity sources the deployment must support.
We record whether cross-organization federation, public sector data residency or air-gapped operation is required.
Scope defines deliverables, timelines and responsibilities before any work starts, as engagements are fixed-scope.
We ask you to confirm current license terms and paid edition features with each vendor before the scope is signed.

How we build

We deploy the chosen platform in your infrastructure, including database and, for Matrix, Redis and worker layout.
Identity integration covers LDAP, Active Directory, SSO or OpenID Connect and SAML, as the chosen edition supports.
Hardening covers access controls, federation restrictions and firewall rules agreed in the written scope.
Client connectivity is tested on the official mobile and desktop clients you plan to give users.

How we hand over

Documentation covers the architecture, configuration keys, backup and restore steps and upgrade procedures we delivered.
Handover includes migration of users or history where a supported import path exists, such as Slack exports for Rocket.Chat.
We prepare compliance-relevant evidence for your assessors, while independent auditors issue any audit reports.
Your team receives runbooks for the version lifecycle, so upgrades happen before a release reaches end of life.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover version upgrades, which matter for Rocket.Chat support windows and Synapse schema changes.
Security testing of the deployed chat service can be scoped separately under the same written agreement.
Ask any provider, including us, to confirm which features your chosen edition includes before you commit.

Rocket.Chat vs Matrix