Cómo alojar Matrix Synapse en un VPS

Lo que se necesita para mantener activo un homeserver de Matrix Synapse

Matrix Synapse es fácil de instalar y fácil de descuidar. La instalación requiere un repositorio apt, un archivo de configuración, un bloque de reverse proxy y un registro DNS. Mantener el homeserver en buen estado durante un año requiere un trabajo diferente: una base de datos real, un almacén de archivos multimedia que se depure, un registro que no puedan utilizar personas ajenas y una copia de seguridad que incluya ambas partes del servidor.

Esta guía está dirigida a Ubuntu 24.04 LTS e instala Synapse desde el repositorio apt de matrix.org, que es la fuente de paquetes que el proyecto Synapse mantiene para Debian y Ubuntu. Las versiones de los paquetes cambian cada pocas semanas, por lo que aquí no se indica ningún número de versión. Todas las rutas y opciones siguientes proceden de la documentación actual de Synapse.

Dimensionamiento: qué permiten realmente 1 vCPU y 2 GB de RAM

Las páginas de dimensionamiento publicadas, a fecha de agosto de 2026, suelen situar un homeserver de Synapse en 1 vCPU y 2 GB de RAM. Esto es válido en un caso: un servidor privado, pocos usuarios, salas pequeñas y ninguna sala pública con mucha actividad. La documentación de Synapse es clara sobre el otro caso. Indica que se necesita «al menos 1 GB de RAM libre si quiere unirse a salas públicas grandes como #matrix:matrix.org». Es RAM libre adicional a la que necesitan Python, Postgres y el kernel.

Una sola sala puede cambiar el dimensionamiento por la forma en que funciona la unión. Cuando un usuario local se une a una sala, su homeserver se convierte en un participante completo de esa sala. Recibe todos los eventos de los demás servidores de la sala, verifica la firma de cada evento y almacena localmente el estado de la sala. Una sala pública grande tiene miles de miembros distribuidos entre cientos de servidores, por lo que su servidor realiza ese trabajo continuamente, aunque el usuario no vuelva a abrir la sala. Salir de la sala más tarde no elimina el historial que ya se ha almacenado.

La mayor parte de la RAM de Synapse se utiliza para cachés. La sección caches contiene un global_factor que ajusta todas las cachés a la vez, y la variable de entorno SYNAPSE_CACHE_FACTOR establece el mismo valor. Aumentarlo consume RAM para evitar consultas a la base de datos. Reducirlo consume más CPU y tiempo de Postgres para ahorrar RAM. Postgres también necesita memoria, por lo que en un servidor con 2 GB ambos compiten por los mismos megabytes.

Dos reglas prácticas para un plan pequeño. Añada swap: la swap no hará que Synapse sea más rápido, pero evita que el kernel mate el proceso durante una unión grande. Después, supervise el disco desde la primera semana, porque los dos elementos que crecen sin límite son el almacén de medios y las tablas de estado de las salas, y ambos residen en el disco.

Por qué Postgres y por qué SQLite deja de ser una opción

El paquete de Debian empieza con SQLite. Esto está bien para el primer arranque, pero no para un servidor que utilizan otras personas. SQLite permite un escritor a la vez. El tráfico de federación y las peticiones de los clientes escriben al mismo tiempo, por lo que una petición sencilla espera detrás de otra lenta. El síntoma que comunican los usuarios es que la aplicación se bloquea durante unos segundos de forma aleatoria.

La segunda razón es estructural. Los procesos worker de Synapse son la forma admitida de usar más de un núcleo de CPU, y los workers requieren Postgres. Mantener SQLite implica renunciar tanto a la ruta de actualización como al rendimiento.

La migración posterior está admitida y requiere una interrupción del servicio, así que hágala antes de tener usuarios. Synapse incluye synapse_port_db, que copia una base de datos SQLite en una base de datos Postgres preparada:

synapse_port_db --sqlite-database homeserver.db --postgres-config homeserver-postgres.yaml

Si prefiere ejecutar la base de datos en un contenedor junto a Synapse, consulte las ventajas y desventajas en ejecutar la base de datos en Docker o en el host.

Instalar Synapse en Ubuntu 24.04

sudo apt install -y lsb-release wget apt-transport-https
sudo wget -O /usr/share/keyrings/matrix-org-archive-keyring.gpg https://packages.matrix.org/debian/matrix-org-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/matrix-org-archive-keyring.gpg] https://packages.matrix.org/debian/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/matrix-org.list
sudo apt update
sudo apt install matrix-synapse-py3

En Ubuntu 24.04, lsb_release -cs muestra noble y el repositorio de matrix.org publica una suite noble. No use el paquete matrix-synapse del archivo propio de Ubuntu. El proyecto Synapse lo desaconseja porque esas compilaciones quedan atrás respecto de sus versiones y contienen vulnerabilidades de seguridad conocidas.

El instalador solicita un nombre de servidor y escribe la respuesta en /etc/matrix-synapse/conf.d/server_name.yaml. Responda con cuidado. server_name es la parte posterior a los dos puntos en cada ID de usuario (@alice:example.com) y se incluye en cada sala que crea el servidor. Cambiarlo después no traslada nada: crea otro homeserver. Use su dominio sin subdominio, example.com, aunque Synapse se ejecute en matrix.example.com. La delegación conecta ambos, y esa es la siguiente sección.

El paquete ejecuta Synapse con el usuario matrix-synapse, mantiene sus datos en /var/lib/matrix-synapse y lee /etc/matrix-synapse/homeserver.yaml, seguido de todos los archivos de /etc/matrix-synapse/conf.d/. Coloque su configuración personalizada en archivos pequeños dentro de conf.d. Las actualizaciones del paquete no los modifican.

sudo systemctl restart matrix-synapse
systemctl status matrix-synapse
sudo journalctl -u matrix-synapse -n 100 --no-pager

Un arranque correcto activa los listeners y después deja de producir mensajes. La unidad de systemd reinicia el servicio unos segundos después de cualquier salida, por lo que una configuración que Synapse rechaza aparece como una unidad que se inicia y termina en un bucle. Las últimas líneas del journal indican la clave que rechazó.

Apunte Synapse a Postgres

sudo apt install -y postgresql
sudo -u postgres createuser --pwprompt synapse_user
sudo -u postgres createdb --encoding=UTF8 --locale=C --template=template0 --owner=synapse_user synapse

La configuración regional no es un detalle cosmético. Synapse no se inicia con una base de datos creada con valores diferentes de COLLATE y CTYPE, a menos que establezca allow_unsafe_locale en la configuración de la base de datos. La reparación documentada posterior consiste en volcar la base de datos y volver a cargarla en una base de datos creada correctamente. Créela bien desde el principio.

database:
  name: psycopg2
  txn_limit: 10000
  args:
    user: synapse_user
    password: secretpassword
    dbname: synapse
    host: localhost
    port: 5432
    cp_min: 5
    cp_max: 10

Mantenga exactamente una clave database: en todos los archivos de configuración. Sustituya el bloque de SQLite dentro de homeserver.yaml en lugar de añadir una segunda copia bajo conf.d. Así no habrá dudas sobre cuál está activa. Reinicie y compruebe que Synapse usa realmente Postgres:

sudo -u postgres psql synapse -c "SELECT count(*) FROM users;"

Un número indica que Synapse creó su esquema en esta base de datos. Un error sobre una relación inexistente indica que todavía está escribiendo en el archivo de SQLite. Por tanto, el archivo de configuración que editó no es el que se está leyendo.

Proxy inverso, TLS y los archivos .well-known que necesita la federación

Synapse escucha en HTTP sin cifrar en el puerto 8008 y está asociado a localhost. TLS y el puerto público corresponden al proxy inverso situado delante.

listeners:
- port: 8008
  tls: false
  type: http
  x_forwarded: true
  bind_addresses:
  - '::1'
  - '127.0.0.1'
  resources:
  - names:
    - client
    - federation
    compress: false

x_forwarded: true indica a Synapse que confíe en la cabecera X-Forwarded-For que establece el proxy. Sin esta configuración, todos los clientes parecen proceder de 127.0.0.1. Por tanto, el control de tasa detecta un único usuario local extremadamente activo y limita a todos los clientes juntos.

location ~ ^(/_matrix|/_synapse/client) {
    proxy_pass http://localhost:8008;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Host $host:$server_port;
    client_max_body_size 50M;
    proxy_http_version 1.1;
}

La documentación de Synapse incluye una advertencia sobre este bloque que ha hecho perder días a muchos administradores. No añada una ruta después del puerto en proxy_pass, ni siquiera un único /. nginx normaliza entonces el URI. Esto cambia los bytes que firmó el servidor emisor y las solicitudes de federación no superan la verificación de firma, mientras que las solicitudes normales de los clientes siguen funcionando.

client_max_body_size debe ser como mínimo tan grande como max_upload_size de Synapse. Si nginx establece un valor menor, rechaza las cargas superiores a ese límite con 413 Request Entity Too Large antes de que Synapse pueda recibirlas. Por tanto, no habrá ninguna línea en el registro de Synapse que explique el fallo.

Para obtener el certificado, siga Certbot y Let's Encrypt en Ubuntu 24.04. Si todavía no ha elegido el proxy, la comparativa de proxies inversos explica cuál se encarga de TLS.

La delegación permite que server_name conserve el valor example.com mientras Synapse se ejecuta en matrix.example.com. Sirva dos archivos desde el dominio raíz:

location /.well-known/matrix/server {
    default_type application/json;
    return 200 '{"m.server": "matrix.example.com:443"}';
}

location /.well-known/matrix/client {
    default_type application/json;
    add_header Access-Control-Allow-Origin '*';
    return 200 '{"m.homeserver": {"base_url": "https://matrix.example.com"}}';
}

El archivo del servidor indica a los demás homeservers dónde enviar el tráfico de federación. Así, la federación utiliza 443 en lugar del puerto predeterminado 8448. El archivo del cliente indica a los clientes Matrix qué URL proporciona @alice:example.com. La cabecera Access-Control-Allow-Origin es importante en el archivo del cliente porque los clientes basados en navegador lo solicitan desde otro origen. Sin esta cabecera, el navegador bloquea la respuesta y el cliente informa de que no encuentra el homeserver.

Ambos archivos deben servirse mediante TLS válido desde example.com. Compruébelos y, después, compruebe qué respuesta recibe el exterior:

curl -s https://example.com/.well-known/matrix/server
curl -s https://matrix.example.com/_matrix/federation/v1/version

El primero devuelve el JSON que ha escrito. El segundo devuelve un objeto JSON con el nombre de la implementación del servidor y su versión. Esto demuestra que el proxy llega a Synapse mediante la ruta de federación. Después, pruebe el dominio con el comprobador de federación de Matrix en https://federationtester.matrix.org, que sigue la misma ruta que utilizaría un servidor remoto real.

Federar o no federar: decídalo de forma intencionada

La federación es el objetivo de Matrix y también su principal coste. Un homeserver federado acepta conexiones de servidores que usted no conoce, recibe sus eventos, almacena en caché sus archivos multimedia y guarda el estado de todas las salas que utilizan sus usuarios. Es una decisión sobre el modelo de amenazas, no un valor predeterminado.

Federar tiene sentido cuando sus usuarios necesitan comunicarse con personas de otros homeservers o cuando una identidad portable es el motivo por el que eligió Matrix. No federar tiene sentido cuando el servidor existe para un solo equipo y todas sus cuentas le pertenecen. Un servidor cerrado almacena menos datos, recibe menos tráfico y resulta mucho menos interesante para usos abusivos.

Para restringir la federación sin desactivarla, Synapse utiliza una lista de permitidos:

federation_domain_whitelist:
- lon.example.com
- nyc.example.com

La documentación también recomienda aplicar reglas de firewall al listener de federación, para que el tráfico no deseado se detenga en la red y no dentro de Python. Para desactivar por completo la federación, elimine federation de la lista de listeners resources, no publique /.well-known/matrix/server y mantenga cerrado el puerto 8448.

Si el motivo para ejecutar Matrix era disponer de un chat privado para un equipo y la federación nunca formó parte del plan, compare el coste operativo con las otras alternativas autoalojadas a Slack antes de comprometerse con Synapse. Rocket.Chat en Docker Compose proporciona chat de equipo en una máquina más pequeña porque nunca necesita almacenar el estado de las salas de otra organización.

El repositorio multimedia es lo que llena el disco silenciosamente

Los archivos que suben tus propios usuarios permanecen en el disco de forma permanente. Los archivos publicados por usuarios de otros homeservers se descargan y almacenan en caché en el disco en cuanto uno de tus clientes los muestra. Synapse también genera miniaturas para las imágenes, por lo que una foto se convierte en varios archivos. De forma predeterminada, nada de esto caduca.

Localiza el almacenamiento y mide su tamaño:

grep media_store_path /etc/matrix-synapse/homeserver.yaml
sudo du -sh /var/lib/matrix-synapse/media_store

Mide la ruta que muestra tu propia configuración. El paquete de Debian mantiene los datos de Synapse en /var/lib/matrix-synapse, por lo que el almacenamiento normalmente se encuentra allí. Después, configura una política de retención en conf.d:

media_retention:
  local_media_lifetime: 90d
  remote_media_lifetime: 14d

Lee esas dos líneas con atención, porque no son el mismo tipo de configuración. remote_media_lifetime hace caducar una caché, y todo lo que elimina se puede volver a descargar desde el servidor propietario del archivo. local_media_lifetime elimina permanentemente las cargas de tus usuarios cuando alcanzan esa antigüedad. Un equipo que comparte documentos en el chat y espera encontrarlos el año siguiente los perderá. Muchos servidores configuran sólo el valor remoto.

Para una limpieza puntual, la API de administración acepta una marca de tiempo Unix en milisegundos:

BEFORE_TS=$(date -d '30 days ago' +%s%3N)
curl -X POST -H "Authorization: Bearer $ADMIN_TOKEN" \
  "https://matrix.example.com/_synapse/admin/v1/purge_media_cache?before_ts=$BEFORE_TS"

POST /_synapse/admin/v1/purge_media_cache elimina los archivos multimedia remotos almacenados en caché cuyo último acceso sea anterior a esa marca de tiempo. POST /_synapse/admin/v1/media/delete?before_ts=<ms> elimina los archivos multimedia locales según la misma regla. Ejecuta primero la purga remota y vuelve a medir, porque en un servidor que participa en la federación la caché remota suele ocupar la mitad más grande.

Dos configuraciones consumen espacio del mismo disco. max_upload_size limita una sola carga y debe mantenerse sincronizada con client_max_body_size en nginx. url_preview_enabled: true hace que tu servidor descargue páginas remotas para que los clientes puedan mostrar vistas previas de enlaces. Esto consume ancho de banda y almacena miniaturas de contenido que nadie ha subido a tu servidor.

Cierre el registro antes de que alguien encuentre su homeserver

Los escáneres encuentran un homeserver abierto en cuestión de días. Cuando cualquiera puede crear cuentas, su servidor se convierte en una fuente de spam en todas las salas con las que federa, y los administradores del otro lado bloquean todo su dominio. Ese daño a la reputación persiste después de la limpieza, porque las listas de bloqueo se mantienen manualmente.

Synapse se distribuye con el registro cerrado. enable_registration tiene el valor predeterminado false y registration_requires_token tiene el valor predeterminado false. Synapse tampoco se inicia con el registro habilitado y sin un paso de verificación, a menos que establezca además enable_registration_without_verification: true. Este rechazo es deliberado. No lo habilite sólo para eliminar un error de inicio.

Cree manualmente las cuentas que necesite:

sudo register_new_matrix_user -c /etc/matrix-synapse/homeserver.yaml http://localhost:8008

La herramienta solicita el nombre de usuario, la contraseña y si la cuenta es administradora del servidor. Lee registration_shared_secret desde la configuración que indique con -c. Si informa de que no encuentra un secreto compartido, indique -c al archivo que lo contiene.

Cuando la creación manual de cuentas deja de ser escalable, los tokens de registro son una opción intermedia. Un token es una cadena que un usuario nuevo debe presentar durante el registro. Cada token puede incluir un límite sobre el número de veces que puede utilizarse:

enable_registration: true
registration_requires_token: true

curl -X POST -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"uses_allowed": 1}' \
  https://matrix.example.com/_synapse/admin/v1/registration_tokens/new

Omita token del cuerpo y Synapse generará un token y lo devolverá. GET /_synapse/admin/v1/registration_tokens muestra los tokens activos. Ambas llamadas necesitan el token de acceso de una cuenta administradora del servidor. Puede obtenerlo iniciando sesión con el usuario administrador que creó antes.

Una organización que ya administra las cuentas en otro sistema puede omitir por completo las contraseñas locales, porque Synapse puede delegar el inicio de sesión en un proveedor OIDC (OpenID Connect), por ejemplo Authentik como proveedor SSO autohospedado. Así, las altas y bajas se gestionan en un único lugar.

Una copia de seguridad que realmente puede reconstruir el servidor

Una copia de seguridad de Synapse tiene tres partes. Si falta cualquiera de ellas, se restaura un servidor que nadie puede utilizar.

• La base de datos de Postgres, que contiene todos los eventos, las cuentas y las salas.
• El directorio de almacenamiento multimedia, que contiene todos los archivos cargados.
• /etc/matrix-synapse, que contiene la configuración y la clave de firma del servidor.

La clave de firma es la parte que más se olvida. Es la clave privada con la que el homeserver firma los eventos, y los servidores remotos verifican los eventos con la clave pública correspondiente. Ejecute grep signing_key_path /etc/matrix-synapse/homeserver.yaml para ver dónde está la suya. Si la pierde, restaurará un servidor que no puede demostrar que es el mismo servidor que sus salas ya conocen.

sudo -u postgres pg_dump --format=custom --file=/var/backups/synapse-$(date +%F).dump synapse
sudo tar czf /var/backups/synapse-etc-$(date +%F).tgz -C /etc matrix-synapse

Vuelque primero la base de datos y después copie el almacenamiento multimedia. Los archivos multimedia se escriben una vez y se referencian mediante un ID, por lo que una copia del contenido multimedia realizada después del volcado sólo puede contener archivos adicionales, nunca archivos ausentes. Si invierte el orden, la base de datos restaurada puede apuntar a un archivo que la copia de seguridad nunca capturó.

Envíe las tres partes fuera del VPS. restic con instantáneas externas encaja bien con este esquema, porque el almacenamiento multimedia es la mitad más grande y apenas cambia entre ejecuciones, de modo que la deduplicación mantiene pequeño cada snapshot.

Después, ensaye la restauración, porque una copia de seguridad que nunca ha restaurado sólo es una hipótesis. Prepare un segundo VPS, instale el mismo paquete, restaure la configuración, cree la base de datos con la misma codificación y configuración regional, pg_restore el volcado en ella, vuelva a copiar el almacenamiento multimedia y acceda al sistema. Anote cuánto tardó. Ese número es su tiempo real de recuperación.

Cuando crecen las tablas de estado: compactación

Synapse almacena el estado de las salas como grupos de estado y, en un servidor federado, state_groups_state suele convertirse en el objeto más grande de la base de datos. Mida antes de cambiar nada:

sudo -u postgres psql synapse -c "SELECT pg_size_pretty(pg_database_size('synapse'));"
sudo -u postgres psql synapse -c "SELECT pg_size_pretty(pg_total_relation_size('state_groups_state'));"

Si esa tabla representa la mayor parte de la base de datos, el proyecto publica un compresor para ella, rust-synapse-compress-state, que reescribe la jerarquía de grupos de estado en menos filas sin cambiar el significado del estado de ninguna sala. Está compilado con Rust:

sudo apt install -y build-essential libssl-dev pkg-config git
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
git clone https://github.com/matrix-org/rust-synapse-compress-state.git
cd rust-synapse-compress-state/synapse_auto_compressor
cargo build --release

./target/release/synapse_auto_compressor -p postgresql://synapse_user:secretpassword@localhost/synapse -c 500 -n 100

-c indica cuántos grupos de estado procesa a la vez y -n indica cuántos de esos bloques procesa esta ejecución. El compresor automático registra hasta dónde llegó, por lo que la siguiente ejecución continúa desde ese punto. Esto permite programarlo de forma segura. Su documentación indica que los cambios se aplican en transacciones sobre tablas de sólo adición, por lo que puede ejecutarse mientras Synapse está activo. Aun así, haga una copia de seguridad de la base de datos antes de la primera ejecución.

Hay un detalle de Postgres que suele sorprender. Al eliminar filas, el espacio queda disponible para que Postgres lo reutilice, pero no se devuelve al sistema de archivos. Por eso, df puede no cambiar en absoluto después de una compactación grande. VACUUM FULL devuelve ese espacio y necesita un bloqueo exclusivo sobre la tabla, además de espacio libre en disco aproximadamente igual al tamaño de la tabla. Prográmelo como una tarea de mantenimiento. No lo ejecute sin planificación.

Comprobaciones que indican que el servidor funciona correctamente

systemctl status matrix-synapse
curl -s https://example.com/.well-known/matrix/server
curl -s https://matrix.example.com/_matrix/federation/v1/version
sudo -u postgres psql synapse -c "SELECT pg_size_pretty(pg_database_size('synapse'));"
sudo du -sh /var/lib/matrix-synapse/media_store

Un estado correcto significa que la unidad está activa y no se reinicia, que el archivo de delegación devuelve el valor m.server, que el endpoint de versión de la federación devuelve JSON y que los dos valores de tamaño se pueden comparar con los del mes pasado. La comprobación de los tamaños es la que se suele omitir. El disco es la causa de fallo que puede dejar un servidor Synapse fuera de servicio sin aviso: cuando un volumen se llena, PostgreSQL deja de escribir y Synapse falla en todas las peticiones que acceden a la base de datos.

FAQ

¿Cuánta RAM necesita un servidor de Matrix Synapse?

Para un homeserver privado con pocos usuarios, salas pequeñas y sin salas públicas grandes, 2 GB son suficientes. Esta es la recomendación de la mayoría de las páginas de dimensionamiento publicadas en agosto de 2026. La documentación de Synapse pide al menos 1 GB de RAM libre adicional si los usuarios van a unirse a salas públicas grandes como #matrix:matrix.org, porque el servidor almacena el estado de esa sala y procesa su tráfico de forma continua. Añada swap en un plan de 2 GB para evitar que una incorporación grande haga que el kernel termine el proceso.

¿Tengo que usar PostgreSQL en lugar de SQLite?

Cuando se supera un número reducido de usuarios, sí. SQLite permite un solo escritor a la vez, por lo que el tráfico de federación y las peticiones de los clientes se bloquean entre sí bajo carga, y las peticiones pueden quedar bloqueadas durante varios segundos. Los procesos worker de Synapse, que son la forma admitida de usar más de un núcleo de CPU, requieren Postgres. La migración posterior funciona con synapse_port_db y causa una interrupción del servicio, por lo que debe crear la base de datos con --encoding=UTF8 --locale=C --template=template0 antes de tener usuarios.

¿Por qué sigue creciendo el uso de disco de Synapse?

Hay que revisar un directorio y una tabla. El almacén de medios conserva todos los archivos subidos a las salas en las que participa el servidor, incluidas las copias en caché de los medios de usuarios remotos y las miniaturas generadas. Nada caduca hasta que configure media_retention. La tabla state_groups_state crece con el estado de las salas en un servidor federado, y rust-synapse-compress-state reduce ese crecimiento. Mida ambos elementos, con du -sh en su media_store_path y con SELECT pg_size_pretty(pg_total_relation_size('state_groups_state'));, antes de decidir cuál debe revisar.

¿Cómo impido que personas desconocidas se registren en mi homeserver?

Deje enable_registration con su valor predeterminado de false y cree las cuentas con register_new_matrix_user. Cuando este método deje de ser suficiente, configure enable_registration: true junto con registration_requires_token: true y distribuya tokens creados mediante POST /_synapse/admin/v1/registration_tokens/new. No configure enable_registration_without_verification: true sólo para evitar que Synapse rechace el arranque, porque un homeserver abierto se convierte en una fuente de spam y otros administradores pueden responder bloqueando todo su dominio.

¿Debe federarse mi homeserver?

La federación es una decisión sobre la exposición, no una configuración predeterminada. Habilítela si sus usuarios necesitan comunicarse con personas de otros homeservers. Manténgala deshabilitada si el servidor presta servicio a un solo equipo, porque un servidor que no se federa almacena menos datos, recibe menos tráfico y atrae mucho menos abuso. Como opción intermedia, federation_domain_whitelist limita la federación a dominios de socios especificados. La documentación de Synapse también recomienda filtrar el listener de federación con el firewall, en lugar de depender únicamente de esa comprobación en la capa de aplicación.