O mascote urso polar da NordBastion conduzindo um grafo de federação de globos-nó ciano conectados por linhas brilhantes com ícones de balões de fala flutuantes representando mensagens criptografadas de ponta a ponta, aurora boreal pelas janelas de um observatório Nordic
Tutorial · 2h prático·Atualizado em 2026

Auto-hospede o Matrix em um VPS.
Synapse + Element. Federado. Criptografado de ponta a ponta.

Matrix é como o e-mail seria se tivesse sido projetado para chat na era dos protocolos abertos. Synapse como homeserver, Element como cliente, PostgreSQL como armazenamento, Caddy como porta de entrada — e um grafo de salas federadas que ninguém em particular possui.

Resumo
  • 01

    O Synapse é o homeserver padrão certo em 2026 — a implementação de referência comprovada em produção e com recursos completos. Conduit e Dendrite são válidos para casos de uso mais restritos.

  • 02

    Mude para PostgreSQL no primeiro dia; o SQLite padrão é apenas para testes e cai acima de um punhado de usuários. Planeje disco para uploads de mídia — salas federadas os acumulam rapidamente.

  • 03

    O registro fechado é o padrão seguro. O registro público é trabalho real de moderação; ative-o apenas se estiver disposto a assumi-lo.

Capítulo 1

Matrix em cinco frases. O que você está realmente implantando.

Matrix é um protocolo aberto de comunicação em tempo real. Um homeserver é um servidor que executa o protocolo; os usuários pertencem a um homeserver cada, identificados como @alice:example.com — o mesmo padrão do e-mail. As salas são as unidades de conversa; uma única sala pode ter membros de muitos homeservers diferentes, e o estado da sala é replicado em todos os homeservers participantes. Salas privadas criptografam cada mensagem com chaves por dispositivo (Olm/Megolm) para que o servidor veja apenas texto cifrado. Toda a rede é um grafo de homeservers federando o estado das salas entre si.

As propriedades interessantes: nenhuma autoridade central pode desligar o Matrix (o protocolo é aberto e roda em todo lugar), usuários em servidores diferentes se comunicam de forma transparente (federação), salas privadas têm criptografia de ponta a ponta adequada (não a criptografia em trânsito de estilo publicitário), e um usuário pode trocar de homeservers e manter sua identidade ao executar o próprio. A troca é a complexidade operacional — executar um homeserver dá mais trabalho do que fazer login no Discord — e um ecossistema de clientes polidos menor do que as plataformas proprietárias.

O que você implanta neste guia: Synapse (o homeserver), PostgreSQL (seu banco de dados), Element Web (o cliente de navegador, hospedado no seu próprio domínio), e Caddy (o reverse proxy + TLS automático). Opcionalmente um backend de armazenamento de mídia e os endpoints well-known para descoberta de federação. O stack inteiro são dois arquivos Docker Compose e uma configuração Caddy.

Capítulo 2

Dimensionamento. O Synapse tem perfil de memória.

O Synapse mantém o estado por sala em memória, e entrar em uma sala federada grande (digamos #matrix:matrix.org com 60.000 membros) puxa muito desse estado para o seu homeserver. O resultado é que mesmo um Synapse de usuário único pode usar 2–3 GB de RAM continuamente se o usuário estiver em salas federadas movimentadas. Planeje de acordo.

Usuário único, federação modesta. 2 vCPU, 4 GB RAM, 40 GB SSD. O <a href="/pt/vps/" class="text-nord-cyan border-b border-nord-cyan/40 hover:border-nord-cyan transition">plano Ravelin ($5.90/mês)</a> da NordBastion está dimensionado corretamente. O disco cresce cerca de 10 GB/ano para um único utilizador ativo; preveja espaço para isso.

Equipe pequena, 5–20 usuários. 4 vCPU, 8 GB RAM, 100 GB SSD. O plano Iron ($24,90/mês) suporta isso confortavelmente. Execute o PostgreSQL no mesmo VPS; o banco de dados cabe na RAM e no disco disponíveis.

Homeserver público, 100+ usuários. Além de 100 usuários ativos, o Synapse se beneficia de processos worker (federation sender, federation reader e client reader separados) e de um PostgreSQL otimizado. Os planos Iron ou Granite lidam com isso, mas a complexidade operacional cresce de forma não linear — nessa escala você é um administrador Matrix além de usuário de software.

Realidade do disco. Uploads de mídia (imagens, vídeos, arquivos) de salas federadas se acumulam no seu homeserver porque a federação Matrix puxa mídia para local para servir. Um homeserver público movimentado pode adicionar 1 GB de mídia por semana. A configuração media_retention do Synapse permite podar conteúdo mais antigo; revise-a uma vez por trimestre.

Capítulo 3

A instalação Docker Compose. Synapse, PostgreSQL, Element.

Inicialize um VPS Debian 12 novo, aponte três registros DNS para ele: matrix.example.com (o hostname do homeserver), element.example.com (o cliente web) e o próprio example.com se você quiser a forma abreviada do identificador @alice:example.com. Conecte via SSH como usuário sudo.

1. Instale o Docker e o Compose. curl -fsSL https://get.docker.com | sh — o Docker Engine vem com o Compose v2 no mesmo pacote.

2. Gere a configuração do Synapse. mkdir -p ~/synapse/data && docker run -it --rm -v ~/synapse/data:/data -e SYNAPSE_SERVER_NAME=example.com -e SYNAPSE_REPORT_STATS=no matrixdotorg/synapse:latest generate — isso escreve o homeserver.yaml. Edite-o: mude o banco de dados de SQLite para PostgreSQL, defina a URL de mídia, defina enable_registration: false para começar (você cria usuários via CLI de admin por enquanto).

3. Escreva o docker-compose.yml. Três serviços: postgres (postgres:16, volume persistente, locale C), synapse (matrixdotorg/synapse:latest, monta ~/synapse/data, depende do postgres), element (vectorim/element-web:latest, monta um config.json pequeno apontando para https://matrix.example.com). Mapeie apenas synapse:8008 e element:80 para localhost; não vincule 0.0.0.0.

4. Coloque o Caddy na frente. Dois sites Caddyfile: matrix.example.com faz proxy para 127.0.0.1:8008 (Synapse) nas portas 443 e 8448 (a porta de federação); element.example.com faz proxy para 127.0.0.1:8001 (Element Web). O Caddy busca certificados Let's Encrypt automaticamente.

5. Descoberta de federação (.well-known). Adicione dois arquivos JSON estáticos no próprio example.com: /.well-known/matrix/server retornando {\"m.server\": \"matrix.example.com:443\"} e /.well-known/matrix/client retornando {\"m.homeserver\": {\"base_url\": \"https://matrix.example.com\"}}. Isso permite que identificadores no formato curto @alice:example.com sejam resolvidos corretamente. Verifique com o Federation Tester em federationtester.matrix.org.

6. Crie seu primeiro usuário. docker exec -it synapse register_new_matrix_user -u alice -p <password> -a -c /data/homeserver.yaml http://localhost:8008 — isso cria uma conta de administrador. Faça login via https://element.example.com.

Capítulo 4

Element, identidade visual, política de registro. As decisões que ficam.

Configuração do Element. Element Web lê um config.json que aponta para o seu homeserver, define o tema padrão, a identidade visual e a lista de «salas sugeridas» para novas contas. Defina default_server_config.m.homeserver.base_url para https://matrix.example.com, brand para o nome do seu projeto, e desabilite o campo brand_url que sugere matrix.org. Novos usuários chegam ao Element Web apontado para o seu servidor, não para o de outra pessoa.

Política de registro. Três modos: fechado (apenas o admin pode registrar usuários via CLI; a postura de moderação mais limpa), baseado em token (você gera tokens de registro via API de admin e os compartilha; melhor para um grupo pequeno), aberto (qualquer pessoa pode se registrar; ative apenas se pretender operar um homeserver público com ferramentas de moderação). Comece fechado e só relaxe se tiver um motivo.

Lista de bloqueio de federação. O Synapse suporta federation_domain_whitelist (apenas lista de permissão) e bloqueios por servidor via API de administração. Para a maioria dos homeservers públicos, o padrão é "federar com tudo", com bloqueios reativos de servidores abusivos conforme necessário. O bot Mjolnir automatiza isso se você se tornar um alvo.

Cópias de segurança. Dump noturno do PostgreSQL + tarball de ~/synapse/data, enviado fora do servidor via rclone para um segundo VPS ou bucket B2. Ambos são necessários; o banco de dados é o estado das salas e das contas, o diretório de dados guarda as chaves de assinatura e a mídia. Testes de restauração a cada trimestre, como para qualquer backup.

Capítulo 5

A realidade da moderação. O que a auto-hospedagem realmente significa.

Executar um homeserver Matrix significa aceitar que o operador é responsável pelo que o servidor faz. Em um homeserver privado de convite, essa responsabilidade é pequena — você conhece cada usuário. Em um homeserver público, a responsabilidade escala com a base de usuários.

Abuso de entrada. Uma sala pública federada pode ser envolvida em coordenação de abusos, despejos de imagens ou assédio. O Synapse expõe endpoints de API de administração para banir um usuário (em todas as salas), bloquear um homeserver (sem mais federação) e forçar um servidor a sair de uma sala. O bot Mjolnir encapsula tudo isso em um fluxo de moderação por sala; o fork Draupnir é sua continuação ativamente mantida.

Abuso de saída. Uma conta de usuário comprometida pode publicar conteúdo abusivo em salas federadas, prejudicando a reputação do seu servidor junto ao restante da rede. Duas mitigações: limite de taxa por usuário (os limites padrão do Synapse são razoáveis) e exigência de verificação de e-mail para novas contas (eleva a barreira contra registros automatizados).

Postura jurídica. Na UE, o papel de provedor de infraestrutura oferece fortes proteções de responsabilidade intermediária (Artigo 14 da Diretiva de Comércio Eletrônico, Artigo 6 da DSA) — você não é responsável pelo conteúdo do usuário enquanto responder a notificações e remoções. As jurisdições nórdicas ampliam isso com proteções constitucionais explícitas de liberdade de imprensa. O mesmo homeserver executado em uma jurisdição sem proteções intermediárias tem mais riscos operacionais; escolha a localização do servidor de acordo.

O padrão seguro. Registro somente por convite, federação ativada com bloqueios reativos, Mjolnir / Draupnir instalados mas sem uso até ser necessário, termos de serviço publicados no site do homeserver com uma política de uso aceitável clara. Essa postura atende 95% dos operadores sem esforço adicional.

Capítulo 6

Por que o provedor importa. A criptografia protege o conteúdo, o provedor protege os metadados.

O E2EE do Matrix protege os corpos das mensagens — o servidor guarda apenas texto cifrado para salas privadas. O que ele não protege são os metadados: quais homeservers federaram entre si, quais usuários estão em quais salas, quando estão online, com que frequência enviam mensagens, quais são seus dispositivos. Esse grafo de metadados reside no homeserver e nos homeservers com os quais ele se federa, e está tecnicamente fora do alcance da camada de criptografia.

Um homeserver rodando em um VPS vinculado a KYC conecta o grafo de metadados à identidade legal do operador. Uma intimação ao provedor entrega não apenas o banco de dados criptografado, mas também o vínculo entre o identificador @alice:example.com e um nome real. A criptografia permanece; a camada de metadados está exposta.

A postura da NordBastion é o oposto: <a href="/pt/doctrine/" class="text-nord-cyan border-b border-nord-cyan/40 hover:border-nord-cyan transition">registo sem KYC</a>, pagamento em criptomoeda, jurisdições constitucionais nórdicas. O servidor doméstico é seu; a ligação do servidor doméstico a um nome não existe; o regime jurídico que toca no disco tem proteções explícitas de liberdade de imprensa. A combinação corresponde ao modelo de segurança do próprio Matrix — tanto a camada criptográfica de conteúdo como a camada operacional de metadados estão defendidas.

FAQ · Auto-hospedar Matrix

Perguntas, respondidas.

Oito perguntas que surgem ao executar um homeserver Matrix em 2026.

O que é o Matrix e como é diferente do Discord ou Slack?

Matrix é um protocolo de comunicação em tempo real federado e de padrão aberto — pense no SMTP para chat. Qualquer um executa um homeserver (Synapse, Dendrite, Conduit), usuários em homeservers diferentes se comunicam entre si de forma transparente, cada mensagem em uma sala privada é criptografada de ponta a ponta por padrão, nenhuma empresa central controla a rede. Discord e Slack são centralizados, proprietários e a empresa hospeda cada conversa. A compensação: o Matrix tem complexidade operacional ligeiramente maior e um ecossistema menor de clientes refinados, mas você possui cada byte.

Synapse, Dendrite ou Conduit — qual homeserver?

O Synapse é a referência, escrito em Python, a escolha mais completa em recursos e comprovada em produção. É pesado em memória. O Dendrite é a reescrita mais recente em Go, muito mais leve, com alguns recursos avançados de moderação faltando, mas fechando rapidamente a lacuna. O Conduit é a terceira opção, um homeserver em Rust focado em pegada mínima de recursos, bom para um homeserver de usuário único em um VPS econômico. Opte pelo Synapse a menos que tenha um motivo específico — a documentação, as ferramentas de moderação e as pontes de terceiros assumem o Synapse.

Quanto de VPS preciso para um homeserver Matrix?

Usuário único federando com a rede Matrix mais ampla — 2 vCPU, 4 GB RAM, 40 GB SSD é o mínimo prático. Equipe pequena (5–20 usuários) — 4 vCPU, 8 GB RAM, 100 GB SSD. Os tiers Ravelin ou Iron cobrem ambos os casos. O recurso dominante é RAM (o Synapse mantém muito estado de sala em memória) e disco (uploads de mídia e histórico de salas federadas crescem continuamente).

Devo ativar a federação?

Quase sempre sim — esse é o objetivo central do Matrix. A federação permite que seus usuários se comuniquem com qualquer pessoa em matrix.org, mozilla.org, kde.org e os milhares de outros homeservers. As exceções: um servidor privado de equipe interna onde você não quer que ninguém descubra salas; um modelo de ameaça de alto risco onde padrões de tráfego de federação vazam informações; um servidor hospedando conteúdo sensível onde você quer controle estrito de membros. Desativar a federação depois é possível; reativá-la torna você detectável.

As salas privadas são criptografadas de ponta a ponta por padrão?

Sim — cada cliente Element ativa E2EE por padrão para novas mensagens diretas e salas privadas. A criptografia é Olm/Megolm por sala com verificação de dispositivo com assinatura cruzada. O servidor vê apenas texto cifrado para o corpo da mensagem. Salas públicas são não criptografadas por design (já que qualquer pessoa pode entrar, a criptografia não protegeria nada). Salas públicas federadas são visíveis para qualquer pessoa — que é o objetivo de uma sala pública.

Qual é a realidade da moderação de executar um homeserver público?

É trabalho real. Se você permitir registro público, seu homeserver se federará a salas de spam, será arrastado para salas de coordenação de abuso e ocasionalmente exibirá conteúdo objecível de servidores federados. Executar um homeserver público exige disponibilidade para aplicar banimentos no nível do servidor, bloquear federação de servidores hostis e responder a denúncias de abuso. Para a maioria dos operadores, a postura correta é registro fechado (somente por convite) — cada usuário é alguém que você conhece e a superfície de abuso cai para quase zero.

Posso usar meu homeserver Matrix como substituto do Slack / Discord no trabalho?

Sim — o Element Server Suite e a combinação subjacente Synapse + Element Web cobrem o conjunto de recursos de "chat de equipe com salas persistentes, threads, reações, huddles de voz/vídeo". A principal lacuna em relação ao Slack são as integrações de terceiros (menos aplicativos pré-construídos); a principal lacuna em relação ao Discord são os canais de voz polidos. Ambos são viáveis, mas requerem algum esforço do operador. Para uma equipe pequena que valoriza a soberania dos dados acima do polimento, a troca vale claramente.

Por que o provedor de quem alugo o VPS importa para um servidor Matrix?

Porque o protocolo de chat federado cria metadados persistentes sobre quem fala com quem e quando no homeserver. Esses metadados são ricos (grafo de salas federadas, eventos de federação, uploads de mídia). Colocá-los em um provedor com KYC vincula os metadados à sua identidade; colocá-los em um provedor em uma jurisdição hostil significa que um ator estatal pode exigí-los. Um VPS nórdico sem KYC alinha a postura de metadados do provedor com a postura criptográfica do protocolo — as duas metades da história de privacidade.

Obtenha o hardware

Um VPS nórdico para o seu servidor doméstico. Sem KYC, pago em cripto.

O Ravelin (2 vCPU, 4 GB, $5,90/mês) cobre um Synapse federado de usuário único. O Iron (4 vCPU, 8 GB, $24,90/mês) é a resposta para equipes pequenas.

Última revisão · 2026-05-20 · Fontes · Documentação upstream do Synapse, referência de configuração do Element, especificação Matrix, Artigo 6 da DSA da UE · Cadência · anualmente