Discord vs Matrix: when each one fits your community or team
Discord remains the simpler choice when your community values fast onboarding, mobile-first voice channels and built-in moderation tools, and when nobody on the team is willing to run servers. A self-hosted Matrix homeserver is the better fit when the organization must hold the data, control federation and set its own retention and moderation rules. Three questions settle most of the decision: who must hold the data, who runs the servers, and how much change members will accept. Start with data. If a regulator, customer contract or internal policy requires that messages stay in your own cloud account or data center, Discord's hosted model is hard to justify regardless of features. Check current Discord limits on retention, export and data handling in Discord's own documentation, since those details change and should be read from the source rather than from third-party summaries.
The second question is operations. A Synapse deployment needs a PostgreSQL database, a reverse proxy, TLS certificates, backups and a plan for upgrades, and the upgrade notes warn that rolling back can be difficult because of schema changes. Ask who will own those tasks after go-live and whether that person has time for them. Federation is a separate decision. Synapse federates on port 8448 by default, and the federation_domain_whitelist setting can restrict federation to listed domains or disable it entirely, so you can decide whether your community talks to other servers at all. The third question is member change. Matrix clients such as Element differ from Discord's interface and voice model, and members who only know Discord will need guidance. Plan a pilot group, confirm which Discord features your community depends on, and decide early whether a bridge will carry members through the transition.
Which scenarios favor Discord and which favor self-hosted Matrix
This table pairs common Discord use cases with the self-hosted Matrix conditions that would change the choice. Read each row as a test: if your situation matches the condition in the right column, the matching platform is usually the better fit. The main takeaway is that Discord fits open, community-first audiences, while Matrix fits organizations that must own hosting, identity, federation and retention.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Public hobby community with thousands of casual members | Discord | Members already use Discord, and the community depends on its discovery, bots and voice channels rather than on owning the data. |
| Internal engineering team under a data residency rule | Self-hosted Matrix | Messages and media must stay in named regions or data centers, and the organization can run Synapse on infrastructure it controls. |
| Partner network that must exchange messages across organizations | Self-hosted Matrix | Each partner runs its own homeserver and federation is limited to an agreed list of domains, such as with Synapse's federation domain whitelist. |
| Community that needs owner-controlled retention | Self-hosted Matrix | The operator sets how long rooms and media are kept and confirms that deletion happens on the operator's own database and storage. |
| Small open community that wants a quick start with no hosting work | Discord | No team is available to operate a homeserver, database, backups and upgrades, and the community does not need a private network. |
| Company that must prove who can access each room through its own identity provider | Self-hosted Matrix | Single sign-on through OpenID Connect, SAML2 or CAS is required, and the identity team can own the connection and offboarding process. |
| Gaming or fan community centered on voice and live events | Discord | Voice channels, stage-style events and the existing bot ecosystem are central, and members prefer the native client experience. |
| Organization that must avoid sending member data to a third-party service | Self-hosted Matrix | Legal or contractual terms prohibit third-party hosting of conversations, so the organization must confirm its own operating model before migrating. |
Which Matrix homeserver to run and why it matters
Synapse is the most widely documented Matrix homeserver. It is written in Python, developed by Element and distributed under AGPL-3.0, with commercial licenses also available from Element. It fits organizations that want the largest body of documentation, the widest set of deployment examples and a clear path to commercial support if they need one. Its licensing matters because running a modified Synapse for users over a network can trigger AGPL source disclosure duties, so legal review should come before any customization.
- Documentation depth: The Synapse documentation covers federation, workers, configuration and upgrades in detail, which lowers the effort of planning a deployment.
- Database and runtime: PostgreSQL is recommended for production, and recent releases require PostgreSQL 14 or newer and Python 3.10 or newer, so confirm your platform versions before choosing a release.
- Scaling model: Workers connected through Redis let you split client, federation and event traffic across processes once a single node is no longer enough.
- Commercial option: Element offers commercial licenses and the Synapse Pro edition, which removes the AGPL obligations for organizations that cannot accept them.
- Upgrade discipline: Upgrade notes warn that rolling back can be difficult because of schema changes, so plan database backups before every upgrade.
Confirm with the Element project which Synapse release line, feature set and support terms apply to your use case, and check the Synapse upgrade notes before you pin a version.
Dendrite is a Matrix homeserver written in Go, also from Element, and distributed under AGPL-3.0-or-later. It is a separate codebase from Synapse, built to use fewer resources and a different process model. It fits teams with Go experience who want a server they can read and operate in a single language, and who accept the AGPL terms in the same way they would for Synapse. Teams should not assume Dendrite matches Synapse on every feature or federation behavior, so compare them directly for the features they need.
- Language and footprint: The Go implementation suits teams that already operate Go services and want to standardize their tooling.
- Same license family: AGPL-3.0-or-later carries the same network-use source disclosure considerations as Synapse, so the legal review is similar.
- Feature coverage: Confirm which Matrix specification features, bridges and admin APIs your users depend on, because coverage can differ from Synapse.
- Community and vendor support: Ask Element and the wider Matrix community how actively Dendrite is developed and supported for your release.
- Operational tooling: Check whether your monitoring, backup and identity integration patterns have documented examples for Dendrite, or whether your team will write them.
Confirm feature parity, federation behavior and support status for your use case with the Dendrite project and Element before you commit.
Conduit is a lightweight Matrix homeserver written in Rust and licensed under Apache-2.0. The permissive license is the main reason organizations look at it, because it avoids the AGPL source disclosure duties attached to Synapse and Dendrite. It fits small deployments, labs and organizations with a strict license policy that prefer a permissive license. Its maturity, feature coverage and release cadence should be verified before it carries production traffic for a regulated team.
- License fit: Apache-2.0 permits use and modification without the network-use disclosure obligations of AGPL, which can simplify legal review.
- Resource profile: Conduit was designed to be small, which suits modest single-node deployments.
- Feature gaps: Confirm support for the clients, bridges, identity integrations and admin functions your users need, since a smaller project may cover fewer of them.
- Upstream activity: Check the project's current release history and issue handling before you depend on it for compliance-relevant chat.
- Support path: Without a commercial vendor in the same way as Element, ask who will fix security issues and how quickly, and whether you will need your own maintenance capacity.
Confirm release status, security response and feature parity for your use case with the Conduit project before you choose it for a production environment.
Continuwuity and Tuwunel are Rust forks of Conduit, both listed under Apache-2.0 on the Matrix.org server list. Forks can diverge in direction, release practice and feature coverage, so each needs its own evaluation rather than being treated as interchangeable. They fit teams that want a permissively licensed Rust server and are comfortable following an active fork's roadmap. The main risk is governance: a smaller project may change maintainers, priorities or release rules with little notice.
- Fork lineage: Both descend from Conduit, but their development choices and feature sets have diverged, so do not assume one behaves like the other.
- Permissive license: Apache-2.0 keeps the license question simple for internal use and modification.
- Maintainership: Review who maintains each fork, how decisions are made and how security fixes are published.
- Migration risk: Moving between a fork and Synapse later means a database and data migration project, so pick the option you expect to keep.
- Testing: Run your own federation, bridge and client tests against the exact release you plan to deploy.
Confirm maintainership, release status, feature parity and security response for each fork with its project before you select one.
The licensing question usually decides the shortlist before features are compared. Synapse and Dendrite are AGPL-3.0 or AGPL-3.0-or-later, which means organizations that modify and offer the server to users over a network must meet source disclosure duties, or buy a commercial license. Conduit and the Rust forks are Apache-2.0, which avoids those duties but shifts more evaluation work onto your team. This tab is a decision aid, not legal advice, and the answer depends on how you intend to modify and host the server.
- Unmodified use: Running an unmodified AGPL server internally has different obligations from modifying it and offering it to outside users, so confirm your scenario.
- Commercial licenses: Element sells commercial licenses and Synapse Pro, which may resolve AGPL concerns for some organizations.
- Support versus permissiveness: Synapse and Dendrite come from a vendor with a commercial relationship, while the Apache-2.0 options rely more on community maintenance.
- Documented risk: Record the license decision, the reviewer and the conditions in your architecture file.
- Exit path: Pick a server you can migrate away from, since changing homeservers later affects accounts, rooms and history.
Ask your legal and procurement teams to review the specific license terms and your planned use, and confirm support terms with the vendor or project before you commit.
Discord vs Matrix side by side on capabilities and licensing
This table compares how Discord's community model and a self-hosted Matrix homeserver with Element clients handle structure, roles, identity, federation and licensing. Rows marked as items to verify are Discord behaviors that the supplied research does not confirm, so check them in Discord's own documentation before deciding.
| Capability | Discord (hosted) | Self-hosted Matrix (Synapse with Element) |
|---|---|---|
| Server and room structure | Servers contain channels and categories managed by the server owner. Verify current channel and thread limits in Discord's documentation. | Rooms are created on your homeserver, identified by room IDs, and can be public, invite-only or joined by space membership. Users are identified as @user:server_name. |
| Roles and moderation | Server roles and moderation tools are configured by the owner and moderators. Verify the exact permission model and automod options in Discord's documentation. | Moderation is handled by room power levels and server admins. Admin and moderation tooling depends on the client and deployment, so confirm the features you need with Element's documentation. |
| Identity and sign-in | Accounts are Discord user accounts. Organizations generally cannot bring their own identity provider to a community server. Verify this in Discord's documentation. | Synapse supports single sign-on through OpenID Connect providers (oidc_providers), SAML2 (saml2_config) and CAS, as described in its configuration manual. |
| Federation controls | Discord is a single hosted network. Organizations cannot choose which external servers can join. | Federation can be restricted with federation_domain_whitelist, an empty list disables it. Federation uses port 8448 by default, and delegation can serve user IDs from another host on port 443. |
| Data retention and export | Retention and export of server-wide history are not covered by the supplied research. Confirm what Discord provides for owners in its documentation. | Your homeserver database holds message history, so retention and backup policies are set by your organization. Confirm how your chosen retention settings work in your Synapse version. |
| Core server license | Discord is a proprietary hosted service governed by Discord's terms. | Synapse is distributed under AGPL-3.0, with commercial licenses also available from Element. Dendrite is also AGPL-3.0-or-later. |
| Licensing options from the vendor | Discord is not offered as a self-hosted product. | Element Server Suite has a free AGPL Community edition with Synapse and Element Call, a Pro edition with Synapse Pro, and a Sovereign edition for air-gapped deployments. |
What does not map cleanly from Discord to Matrix
Discord's community tools do not have one-to-one equivalents in a self-hosted Matrix deployment, and the gaps matter most for public communities. Discovery and growth features, such as server directories and invite-driven growth loops, are built into Discord's hosted service. Matrix has public room directories and space hierarchies, but a self-hosted homeserver does not bring a built-in discovery network with it, so the operator must decide how new members will find the community. Voice and stage channels are also a gap to plan for. Matrix supports calls through Element Call, but you should confirm with Element and the Matrix ecosystem whether the audience sizes, stage-style moderation and recording you need are covered by your chosen components.
Bot and integration behavior changes as well. Discord bots run against Discord's gateway and API, while Matrix bots and bridges run against the Matrix client-server API and the homeserver's application service interface. Many Discord bots will need rewriting or replacement, and the Matrix ecosystem page lists bridges and tools you should check against each feature you rely on. The way members join also changes. Federation is controlled by the homeserver: server_name fixes how identities and rooms are named, and federation_domain_whitelist decides which servers you talk to. Joining a space depends on invites, room visibility and the client a member uses, so onboarding flows need to be tested with real members rather than assumed.
Before you decide, write a short list of your must-have features, such as public discovery, voice and video, moderation roles, bot commands, age gating, and member onboarding. Mark each one as native, provided by a component you would run, or missing. Then confirm every item with Element for the commercial and server suite options, and check the Matrix ecosystem for the clients and bridges involved. Anything still unconfirmed should become a pilot test, not a launch assumption.
How hosting, identity and compliance change with a self-hosted Matrix server
Moving from Discord to a self-hosted Matrix homeserver shifts where messages live, who signs people in, how long history is kept and who answers for exposure to other servers. Each card below names one control, the condition under which it matters, and what to confirm before choosing a hosting model. DeployOpen prepares these controls and collects evidence for compliance assessments, but independent auditors and certification bodies issue any audit reports.
Data location and residency
A self-hosted Synapse homeserver stores rooms, events, media and user records in the PostgreSQL database and media store you operate, so the location is a decision you make rather than a vendor setting. This matters most when members are subject to residency rules or when community data must stay in a specific country. Check where the database, backups and media files sit, and confirm that replicas and log shipping follow the same rule. Map every copy of message data before go-live.
Hosting model selection
The hosting choice is between your own cloud account, a data center you run, or an air-gapped network. Element Server Suite offers a free AGPL Community edition, a Pro edition with Synapse Pro, and a Sovereign edition for air-gapped deployments, so the licensing path depends on the network you need. Ask Element which edition covers your target environment and whether the components you need are included. Plan for the Synapse upgrade notes, which warn that rolling back can be difficult because of schema changes.
Identity integration with existing providers
Discord accounts are managed by Discord, while a Matrix homeserver can accept logins from your own identity provider. Synapse supports OpenID Connect through oidc_providers, SAML2 through saml2_config, and CAS, so you can tie membership to the directory you already run. Confirm which protocol your identity provider supports, how deprovisioning removes access to rooms, and whether community members without corporate accounts need a separate path. Matrix Authentication Service documents how upstream identity providers are configured.
Retention and moderation ownership
Discord controls message history, moderation tools and reporting for the servers you join, while on Matrix you decide how long events and media are kept and who holds moderator powers in each room. Retention rules, redaction policies and admin access are part of your operating procedure, and they must match any legal hold or records obligation you carry. Write down who can redact content, who reviews reports and how long media is retained, then test those steps on a staging server. Ask your counsel whether the retention policy meets your own obligations.
Federation exposure
Federation lets your users talk with people on other Matrix servers, and it also exposes your homeserver to inbound traffic on port 8448 unless you restrict it. Setting federation_domain_whitelist limits federation to listed domains, and an empty list disables it, so a closed community can run with no external exposure. The Synapse docs also recommend firewalling the federation listener, which needs coordination with your network team. Decide whether the community should federate at all before you publish DNS records, and review the list of allowed domains on a schedule.
Compliance evidence and records
Auditors will ask for proof that access controls, logging, backups and change management work as described, and a Matrix deployment creates that evidence only if you collect it. DeployOpen can prepare the controls, configuration baselines and evidence packs that an assessor reviews, but DeployOpen does not issue audit reports, attestations or certifications. Ask your assessor which control frameworks apply and which artifacts they expect, such as configuration exports, access reviews and restore tests. Confirm these requirements in writing before scoping the implementation.
Discord vs Matrix cost of ownership: what you pay for and why
The cost comparison comes down to who pays for what, and which costs are one-time versus recurring. On the Discord side, the visible line item is any subscription the organization buys, plus any server boosts or paid features it chooses to add. Those prices change, so confirm current figures on Discord's own pricing pages before you build a budget. Discord's recurring cost is mostly predictable, but the bill does not include the staff time spent on moderation tooling, bots or the audit work that a compliance review will ask for. On the Matrix side, the costs are different in kind: you pay for the servers that host the homeserver, a PostgreSQL database (Synapse recommends PostgreSQL for production, and Synapse 1.143.0 and later require PostgreSQL 14 or newer), and Redis if you scale out with workers. You also pay for people to run upgrades, monitoring, backups and identity integration. Synapse 1.143.0 and later require PostgreSQL 14 or newer, and 1.142.0 and later require Python 3.10 or newer, so a version jump can trigger database work you did not plan for.
One-time costs include planning, identity integration with your SSO provider, client rollout, and any migration of community history. Recurring costs include hosting, database and storage growth, upgrades, monitoring, backups, and support. The main cost drivers are the number of active users and rooms, how much media members upload, how long you retain messages, and how many federation peers you serve. Element's licensing is a separate decision. Synapse is AGPL-3.0, so a self-hosted deployment under the AGPL has no license fee, but if your legal team needs terms that the AGPL does not provide, Element sells commercial licenses, and Element Server Suite comes in a free Community edition, a Pro edition with Synapse Pro, and a Sovereign edition for air-gapped deployments. Confirm with Element which edition fits your obligations and what support is included.
When you request a written quote, ask for each component on its own line: infrastructure sizing for the homeserver, PostgreSQL, Redis and media storage; the upgrade cadence and who performs it; backup and restore testing; monitoring and alerting scope; identity integration; and whether a commercial Element license is included or priced separately. Ask which items are one-time and which recur, what triggers a price change, and what happens to the bridge or migration work if the scope changes. A fixed-scope quote, agreed in writing before work starts, makes it easier to compare with a Discord subscription than an open-ended estimate. DeployOpen provides quotes against a written scope, and the reader should check every assumption in that scope against their own user count, retention rules and compliance needs.
How a move from Discord to a self-hosted Matrix server proceeds
The sequence turns an informal Discord community into a Matrix homeserver that the organization names, hosts, authenticates and moderates, with a tested pilot and a planned transition before the old server is retired. Each phase closes with a written output that the next phase depends on.
Inventory servers, channels, roles and bots
The community owner, moderators and whoever administers the Discord server list every channel, category, role with its permissions, bot and webhook, and integration that members rely on. Discord does not offer a direct importer to Matrix in the supplied facts, so this list is a manual design document rather than an export. Record which channels carry decisions, which carry community history and which can be retired. The step is done when the list is signed off by the people who will own the Matrix rooms and spaces after the move.
Decide server_name and domain
Choose the server_name that will appear in every user ID and room ID, such as the part after the colon in @user:example.com. Synapse's federation docs explain that this value fixes how users and rooms are identified, and it is difficult to change later, so it is decided before any account exists. Decide whether the homeserver runs on the apex domain or a subdomain, and whether delegation will serve user IDs from another host on port 443. The step is done when the domain, DNS plan and federation stance are written down and approved, including whether federation is enabled at all.
Deploy Synapse and set up the database
The infrastructure team deploys Synapse in the organization's own cloud account, data center or air-gapped network, with PostgreSQL as the production database. Synapse's upgrade notes state that 1.143.0 and later require PostgreSQL 14 or newer and 1.142.0 and later require Python 3.10 or newer, so confirm those versions before installation. Plan for the upgrade notes' warning that rolling back can be difficult because of schema changes. Configure the federation_domain_whitelist setting and firewall the federation listener if federation is restricted. The step is done when the server answers on its client and federation endpoints and a test account can log in.
Integrate identity and single sign-on
The identity team connects Synapse to the directory the organization already uses through oidc_providers, saml2_config or CAS, as described in the Synapse configuration manual. Confirm which attributes map to the display name and the user ID, and decide who may create accounts. The Matrix Authentication Service documentation covers upstream identity providers if that component is part of the design. The step is done when a user signs in through the chosen provider and the account is created with the expected identifier, and when deprovisioning a user in the directory is tested.
Run a pilot with a small group
A small group of moderators and active members uses the new server for a defined set of rooms and spaces, recreating the Discord roles as Matrix power levels and testing the moderation tools the community will rely on. Test media upload, notifications on mobile and desktop Element clients, and any bot that replaces a Discord integration. Record what breaks and what members find confusing. The step is done when the pilot group signs off on the room structure, the moderation process and the backup and restore test, and every open issue has an owner.
Onboard members in planned waves
Community managers invite members in batches, publish a short guide for the Element client, and set expectations about which rooms have moved. Support volume is highest in the first days, so the team staffs that period and keeps a list of common questions. If the community wants members to keep using Discord during the move, the bridge pages in this group describe that approach. The step is done when the target membership has accounts, the main rooms are populated, and the support queue has settled to the level the owners agreed.
Run a transition period and retire the old server
The owners keep the Discord server available for a defined transition so late members can find the new rooms and copy anything they need. Announce a retirement date in writing, archive what the community still wants from Discord through each member's own data package, and state clearly that past channel history cannot be pulled from those packages. The Discord migration and bridging pages in this group explain how transitions run in practice. The step is done when the Discord server is read-only or closed, the new server has its backup schedule and monitoring running, and the owners have a documented runbook for upgrades.
Questions buyers ask before switching from Discord to Matrix
What does a self-hosted Matrix deployment cost, and what drives the price up?
The cost splits into one-time work and recurring operation. One-time work covers design, installation, identity integration, client rollout, and testing. Recurring cost covers the servers, database, backups, monitoring, upgrades and the staff time to run them. Synapse itself is AGPL-3.0 licensed and Element's Community edition of Element Server Suite is free under AGPL, so software licensing is not usually the main line item. The largest drivers are the number of users and rooms, whether you need federation, whether you need high availability through workers and Redis, and how much custom identity or moderation tooling you require. Ask any implementation partner for a written scope that lists each of these components separately, so you can compare the one-time and recurring parts with your current Discord spend and internal staffing.
How long does a Matrix pilot or cutover usually take?
The duration depends on scope rather than on a fixed number, so ask for a timeline in the written scope instead of relying on a general estimate. A pilot usually covers one or two communities or teams, a test homeserver, a chosen client, and a short run with real members. A cutover adds DNS and TLS setup, production database and backups, identity integration, user communication, and a plan for how long the old Discord server stays open. Timing is most affected by how many channels and roles must be recreated, how many people must change clients, and how complex the sign-in setup is. Confirm the milestones, the acceptance criteria for each one, and the date on which Discord stops being the primary channel.
Can our internal team run Synapse without outside help?
Many teams can, but only if they already operate PostgreSQL, reverse proxies, and certificate management and can staff an on-call rotation. Synapse requires PostgreSQL for production, and recent releases require PostgreSQL 14 or newer and Python 3.10 or newer. The upgrade notes warn that rolling back can be difficult because the database schema changes between releases, so upgrades need a tested plan and a backup taken before each one. Scaling to workers adds Redis to the design. An honest self-assessment asks whether your team has done this before, who reads the release notes, and who takes the call at night. If the answer is unclear, a fixed-scope engagement can cover the build and handover, and a retainer can cover upgrades and testing afterward.
What does our organization have to provide before a Matrix server can go live?
Plan for several prerequisites that Discord currently handles for you. These include a stable server_name that will not change later, because it identifies every user and room. You need DNS records and TLS certificates for the homeserver and, if you federate, delegation so that user IDs on your domain resolve to the right host. Federation listens on port 8448 by default, so firewall rules and any load balancer must account for it. You also need a PostgreSQL database with backups, an identity provider for single sign-on through OpenID Connect, SAML2 or CAS, a monitoring setup, and named owners for on-call and incident response. Ask the partner to list each prerequisite, who supplies it, and which items are blockers for the pilot.
Can Matrix keep the message history from our Discord server?
No standard importer moves a Discord server's full history into Matrix, so plan for history to stay on Discord or in an archive. Discord's per-user Data Package contains only a user's own data, which does not reconstruct a community's channels. Bridges such as mautrix-discord can relay messages during a transition, but a bridge's backfill behavior has limits that you must test on your own server. For regulated teams, the practical decision is which records must be retained, where the archive will live, and who can search it. Ask the partner to document what the bridge carries, what it does not carry, and how the archive will be produced and verified.
What does the work require for moderation, retention and access control?
Matrix provides room permissions, power levels, and server administration, but Discord's bot ecosystem, role names and automated moderation features will not transfer automatically. You must decide how moderators are assigned, which rooms are public or invite-only, how bans and reports work, and how long messages are kept. Retention and deletion behavior should be written into the design, along with who may export data and under what approval. Ask for a written list of roles, moderation procedures and retention rules, and confirm which of these must be tested before go-live.
When does a support retainer make sense after go-live?
A retainer makes sense when the cost of falling behind on upgrades, backups, security testing or incident response exceeds the cost of a steady external service. Synapse releases frequently, and the upgrade notes say support for Python and PostgreSQL versions ends at upstream end of life, so someone must plan those changes. Ongoing support, upgrades and continuous testing are available as DeployOpen retainers, and most engagements are fixed-scope before that. Compare retainer scope with what your own team can absorb, and ask for the response expectations and the upgrade cadence in writing before you sign.
How DeployOpen helps evaluate, implement and migrate a Matrix server
DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Discord vs Matrix, we start with a written scope that defines the server, clients, identity integration, moderation and retention rules you need before any build begins.
How we scope
- Map which Discord servers, roles, channels and bots your community actually depends on today
- Agree in writing how Matrix rooms, spaces and power levels will mirror those roles
- Define federation policy, including whether federation is off, restricted to listed domains or open
How we build
- Deploy Synapse with PostgreSQL and configure server_name, delegation and the federation listener
- Connect single sign-on through OIDC, SAML2 or CAS if your identity provider requires it
- Test Element clients, media handling, retention settings and moderation tooling before go-live
How we hand over
- Document the deployment, configuration keys, upgrade path and rollback limits for your team
- Set up backups of the database and media store, with restore tests you can repeat
- Train moderators and administrators on room permissions, reporting and account deactivation
How we support
- Provide ongoing support, upgrades and continuous testing as a retainer after handover
- Review Synapse release notes and schedule upgrades around database schema changes
- Revisit federation and access settings whenever your community or compliance needs change
