Como manter um servidor Matrix Synapse em um VPS

O que é necessário para manter um homeserver Matrix Synapse ativo

O Matrix Synapse é fácil de instalar e fácil de deixar sem manutenção. A instalação exige um repositório apt, um ficheiro de configuração, um bloco de reverse proxy e um registo DNS. Manter o homeserver saudável durante um ano exige outro tipo de trabalho: uma base de dados real, um armazenamento de multimédia que seja limpo periodicamente, um sistema de registo que não possa ser usado por desconhecidos e uma cópia de segurança que inclua ambas as partes do servidor.

Este guia destina-se ao Ubuntu 24.04 LTS e instala o Synapse a partir do repositório apt do matrix.org, que é a fonte de pacotes mantida pelo projeto Synapse para Debian e Ubuntu. As versões dos pacotes mudam a cada poucas semanas, por isso não é indicado nenhum número de versão. Todos os caminhos e opções abaixo vêm da documentação atual do Synapse.

Dimensionamento: o que 1 vCPU e 2 GB de RAM realmente oferecem

As páginas de dimensionamento publicadas, em agosto de 2026, normalmente indicam 1 vCPU e 2 GB de RAM para um homeserver Synapse. Isso é adequado para um caso específico: um servidor privado, alguns utilizadores, salas pequenas e nenhuma sala pública movimentada. A documentação do Synapse é clara sobre o outro caso. Ela exige "At least 1GB of free RAM if you want to join large public rooms like #matrix:matrix.org". Trata-se de RAM livre além da memória usada pelo Python, pelo Postgres e pelo kernel.

Uma sala pode alterar o dimensionamento devido à forma como a entrada funciona. Quando um utilizador local entra numa sala, o seu homeserver torna-se um participante completo dessa sala. Ele recebe todos os eventos da sala provenientes de todos os outros servidores, verifica a assinatura de cada evento e armazena localmente o estado da sala. Uma sala pública grande tem milhares de membros distribuídos por centenas de servidores. Por isso, o seu servidor executa esse trabalho continuamente, mesmo que o utilizador nunca mais abra a sala. Sair da sala posteriormente não elimina o histórico que já foi armazenado.

A maior parte da RAM usada pelo Synapse é destinada às caches. A secção caches contém um global_factor que dimensiona todas as caches ao mesmo tempo, e a variável de ambiente SYNAPSE_CACHE_FACTOR define o mesmo valor. Aumentá-lo usa mais RAM para evitar consultas à base de dados. Reduzi-lo usa mais CPU e tempo do Postgres para poupar RAM. O Postgres também precisa de memória própria. Num servidor com 2 GB, os dois competem pelos mesmos megabytes.

Duas regras práticas para um plano pequeno. Adicione swap: a swap não torna o Synapse rápido, mas impede que o kernel termine o processo durante uma entrada grande numa sala. Depois, monitorize o disco desde a primeira semana, porque os dois elementos que crescem sem limite são o armazenamento de media e as tabelas de estado das salas. Ambos ficam no disco.

Por que Postgres e por que SQLite deixa de ser uma opção

O pacote Debian começa com SQLite. Isso é adequado para o primeiro arranque, mas não para um servidor utilizado por outras pessoas. O SQLite permite apenas uma operação de escrita de cada vez. O tráfego de federação e os pedidos dos clientes escrevem ao mesmo tempo. Por isso, um pedido simples fica à espera de um pedido lento, e o sintoma relatado pelos utilizadores é que a aplicação bloqueia durante alguns segundos, de forma aleatória.

A segunda razão é estrutural. Os processos worker do Synapse são a forma suportada de utilizar mais de um núcleo de CPU, e os workers requerem Postgres. Continuar a utilizar SQLite elimina tanto o caminho de atualização como o desempenho.

A migração posterior é suportada, mas implica indisponibilidade. Faça-a antes de ter utilizadores. O Synapse inclui synapse_port_db, que copia uma base de dados SQLite para uma base de dados Postgres preparada:

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

Se preferir executar a base de dados num contentor junto do Synapse, as diferenças estão descritas em executar a base de dados no Docker ou no host.

Instalar o Synapse no 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

No Ubuntu 24.04, lsb_release -cs apresenta noble, e o repositório matrix.org publica uma suite noble. Não use o pacote matrix-synapse do arquivo próprio do Ubuntu. O projeto Synapse recomenda que não o faça, porque essas compilações ficam atrás das versões publicadas e incluem falhas de segurança conhecidas.

O instalador pede um nome de servidor e grava a resposta em /etc/matrix-synapse/conf.d/server_name.yaml. Responda com atenção. server_name é a parte depois dos dois-pontos em cada ID de utilizador (@alice:example.com) e está incorporado em todas as salas que o seu servidor cria. Alterá-lo mais tarde não move nada: cria um homeserver diferente. Use o seu domínio simples, example.com, mesmo quando o próprio Synapse for executado em matrix.example.com. A delegação liga os dois, e essa é a próxima secção.

O pacote executa o Synapse como o utilizador matrix-synapse, mantém os dados em /var/lib/matrix-synapse e lê /etc/matrix-synapse/homeserver.yaml, seguido de todos os ficheiros em /etc/matrix-synapse/conf.d/. Coloque as suas próprias definições em ficheiros pequenos em conf.d. As atualizações do pacote não os alteram.

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

Um arranque saudável ativa os listeners e depois fica silencioso. A unidade systemd reinicia o serviço alguns segundos depois de qualquer saída, por isso uma configuração rejeitada pelo Synapse aparece como uma unidade que inicia e termina num ciclo. As últimas linhas do journal indicam a chave que foi recusada.

Aponte o Synapse para o 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

A localidade não é apenas estética. O Synapse recusa iniciar com uma base de dados criada com valores diferentes de COLLATE e CTYPE, a menos que defina allow_unsafe_locale na configuração da base de dados. A correção documentada depois disso consiste em fazer um dump e recarregá-lo numa base de dados criada corretamente. Crie-a corretamente desde o início.

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

Mantenha exatamente uma chave database: em todos os ficheiros de configuração. Substitua o bloco SQLite dentro de homeserver.yaml, em vez de adicionar uma segunda cópia sob conf.d. Assim, não haverá dúvidas sobre qual configuração está ativa. Reinicie e confirme que o Synapse está realmente a usar Postgres:

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

Um número significa que o Synapse criou o respetivo esquema nesta base de dados. Um erro sobre uma relação inexistente significa que ainda está a escrever no ficheiro SQLite. Nesse caso, a configuração que editou não é a que está a ser lida.

Proxy reverso, TLS e os ficheiros .well-known necessários para a federação

O Synapse escuta em HTTP simples na porta 8008, associado a localhost. O TLS e a porta pública pertencem a um proxy reverso colocado à frente dele.

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 ao Synapse para confiar no cabeçalho X-Forwarded-For definido pelo proxy. Sem esta configuração, todos os clientes parecem vir de 127.0.0.1. O controlo de limites de pedidos vê um único utilizador local extremamente ocupado e limita todos em conjunto.

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;
}

A documentação do Synapse inclui um aviso sobre este bloco que causa problemas durante dias. Não adicione um caminho depois da porta, nem sequer um único /, em proxy_pass. O nginx canoniza então o URI. Isso altera os bytes assinados pelo servidor emissor, e os pedidos de federação falham na verificação da assinatura, enquanto os pedidos normais dos clientes continuam a funcionar.

client_max_body_size deve ser pelo menos igual a max_upload_size do Synapse. Se o nginx tiver um valor menor, os uploads acima desse limite são rejeitados pelo nginx com 413 Request Entity Too Large antes de o Synapse os receber. Por isso, não existe nenhuma linha no log do Synapse que explique a falha.

Para o certificado, siga Certbot e Let's Encrypt no Ubuntu 24.04. Se ainda não decidiu qual proxy utilizar, a comparação de proxies reversos explica qual deles pode tratar do TLS.

A delegação permite que server_name permaneça em example.com enquanto o Synapse funciona em matrix.example.com. Sirva dois ficheiros a partir do domínio base:

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"}}';
}

O ficheiro do servidor informa os outros homeservers para onde devem enviar o tráfego de federação. É assim que a federação utiliza a porta 443 em vez da porta predefinida 8448. O ficheiro do cliente informa os clientes Matrix sobre o URL associado a @alice:example.com. O cabeçalho Access-Control-Allow-Origin é importante no ficheiro do cliente porque os clientes baseados no navegador o obtêm entre origens. Sem esse cabeçalho, o navegador bloqueia a resposta e o cliente informa que não consegue encontrar o seu homeserver.

Ambos os ficheiros devem ser servidos através de TLS válido a partir do próprio example.com. Verifique-os e depois verifique o que é visível a partir da Internet:

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

O primeiro comando devolve o JSON que escreveu. O segundo devolve um objeto JSON com o nome da implementação do servidor e a respetiva versão. Isso confirma que o proxy alcança o Synapse através do caminho de federação. Depois, teste o domínio no Matrix federation tester em https://federationtester.matrix.org, que segue o mesmo percurso utilizado por um servidor remoto real.

Federar ou não federar: decida de forma consciente

A federação é o objetivo do Matrix e também representa a maior parte do custo. Um homeserver federado aceita ligações de servidores que você nunca ouviu mencionar, recebe os respetivos eventos, armazena em cache os seus ficheiros multimédia e guarda o estado de todas as salas utilizadas pelos seus utilizadores. Isto é uma decisão sobre o modelo de ameaças, não um comportamento predefinido.

Federe quando os seus utilizadores precisam de contactar pessoas noutros homeservers ou quando uma identidade portátil é o motivo pelo qual escolheu o Matrix. Não federe quando o servidor existe para uma única equipa e todas as contas pertencem à sua organização. Um servidor fechado armazena menos dados, recebe menos tráfego e é muito menos interessante para abusos.

Para restringir a federação em vez de a desativar, o Synapse aceita uma lista de permissões:

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

A documentação também recomenda bloquear a porta de escuta da federação na firewall, para que o tráfego indesejado seja interrompido na rede e não dentro do Python. Para desativar completamente a federação, remova federation da lista de resources do listener, não publique /.well-known/matrix/server e mantenha a porta 8448 fechada.

Se o motivo para executar o Matrix era disponibilizar chat privado para uma equipa e a federação nunca fez parte do objetivo, compare o custo operacional com as outras alternativas autoalojadas ao Slack antes de optar pelo Synapse. O Rocket.Chat no Docker Compose fornece chat de equipa numa máquina mais pequena, porque nunca precisa de armazenar o estado das salas de outra organização.

O repositório de media é o que enche o disco silenciosamente

Os ficheiros carregados pelos seus próprios utilizadores permanecem permanentemente no disco. Os ficheiros publicados por utilizadores noutros homeservers são obtidos e colocados em cache no disco assim que um dos seus clientes os apresenta. O Synapse também gera miniaturas para imagens, por isso uma fotografia transforma-se em vários ficheiros. Por predefinição, nada disso expira.

Localize o armazenamento e meça-o:

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

Meça o caminho apresentado pela sua própria configuração. O pacote Debian mantém os dados do Synapse em /var/lib/matrix-synapse, por isso o armazenamento normalmente fica aí. Depois, defina uma política de retenção em conf.d:

media_retention:
  local_media_lifetime: 90d
  remote_media_lifetime: 14d

Leia atentamente essas duas linhas, porque não representam o mesmo tipo de configuração. remote_media_lifetime faz expirar uma cache, e tudo o que eliminar pode ser obtido novamente a partir do servidor que possui o ficheiro. local_media_lifetime elimina permanentemente os carregamentos dos seus próprios utilizadores quando atingem essa idade. Uma equipa que partilha documentos no chat e espera encontrá-los no próximo ano irá perdê-los. Muitos servidores definem apenas o valor remoto.

Para uma limpeza pontual, a API de administração aceita um timestamp Unix em milissegundos:

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 os media remotos em cache cujo último acesso ocorreu antes desse timestamp. POST /_synapse/admin/v1/media/delete?before_ts=<ms> elimina os media locais segundo a mesma regra. Execute primeiro a limpeza remota e meça novamente, porque, num servidor federado, a cache remota é normalmente a maior das duas partes.

Duas configurações alimentam o mesmo disco. max_upload_size limita um único carregamento e tem de permanecer alinhado com client_max_body_size no nginx. url_preview_enabled: true faz o seu servidor obter páginas remotas para que os clientes possam apresentar pré-visualizações de ligações. Isso consome largura de banda e armazena miniaturas de conteúdo que ninguém carregou para o seu servidor.

Feche o registo antes que alguém encontre o seu homeserver

Os scanners encontram um homeserver aberto em poucos dias. Assim que for possível criar contas livremente, o seu servidor torna-se uma fonte de spam em todas as salas com as quais federa, e os administradores do outro lado bloqueiam todo o seu domínio. Esse dano à reputação persiste depois da limpeza, porque as listas de bloqueio são mantidas manualmente.

O Synapse é fornecido com o registo fechado. enable_registration tem como predefinição false e registration_requires_token tem como predefinição false. O Synapse também recusa iniciar com o registo ativado e sem uma etapa de verificação, a menos que defina adicionalmente enable_registration_without_verification: true. Essa recusa é intencional. Não o ative apenas para eliminar um erro de arranque.

Crie manualmente as contas pretendidas:

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

O comando pede o nome de utilizador, a palavra-passe e indica se a conta é administradora do servidor. Lê registration_shared_secret a partir da configuração fornecida com -c. Se indicar que não consegue encontrar um segredo partilhado, aponte -c para o ficheiro que o contém.

Quando a criação manual de contas deixar de ser escalável, use tokens de registo. Um token é uma cadeia que um novo utilizador tem de apresentar durante o registo. Cada token pode definir um limite para o número de utilizações:

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 do corpo e o Synapse gera um token e devolve-o. GET /_synapse/admin/v1/registration_tokens apresenta os tokens ativos. Ambas as chamadas precisam do access token de uma conta administradora do servidor. Pode obtê-lo iniciando sessão com o utilizador administrador criado acima.

Uma organização que já faça a gestão das contas noutro local pode eliminar totalmente as palavras-passe locais, porque o Synapse pode delegar o início de sessão num fornecedor OIDC (OpenID Connect), por exemplo Authentik como fornecedor SSO autoalojado. Os processos de entrada e saída de utilizadores passam então a ser geridos num único local.

Um backup que realmente consegue reconstruir o servidor

Um backup do Synapse tem três partes. Se faltar qualquer uma delas, o servidor restaurado não poderá ser utilizado.

• A base de dados PostgreSQL, que contém todos os eventos, contas e salas.
• O diretório do repositório de media, que contém todos os ficheiros carregados.
• /etc/matrix-synapse, que contém a sua configuração e a chave de assinatura do servidor.

A chave de assinatura é a parte que muitas pessoas esquecem. É a chave privada que o seu homeserver usa para assinar eventos. Os servidores remotos validam os eventos com a chave pública correspondente. Execute grep signing_key_path /etc/matrix-synapse/homeserver.yaml para ver onde a sua chave está guardada. Se a perder, restaura um servidor que não consegue provar que é o mesmo servidor que as suas salas já conhecem.

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

Despeje primeiro a base de dados e, em seguida, copie o repositório de media. Os ficheiros de media são escritos uma vez e referenciados por ID. Por isso, uma cópia do media feita depois do dump só pode conter ficheiros adicionais, nunca ficheiros em falta. A ordem inversa pode deixar a base de dados restaurada a apontar para um ficheiro que o backup nunca capturou.

Envie as três partes para fora da VPS. restic com snapshots fora do local adapta-se bem a este cenário, porque o repositório de media é a parte maior e muda muito pouco entre execuções. Assim, a deduplicação mantém cada snapshot pequeno.

Depois, ensaie a restauração, porque um backup que nunca foi restaurado é apenas uma hipótese. Crie uma segunda VPS, instale o mesmo pacote, restaure a configuração, crie a base de dados com a mesma codificação e locale, pg_restore o dump para a base de dados, copie novamente o repositório de media e inicie sessão. Registe quanto tempo demorou. Esse valor é o seu tempo real de recuperação.

Quando as tabelas de estado crescem: compactação

O Synapse armazena o estado das salas como grupos de estado. Num servidor federado, state_groups_state muitas vezes torna-se o maior objeto da base de dados. Meça antes de alterar qualquer coisa:

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'));"

Se essa tabela representar a maior parte da base de dados, o projeto disponibiliza um compressor para ela, rust-synapse-compress-state, que reescreve a hierarquia dos grupos de estado em menos linhas sem alterar o significado do estado de nenhuma sala. É compilado com 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 define quantos grupos de estado são processados de cada vez, e -n define quantos desses blocos esta execução processa. O compressor automático regista até onde chegou, por isso a execução seguinte continua a partir desse ponto. É isso que permite agendar a tarefa com segurança. A documentação indica que as alterações são aplicadas em transações sobre tabelas apenas de acréscimo, pelo que pode ser executado enquanto o Synapse está ativo. Faça uma cópia de segurança da base de dados antes da primeira execução, independentemente disso.

Um detalhe do Postgres surpreende muitas pessoas neste caso. A eliminação de linhas devolve o espaço ao Postgres para reutilização, não ao sistema de ficheiros. Por isso, df pode não diminuir depois de uma compactação grande. VACUUM FULL devolve esse espaço ao sistema de ficheiros e requer um bloqueio exclusivo na tabela, além de espaço livre em disco aproximadamente equivalente ao tamanho da tabela. Agende-o como uma tarefa de manutenção, em vez de o executar sem planeamento.

Verificações que confirmam que o servidor está saudável

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

Saudável significa que a unidade está ativa e não está a reiniciar, que o ficheiro de delegação devolve o seu valor m.server, que o endpoint da versão da federação devolve JSON e que os dois valores de tamanho podem ser comparados com os do mês passado. As verificações de tamanho são as que as pessoas mais ignoram, e o disco é o problema que deixa um servidor Synapse indisponível sem aviso: um volume cheio impede o Postgres de escrever, e o Synapse falha então todos os pedidos que acedem à base de dados.

FAQ

Quanta RAM um servidor Matrix Synapse precisa?

Para um homeserver privado com poucos utilizadores, salas pequenas e sem salas públicas grandes, 2 GB são suficientes. É isso que a maioria das páginas de dimensionamento publicadas recomenda em agosto de 2026. A documentação do Synapse pede pelo menos mais 1 GB de RAM livre se os seus utilizadores entrarem em salas públicas grandes, como #matrix:matrix.org, porque o seu servidor passa a armazenar o estado dessa sala e a processar continuamente o respetivo tráfego. Adicione swap num plano de 2 GB para que uma entrada numa sala grande não faça o kernel terminar o processo.

Tenho de usar PostgreSQL em vez de SQLite?

Acima de um pequeno número de utilizadores, sim. O SQLite permite apenas um escritor de cada vez. Por isso, o tráfego de federação e os pedidos dos clientes bloqueiam-se mutuamente sob carga, e os pedidos ficam pendurados durante vários segundos. Os processos worker do Synapse, que são a forma suportada de usar mais de um núcleo de CPU, requerem Postgres. A migração posterior funciona com synapse_port_db e causa indisponibilidade, por isso crie a base de dados com --encoding=UTF8 --locale=C --template=template0 antes de ter utilizadores.

Por que motivo o uso de disco do meu Synapse continua a aumentar?

Há um diretório e uma tabela envolvidos. O media store mantém todos os ficheiros carregados para salas em que o seu servidor participa, incluindo cópias em cache dos ficheiros multimédia de utilizadores remotos e miniaturas geradas. Nada expira até configurar media_retention. A tabela state_groups_state aumenta com o estado das salas num servidor federado, e rust-synapse-compress-state reduz esse crescimento. Meça ambos com du -sh no seu media_store_path e com SELECT pg_size_pretty(pg_total_relation_size('state_groups_state')); antes de decidir qual deve tratar primeiro.

Como impeço que desconhecidos se registem no meu homeserver?

Mantenha enable_registration com o valor predefinido false e crie contas com register_new_matrix_user. Quando esse método deixar de ser escalável, configure enable_registration: true juntamente com registration_requires_token: true e distribua tokens criados através de POST /_synapse/admin/v1/registration_tokens/new. Não configure enable_registration_without_verification: true apenas para silenciar a recusa de arranque do Synapse, porque um homeserver aberto torna-se uma fonte de spam e os outros administradores respondem bloqueando todo o seu domínio.

O meu homeserver deve participar na federação?

A federação é uma decisão sobre exposição, não um comportamento predefinido. Ative a federação se os seus utilizadores precisarem de contactar pessoas noutros homeservers. Mantenha-a desativada se o servidor servir uma única equipa, porque um servidor sem federação armazena menos dados, recebe menos tráfego e atrai muito menos abuso. Como opção intermédia, federation_domain_whitelist limita a federação a domínios parceiros nomeados. A documentação do Synapse também recomenda filtrar o listener de federação na firewall, em vez de depender apenas dessa verificação na camada da aplicação.