provide readme for mas setup and migration

README.md

@@ -45,6 +45,50 @@ See [`#27`](https://git.coopcloud.tech/coop-cloud/matrix-synapse/pulls/27) for m
 
 You'll need to deploy something like [this](https://git.autonomic.zone/ruangrupa/well-known-uris). This could be implemented in this recipe but we haven't merged it in yet. Change sets are welcome.
 
+### Matrix Authentication Service (MAS)
+
+[MAS](https://element-hq.github.io/matrix-authentication-service/) is Element’s OAuth/OIDC-native auth service for Matrix: it handles login, tokens, and upstream IdPs while Synapse delegates authentication via `matrix_authentication_service`.
+
+**Enable the stack:**
+
+- In `.env`, uncomment `compose.mas.yml` (and `compose.mas-upstream.yml` plus upstream envs if you use an external IdP), and uncomment the `SECRET_MAS_*` version lines.
+- `abra app secret generate YOURAPPDOMAIN`
+- **Manually insert** the PEM RSA key for `SECRET_MAS_SIGNING_RSA_VERSION` (`generate=false` in `.env.sample`) — abra cannot generate that format; see the comment there (e.g. `openssl genrsa 2048` piped to `abra app secret insert`).
+- `abra app cmd YOURAPPDOMAIN db ensure_mas_database` (once, creates the `mas` database in Postgres)
+- `abra app deploy YOURAPPDOMAIN`
+
+**If you plan to migrate an existing homeserver with `syn2mas`:** deploy and configure MAS as above, but **leave `MAS_ENABLED=1` commented** until migration and cutover are done, so Synapse keeps using your current login path until you intentionally switch. You cannot use Synapse legacy OIDC/Keycloak SSO alongside MAS; plan IdP apps and envs accordingly.
+
+<details>
+<summary><strong>Migrating an existing server (<code>syn2mas</code>)</strong></summary>
+
+Requires PostgreSQL on Synapse and a dedicated MAS database. Backup Postgres (and configs) before you start. Official background: [MAS migration guide](https://element-hq.github.io/matrix-authentication-service/setup/migration.html).
+
+1. **Prepare (Synapse still running):** With MAS in `COMPOSE_FILE` but **`MAS_ENABLED` still off**, deploy, then run checks from your machine:
+   ```bash
+   abra app cmd YOURAPPDOMAIN prepare_mas_migration
+   ```
+   This fetches rendered `homeserver.yaml` into the MAS container, runs `syn2mas check`, then `migrate --dry-run` (the dry run rolls back MAS data at the end). The file stays in the MAS container until next restart, so you can repeat this step to provide the file for the actual migration.
+
+2. **Optional snapshot:** save a copy of the rendered config while `app` is up, e.g. `abra app run -t YOURAPPDOMAIN app cat /data/homeserver.yaml > homeserver.snapshot.yaml`.
+
+3. **Downtime — stop Synapse:** run on the **host** with Docker/Swarm access (not inside a container), e.g.:
+   ```bash
+   docker service scale <STACK_NAME>_app=0
+   ```
+   Use the real service name from `docker service ls` (suffix `_app`).
+
+4. **Migration:** with MAS still running and Synapse at zero replicas,
+   ```bash
+   abra app run YOURAPPDOMAIN mas -- mas-cli syn2mas migrate \
+     --config /etc/mas/config.yaml \
+     --synapse-config /tmp/homeserver.yaml
+   ```
+
+5. **Cutover:** in `.env`, set `MAS_ENABLED=1`, `PASSWORD_LOGIN_ENABLED=false`, remove legacy Keycloak/SSO envs, then `abra app deploy YOURAPPDOMAIN` (Synapse comes back with MAS delegation). `syn2mas` does not write to the Synapse database; if you abort before serving traffic through MAS, you can often drop and recreate the MAS DB and revert env.
+
+</details>
+
 ## Bridges
 For all Bridges:
 - Setting it up is a bit of a chicken/egg & chasing cats moment.