Migrate Synapse authentication to MAS

Migrate Synapse authentication to Matrix Authentication Service only after the readiness checks pass

The move from local or SSO-backed Synapse authentication to Matrix Authentication Service (MAS) is feasible only when your Synapse setup avoids unsupported password providers and the Synapse database is PostgreSQL, since MAS supports only PostgreSQL and the syn2mas tool reads only from a PostgreSQL Synapse database. Beyond that, the effort depends mostly on what the readiness checks report and on the downtime window your organization can accept. Treat the readiness results as the decision point, not a formality: if they show a blocker, the project stops or changes shape before any data moves. The central tool is syn2mas, which imports users from the Synapse database into MAS. The real migration requires homeserver downtime and is not easily reversible, so the sequence matters. Start with the configuration check, which finds problems without stopping Synapse. Then run a dry run, which performs a full import and then empties the MAS database, giving you a representative timing for the real window. Only after both have passed should you schedule the production cutover. Ask the team running the work to show you the check output and the dry-run log, not a summary of them.

Confirm which authentication methods are in use today. Synapse can authenticate users through local passwords, OpenID Connect providers (oidc_providers), SAML2 and CAS. MAS does not support SAML directly and recommends a bridge such as Dex for SAML or LDAP, so a SAML or LDAP dependency is a blocker to resolve in design, not during the cutover. Custom password providers are also a blocker. Inventory every entry in your homeserver configuration, including any module or provider loaded from a file, because a single unlisted provider can invalidate the plan. Record the result in writing, with the name of the person who confirmed each item.

Password hashing needs its own check. Synapse hashes passwords with bcrypt, while MAS defaults to argon2id, so migrated passwords must be imported under a version 1 bcrypt scheme with unicode_normalization set to true. If your Synapse uses a pepper, the same pepper value must be configured in MAS, or existing passwords will not verify. Confirm these settings in the MAS configuration before the dry run, and check that a test user can sign in after the dry-run import. A password that works in Synapse but fails in MAS will generate support tickets on cutover day, so test with several accounts, including ones with non-ASCII characters in their passwords.

Plan the upstream identity mapping before you migrate. MAS delegates sign-in to upstream OpenID Connect providers such as Keycloak, Microsoft Entra ID, Google or Authentik, so each existing SSO path must map to a configured upstream provider. Decide how existing user accounts link to upstream identities, and test that a user who signs in through SSO today lands on the same Matrix account after migration. Mismatched subject identifiers or changed user IDs are a common reason the cutover fails, so verify the mapping with real accounts in the dry run rather than assuming it holds. Finally, plan the window and the rollback. Before MAS starts, rolling back needs no Synapse restore, because the tool never writes to the Synapse database. After MAS starts and users sign in against it, a return to the old setup is a different and harder decision. Agree in advance who can call a rollback, the time limit for that call, and what communication goes to users. Confirm the downtime length from your own dry-run timing, not from an estimate.

What maps cleanly from Synapse logins to MAS and what does not

This table compares each Synapse login method and database setting with its Matrix Authentication Service counterpart and notes what needs action before migration. Read the middle column as the target state and the right column as the work or decision it creates. Any row marked as blocking should be settled before you schedule the downtime window.

Synapse source capability	MAS equivalent	Migration notes
Local password accounts	Local accounts stored in the MAS database after syn2mas import	Users keep their passwords, but the stored hashes must be readable by MAS. Confirm that every active account has a local password before cutover.
bcrypt password hashes	Version 1 bcrypt scheme with unicode_normalization set to true	MAS defaults to argon2id, so the bcrypt scheme must be configured explicitly. Set the same pepper as Synapse if one is in use.
OIDC providers in oidc_providers	Upstream OpenID Connect providers such as Keycloak, Microsoft Entra ID, Google or Authentik	Map each Synapse provider to an upstream entry in MAS and confirm that the identity claims match. Plan the user linking step so existing accounts are not duplicated.
SAML2 through saml2_config	Not supported by MAS	MAS does not support SAML. Put a bridge such as Dex in front of the SAML identity provider, or confirm another route, before planning the migration.
CAS	Not a native MAS upstream	Confirm whether a CAS-to-OIDC bridge is available in your environment. Treat CAS users as a blocking item until the route is tested.
LDAP authentication	Not a native MAS upstream; use a bridge such as Dex for LDAP	Identify which LDAP users log in through Synapse and how they will authenticate under MAS. Test a sample of accounts in a staging copy.
Custom password providers	No direct equivalent	Custom password providers need a separate decision before planning. Each one must be replaced, bridged or retired, and this can change the scope of the project.
SQLite versus PostgreSQL database	MAS supports only PostgreSQL, and syn2mas reads only from PostgreSQL	A SQLite Synapse must be moved to PostgreSQL before syn2mas can run. Plan that move as a separate project with its own downtime and verification steps.

Which Synapse authentication setups block the syn2mas migration

Start with the database, because it decides whether the migration can run at all. The syn2mas tool reads only from a PostgreSQL Synapse database, and MAS itself supports only PostgreSQL. If your homeserver still runs on SQLite, the authentication migration is not the first step. Move the database first, then return to these checks against the PostgreSQL copy. Confirm the database engine in your homeserver configuration and in the running environment, since a file left over from an earlier setup can be misleading.

Next, look for password sources that sit outside Synapse's built-in password store. A saml2_config block, an LDAP password provider module or a custom password provider in the password_providers section each means users may not authenticate against a password Synapse holds. Those setups need a different plan before migration: SAML users generally need to move to an OpenID Connect upstream, because MAS does not support SAML directly and its documentation recommends a bridge such as Dex for SAML or LDAP sources. Write down every provider you find, including any that were added years ago and are no longer used, since each one must be accounted for.

Then review the oidc_providers block line by line. Each entry is an upstream identity provider that MAS will need to recognize, so note its issuer, its client registration and the attribute used to map users to Matrix IDs. Check that every provider you intend to keep is one MAS can use as an upstream OpenID Connect provider, and confirm with the provider's vendor or project how its claims are named if the documentation is unclear. If a provider is not documented for this use, put that question to the vendor or project before committing to a date.

Run mas-cli syn2mas check against a copy of your real configuration and database, not a tidied sample. The check reports configuration problems without stopping Synapse, so it is safe to run on a live system, but it is only useful if it sees the same providers and settings that production uses. Treat each reported problem as a blocker to resolve or a decision to record. Repeat the check after every change until it runs clean. Only then should you set the downtime window, because the dry run and the real migration depend on a configuration that has already passed.

Which documented tools move Synapse users into MAS

The syn2mas tooling supports three stages: a configuration check that does not stop Synapse, a rehearsal that imports everything into MAS and then clears it, and the migration itself with Synapse offline. The cards below cover each stage and the source constraint that shapes all of them.

Configuration check with syn2mas check

Run mas-cli syn2mas check before you schedule anything. It finds configuration problems without stopping Synapse, so the homeserver keeps serving users while you work. Use its output to find blockers such as unsupported password providers and settings that do not match the password hash plan covered earlier on this page. Fix the issues in Synapse's configuration, then rerun the check until the output is clean. Confirm the exact invocation, config file inputs and output format in the MAS migration documentation.

Rehearsal with a dry run

Run syn2mas migrate with the --dry-run option to perform a full import into MAS. The tool then empties the MAS database, so the rehearsal leaves no migrated users behind. The run gives a representative timing for the import, which you should record along with the data volume and hardware used. Treat that timing as the basis for the downtime window in your change plan, not as a guarantee for the live run. Before you start, confirm the MAS database holds nothing you need, because the rehearsal clears it.

Migration with Synapse downtime

The real syn2mas migration requires homeserver downtime, so Synapse must be stopped while users move into MAS. Size the window from the timing your dry run produced, and agree it in advance with the teams that own user communication and on-call cover. The migration is not easily reversible, so write the go or no-go criteria and the person who makes the call before the window opens. Check the MAS migration documentation for the flags that apply to your deployment.

Read-only access to Synapse data

syn2mas reads only from a PostgreSQL Synapse database and never writes to it. If your homeserver still runs on SQLite, move the data to PostgreSQL before you plan the migration, because the tool cannot read from SQLite. Since the Synapse database is not modified, rolling back before MAS starts needs no Synapse database restore. Still keep a verified backup of the Synapse database, and confirm that the account syn2mas uses has read access only.

How bcrypt password hashes carry over to MAS, which defaults to argon2id

Synapse stores local passwords as bcrypt hashes, while Matrix Authentication Service defaults to argon2id. Because syn2mas copies existing password hashes rather than asking users to reset them, MAS has to be told how to verify bcrypt. In practice that means configuring a version 1 bcrypt password scheme with unicode_normalization set to true, so MAS accepts the hashes Synapse already holds. Before the first real migration, confirm the password section of your own Synapse configuration and match it in the MAS configuration you plan to use. Do not assume the defaults on either side line up.

Check the pepper as well. If your Synapse configuration sets a password pepper, MAS must be configured with the same value, or every migrated hash will fail verification even though the hash itself was copied correctly. Treat the pepper as a secret: store it in your secrets manager, keep it out of shared configuration files, and make sure the value used in the dry run is the one you will use in production. Ask whoever maintains your Synapse deployment whether a pepper was ever set, since it is easy to forget a setting that was added years earlier.

The failure mode deserves planning because it is quiet. A wrong pepper or a missing unicode_normalization setting does not stop the migration or produce a clear configuration error. The migrated accounts exist, the login request reaches MAS, and then the password is rejected. Users see what looks like a forgotten password, and support queues fill with reset requests that do not fix anything. Your runbook should name this risk explicitly, and your communications plan for the downtime window should tell users that their existing passwords stay the same.

Build verification into the sequence. Run the syn2mas check and the dry run, then, before you open the service to users, sign in with a sample migrated account from each password-based group you have. Use a test account created for this purpose where possible, and record the result. A failed sample login points to either the pepper or the normalization setting, and you should fix that before the real migration rather than during the downtime window. Repeat the sample login after the real migration as well, because the dry run uses a throwaway database and does not prove the production database behaves the same way.

Confirm the scheme choice with your own team and with the MAS documentation for the version you deploy, since the exact configuration keys and defaults can change between releases. Also decide what happens to accounts that authenticate only through an upstream identity provider, because those do not depend on a local bcrypt hash at all. If your organization is planning to move everyone to single sign-on later, record that plan so the password scheme is treated as a transitional setting and not a permanent one.

How Synapse SSO providers map to upstream identity providers in MAS

Synapse sites that already sign users in through oidc_providers are the closest match to MAS. MAS also acts as an OpenID Connect client of an upstream identity provider, so the existing provider can often stay in place. The MAS documentation names Keycloak, Microsoft Entra ID, Google and Authentik as upstream OpenID Connect providers. The work is mainly in how MAS is configured to reach that provider and how existing accounts are matched to it.

Focus on these points:

Confirm the provider is supported. Check the upstream identity provider page in the MAS documentation for your MAS version.
Record the existing subject for each user. Export the link between each Synapse user and the external account they signed in with, so every account can be matched to the same upstream subject in MAS.
Check the redirect URI. Ask whether the existing client registration can accept the MAS redirect URI, or whether a new client is needed.
Keep the claims consistent. Confirm which claim MAS uses to identify the user and that the value matches what Synapse stored.
Test every provider in the dry run. Sign in with a test account for each oidc_providers entry against the dry run MAS.

Before cutover, confirm that every active user resolves to exactly one upstream subject in the dry run environment.

MAS does not support SAML. If your Synapse uses saml2_config, your users cannot be sent straight to MAS through SAML. The MAS documentation recommends a bridge such as Dex for SAML, so the bridge presents an OpenID Connect interface to MAS while it talks SAML to your identity provider. Decide on this path before you plan the migration window, because the bridge becomes a new service that must be running for sign-in to work.

Focus on these points:

Expect a readiness blocker. Run mas-cli syn2mas check against your Synapse configuration. SAML configuration must be removed or bridged before the migration can proceed.
Deploy the bridge first. Confirm the Dex version you will run and the connector that matches your SAML identity provider.
Carry the stable identifier through. Confirm which SAML attribute the bridge passes to MAS as the user identity, and that it matches the value Synapse stored for each user.
Include the bridge in the dry run. It must be reachable from the dry run MAS, with the same settings planned for production.
Test SAML-origin accounts individually. Sign in with accounts from each SAML source through the bridge.

Before cutover, confirm that each SAML-origin account resolves to the same identity through the bridge as it did in Synapse.

How the readiness run, dry run, downtime window and cutover fit together

This sequence moves a Synapse homeserver from its own authentication to Matrix Authentication Service through a planned, approved outage. Each step produces a check or record that the next step depends on, and the dry run timing sets the downtime window.

Inventory the Synapse auth configuration and database
Your team lists every authentication path in the homeserver configuration: local password accounts, any SAML2, LDAP or CAS settings, custom password provider modules, and OIDC providers that will become upstream identity providers in MAS. Confirm the database is PostgreSQL, because syn2mas reads only from PostgreSQL. Record the password hash settings in use, since Synapse hashes with bcrypt and the MAS migration needs matching bcrypt settings, including any pepper. Done when the team has a written inventory that the remaining steps can check against.
Run syn2mas check against the live setup
Run mas-cli syn2mas check against the existing Synapse configuration and database. The check reports configuration problems and does not stop Synapse, so users stay online while it runs. Fix each finding in the Synapse configuration or the planned MAS setup, then rerun the check until it reports no blocking issues. Any SAML, LDAP or custom password provider it flags blocks this migration path and needs a decision before further work. Done when the check passes and every remaining finding has a named owner.
Rebuild a staging MAS and run the dry run
Build a staging MAS on PostgreSQL, sized as closely to production as your environment allows. Configure the upstream identity providers and set the bcrypt password scheme with unicode normalization enabled, plus the pepper if Synapse uses one. Then run mas-cli syn2mas migrate with the dry run option. The dry run performs a full import and then empties the MAS database, so you can repeat it after configuration changes. Record the timing it reports and any warnings. Done when the team holds that reported timing and a list of warnings with owners.
Agree the downtime window with users
Use the reported dry run timing as the core of the window, then add time for the steps around the import: stopping Synapse, running the migration, starting MAS and checking sign-in. Confirm the window with business owners, the support desk and room administrators, and agree what users will see while Synapse is unavailable. Ask the MAS project documentation and your own change process what notice and approvals they require. Done when the window is approved in writing and the support team has the message it will send to users.
Perform the production migration with Synapse down
Stop Synapse and its workers so nothing writes to the database, then take a backup of the PostgreSQL database and confirm it can be restored. Run the syn2mas migration against the production MAS database and watch the output for errors. Compare the run with the dry run output to confirm the same warnings appear. The migration requires homeserver downtime and is not easily reversible, so do not start it until the backup is verified and the rollback plan is agreed. Done when the tool completes without errors and the output log is saved.
Start MAS and confirm sign-in and rollback position
Start MAS, point Synapse at it, and sign in with a test account for each identity path: local password accounts and each upstream provider. Confirm that migrated passwords verify. Record the rollback position: before MAS starts, rollback needs no Synapse restore, because syn2mas never writes to the Synapse database. Once MAS has issued sessions to users, rollback becomes a separate decision, so confirm its steps in the migration documentation before the window opens. Done when test sign-ins pass on every path and the rollback decision is written down.

What drives the cost and duration of a Synapse to MAS move

This table lists the drivers that change the effort and cost of a Synapse to MAS move, with what to ask for in a written quote. Read each row as a question to answer about your environment before requesting a fixed scope. Most of the cost is one-time work (analysis, configuration, the dry run, cutover support and post-cutover checks), while running MAS afterward is an ongoing operational cost.

Driver	Why it changes effort	What to ask for in a quote
Local accounts and user database size	More accounts lengthen the import and the post-cutover verification. The dry run timing is the most reliable measure of the import itself.	The dry run timing, account counts by type, and a plan for sampling accounts after cutover.
Upstream identity providers	Each provider needs its own MAS configuration, claim mapping and matching of existing Synapse user IDs. Every additional provider adds mapping decisions and tests.	The number of providers, the mapping rules for each, and who supplies the client registrations.
SAML, LDAP or custom password providers	MAS does not support SAML directly and recommends a bridge such as Dex for SAML or LDAP. A custom password provider has no direct equivalent and may need redesign.	Whether a bridge is in scope, how it will be deployed and tested, and a separate estimate for any custom provider redesign.
Password hashing settings	Synapse uses bcrypt, so MAS needs a matching bcrypt scheme with unicode normalization and the same pepper if one is set. A mismatch blocks sign-in for existing users.	A check of hash settings against a test account before the dry run, and the steps for correcting a mismatch.
Hosting platform and PostgreSQL access	The syn2mas tool reads only from PostgreSQL, so a Synapse still on SQLite needs a separate move first. Database access, network paths and the MAS hosting setup set the pace of the work.	The PostgreSQL version and access method, whether a SQLite move is in scope, and who grants database and host credentials.
Downtime window approval	The real migration requires homeserver downtime and is not easily reversible, so change approval, user communication and any rescheduling add lead time.	Who approves the change, the window length agreed in writing, and the cost of a rescheduled cutover.
Client sign-in test coverage	Each client and login path that must work after cutover needs a test case. Thin coverage moves verification onto your team during the window.	A test matrix covering clients and login methods, and who runs and signs off the post-cutover checks.
Rollback planning	Before MAS starts, the tool never writes to the Synapse database, so rollback needs no Synapse restore. Once MAS takes logins, the rollback path must be planned and tested separately.	The rollback steps for each phase, the decision point for invoking them, and who makes that decision during the window.

What goes wrong during the Synapse to MAS cutover and how to prevent it

Five points in the Synapse to MAS cutover need decisions before a window is booked: password hash configuration, upstream identity mapping, whether the deployment fits the direct migration path, how long downtime will last, and which clients and bridges still depend on old endpoints. Each card names the check to run and what to confirm in your own environment.

Password hashes fail to verify

Synapse hashes passwords with bcrypt, and MAS defaults to argon2id. Migrated accounts need a version 1 bcrypt scheme with unicode_normalization enabled, plus the same pepper if Synapse uses one, or existing passwords will be rejected. Run mas-cli syn2mas check, then sign in with a test account from each user population. Confirm the hashing settings in both your Synapse and MAS configuration files before the cutover.

Identities do not match upstream subjects

MAS links each migrated user to the subject identifier issued by the upstream OpenID Connect provider. If the subject the provider sends for a user does not match the identifier Synapse holds, that person can end up in a new account or be blocked from signing in. Map the subject claim for each provider in the MAS configuration, then test one account per provider and compare the resulting Matrix IDs. Confirm the claim with your identity provider administrator.

Readiness checks skipped for SAML, LDAP and custom providers

Deployments that use SAML2, LDAP or a custom password provider cannot follow the direct path. MAS does not support SAML and recommends a bridge such as Dex for SAML or LDAP, so the authentication design changes before any data moves. Inventory the SSO and password provider sections of homeserver.yaml, and ask the people who maintain your deployment whether any custom modules exist. Treat every finding from syn2mas check as a blocker for the schedule.

Downtime window sized without a dry run

The real migration requires homeserver downtime and is not easily reversible. Running syn2mas migrate --dry-run performs a full import and then empties the MAS database, which gives a representative timing for your data. Run it against a copy of production data on hardware that matches the target, then set the window from that timing plus margin. Before MAS starts, rollback needs no Synapse restore because the tool never writes to the Synapse database.

Clients and bridges use old endpoints

Clients, bridges and reverse proxy routes that still send authentication requests to Synapse's old endpoints will fail once MAS takes over sign-in. Bridges to platforms such as Slack, IRC, WhatsApp, Telegram, Signal and email each have their own login and registration behavior to review. Inventory every client, bridge, bot and automation account, update the endpoints, and test each bridge login after cutover. Confirm each vendor's support for MAS-based login before you commit to a date.

Questions buyers ask before hiring help to move Synapse logins to MAS

How much does it cost to move Synapse logins to MAS?

The cost follows from the written scope, and DeployOpen does not publish a price list. The priced components usually include readiness analysis (the syn2mas check and a review of your Synapse configuration and identity provider), configuration of MAS and upstream identity provider mapping, the dry run, the production cutover in the agreed downtime window, and post-cutover support. Most of this is one-time work. Support is the part that can recur, and only if you choose it. To compare quotes, ask for each component listed separately, who performs it, the assumptions about your identity provider, and whether a SAML or LDAP bridge is included. Cost rises with the number of identity providers, custom password logic and rehearsal runs.

How long does a Synapse to MAS migration take to schedule?

The schedule is set by two things: the timing of the dry run and the downtime window you agree. The dry run performs a full import into MAS and then empties the MAS database, so it gives a representative timing for the real import. Use that figure to size the downtime window with margin, get the window approved, and then book the cutover. Preparation before the dry run depends on the readiness findings and on how quickly you can provide database access, configuration files and identity provider access. Ask for a written plan with milestones, the dry run date, and the cutover date before work starts.

What does our team need to provide for a MAS migration?

The migration needs the following from your side:

Read access to the Synapse PostgreSQL database, because syn2mas reads only from PostgreSQL.
Synapse and MAS configuration files, including password hash settings and whether Synapse uses a pepper.
Admin access to the upstream identity provider, to create the client and map user claims.
A downtime approval with someone who can authorize stopping Synapse during the window.
Test users covering each login method in use, so logins can be verified after cutover.

Confirm early who holds each item, because access requests are often the longest step before the dry run.

Can our own team migrate Synapse logins to MAS using the documentation?

Yes, a team with PostgreSQL, Synapse and identity provider experience can follow the upstream MAS migration guide. The work covers running the syn2mas check, configuring MAS with a version 1 bcrypt scheme, unicode normalization and the matching pepper, mapping the upstream identity provider, running the dry run, cutover and verification. What a partner adds is an independent readiness review, a rehearsal plan and experience with edge cases. Before deciding, check whether your team can run the dry run at least once and whether someone can own the cutover window. The tool never writes to the Synapse database, so rolling back before MAS starts needs no Synapse restore, but the real migration is not easily reversible.

What happens if we use SAML or LDAP for Synapse logins?

MAS does not support SAML and recommends a bridge, such as Dex, for SAML or LDAP sources. Synapse can use SAML2 directly, so this step is a change in architecture rather than a configuration tweak. The migration then includes choosing and deploying the bridge, connecting it to your identity source, mapping users and testing every login path. The bridge also becomes a service you must operate, patch and monitor. Confirm in the MAS documentation which bridge fits your identity source, and ask for the bridge to appear as a separate line in the readiness findings and the quote. This change can move both the schedule and the cost.

What if the migration fails during the downtime window?

Plan the rollback before the window opens. The syn2mas tool never writes to the Synapse database, so if you stop before MAS is started, you can return to Synapse without restoring its database. After MAS starts and users sign in, reverting is much harder, and the upstream guidance treats the migration as not easily reversible. Agree in advance the criteria for stopping, the point of no return, who makes the call, and how users will be told. Rehearsing the dry run helps show whether the window has enough margin for these decisions.

What does an engineer check before running syn2mas?

Run mas-cli syn2mas check first. It reports configuration problems without stopping Synapse, so it is safe to run on a live homeserver. Confirm there are no SAML, LDAP or custom password providers in use, since these need a different path. Check the MAS password settings: Synapse uses bcrypt while MAS defaults to argon2id, so migrated passwords need a version 1 bcrypt scheme with unicode_normalization set to true, and the same pepper if Synapse uses one. Then run syn2mas migrate with the dry run option against a copy of the environment. A clean check does not guarantee a clean dry run, so record both results.

How DeployOpen scopes, delivers and supports a Synapse to MAS move

DeployOpen plans and runs the move from Synapse's built-in authentication to Matrix Authentication Service as fixed-scope work in infrastructure you control. We start with a readiness review of your Synapse configuration and database, then rehearse the syn2mas import before any production downtime is booked.

How we scope

The written scope lists the Synapse version, database, password providers and upstream identity providers that the migration covers.
Readiness checks confirm that no SAML, LDAP or custom password provider blocks the move, and that the database is PostgreSQL.
Engagements are fixed-scope, so the agreed deliverables, timeline and downtime window are written down before work starts.

How we build

We run syn2mas check against a copy of the configuration first, since the check does not stop Synapse.
We configure MAS with a version 1 bcrypt password scheme, unicode_normalization enabled, and the same pepper if Synapse uses one.
We map upstream OpenID Connect providers to MAS and test sign-in for each user group before the cutover is scheduled.

How we hand over

We run syn2mas migrate with --dry-run to capture a representative import timing and to surface data issues before production.
We document the cutover runbook, the downtime window steps, and the decision point at which rollback is no longer simple.
We deliver configuration files, verification results and operator notes so your team can repeat or audit the change.

How we support

Ongoing support, upgrades and testing for the MAS and Synapse stack are available as a retainer after handover.
Post-cutover checks cover login flows, token issuance and the Synapse configuration changes needed for MAS.
Ask in your quote whether support covers Synapse upgrade notes, MAS releases and incident response for your environment.

Migrate Synapse authentication to Matrix Authentication Service