Synapse + Postgres + Element em um Ravelin a $23,90/mês. Seu homeserver relaya e federa; não consegue ler seu próprio tráfego E2E; jurisdição nórdica significa que ninguém pode educadamente pedir que ele comece a tentar.
Ravelin a $23,90/mês carrega confortavelmente um Synapse bem-federado de ~100 salas — Postgres, Redis, os workers do Synapse, cache de estado de sala, tudo na mesma máquina.
Criptografia de ponta a ponta é estrutural — o homeserver relaya ciphertext que não consegue decifrar. Cadastro de admin KYC-free significa que o operador também não carrega um rastro de papel.
Jurisdição nórdica + no-logs-by-design + uplink ilimitado. Tagarelice de federação para um conjunto de salas ativo é volume real; aqui não cobra extra.
Entrar no matrix.org é a resposta certa para a maioria das pessoas. Rodar seu próprio homeserver é a resposta certa quando seu handle, sua participação em salas e os metadados de suas mensagens não deveriam viver no painel administrativo de outra pessoa. O protocolo é federado, a criptografia é ponta a ponta; a peça faltante é "quem controla a máquina à qual minha conta está ancorada", e a resposta muda o modelo de ameaça materialmente.
O modelo de federação do Matrix é generoso: qualquer homeserver pode conversar com qualquer outro homeserver, salas atravessam servidores, criptografia acompanha o usuário, e não há diretório central exigido para participar. Uma vez que seu homeserver esteja rodando e validado contra o federation tester, sua conta é cidadã de primeira classe da rede — igual a @user:matrix.org ou @user:mozilla.org, só que no seu domínio.
A história operacional do Synapse é bem-trilhada: template Docker Compose upstream, Postgres para estado, Redis para o pool de workers, workers sharded opcionais para federação de alto volume. Nada disso é novo; tudo está documentado; os modos de falha são conhecidos.
A pergunta certa não é "autohospedar ou matrix.org" no abstrato — é "quero minha identidade de federação ancorada a uma máquina que eu administro?". Se a resposta é sim, o resto desta página é a receita.
Para um homeserver comunitário com ~100 salas (mistura de DMs pequenas e um punhado de salas públicas bem-populadas federadas para fora), o tier certo é o Ravelin ($23,90/mês, 8 vCPU, 16 GB, 480 GB NVMe). O data path Python do Synapse é faminto por RAM sob rajadas de federação — uma sala popular entrada por um servidor com 50 mil usuários produz um pico transiente de state-resolution que pede folga. 16 GB absorvem isso confortavelmente.
Acima de ~1000 salas ativas, ou quando o tráfego de federação faz com que o Synapse precise do modo de workers sharded, o tier Bulwark te dá os núcleos para rodar workers federation_sender, synchrotron e event_persister dedicados — a história de escala horizontal do Synapse em uma única máquina. Nesse ponto, você também deve pensar se o Postgres deve ficar em seu próprio VPS; podemos conversar sobre um layout em duas máquinas.
Para um homeserver pessoal — sua conta, algumas DMs, algumas salas privadas pequenas — um Garrison ($11,90/mês, 4 vCPU, 8 GB, 240 GB NVMe) é mais que suficiente. Conduit em um Sentinel é tecnicamente possível para um setup de usuário único, mas Synapse em um Garrison te dá espaço para crescer sem migração.
O que nenhum desses é: uma oferta Matrix gerenciada para mil tenants. A NordBastion é construída para o operador que roda o próprio homeserver para pessoas que ele conhece — não para vender contas Matrix a estranhos.
Um esboço esquelético — a documentação upstream do Synapse pela element-hq continua sendo a referência autoritativa para tuning do homeserver.yaml e modo worker.
O engine oficial do Docker + o plugin Compose v2. A Element-HQ publica uma imagem Synapse mantida que você pode fixar por tag.
curl -fsSL get.docker.com \
| sh
apt install \
docker-compose-pluginO modo "generate" one-shot da imagem Synapse escreve uma config inicial chaveada pelo seu server_name. Desabilite o registro aberto na mesma passada.
docker run --rm \
-v ./data:/data \
-e SYNAPSE_SERVER_NAME=example.org \
matrixdotorg/synapse:latest \
generatePostgres é o store de produção; SQLite é apenas para testes. Redis é exigido para o pool de workers mesmo que você comece single-process.
# adicione ao docker-compose.ymlpostgres: postgres:15
redis: redis:7-alpine
# depois no homeserver.yaml: driver de banco psycopg2Dois pequenos arquivos JSON em /.well-known/matrix/{client,server} no seu domínio apex. Servidos como application/json com CORS Access-Control-Allow-Origin: *.
# /.well-known/matrix/server
{"m.server": "matrix.example.org:443"}
# /.well-known/matrix/client
{"m.homeserver":{"base_url":"https://matrix.example.org"}}federationtester.matrix.org checa well-known, cadeia de certificados, handshake TLS, handshake de versão e troca de chaves. Não convide usuários até estar verde.
# cole o server_name em:# federationtester.matrix.org
# todas as checagens devem estar verdesregistration_shared_secret no homeserver.yaml + CLI register_new_matrix_user = uma conta admin sem nunca abrir cadastro público.
docker compose exec synapse \
register_new_matrix_user \
-a -c /data/homeserver.yaml \
http://localhost:8008Criptografia de ponta a ponta é uma afirmação forte. Ela é minada no momento em que a host do relay sabe, por KYC do lado da cobrança, exatamente qual pessoa legal subiu este homeserver. Cadastro KYC-free com cobrança apenas em cripto mantém os metadados administrativos do relay tão opacos quanto os metadados de payload dele: "o saldo pré-pago por trás deste e-mail", fim de história.
A criptografia de ponta a ponta do Matrix já impede aritmeticamente que o relay leia payloads. A jurisdição nórdica adiciona uma segunda camada: sem mandato de retenção de dados forçando a host a registrar metadados de conexão, sem legislação de client-side scanning em ação, e um warrant canary publicado que descreve o que aconteceria se alguém tentasse mudar a matemática (não podemos). Duas camadas de "não" vencem uma.
Um homeserver federado em algumas salas públicas bem-populadas envia muitos eventos pequenos de federação — cada join, cada mudança de estado, cada recibo de mensagem é um fan-out de entrega-para-N-servidores. O agregado não é enorme, mas é sustentado, e qualquer host que tarifa por GB-out deixa o operador nervoso. Uplink ilimitado remove a sobrecarga cognitiva: federe quanto o protocolo demandar; a fatura é a mesma.
Autohospedar um homeserver Matrix é uma das jogadas mais limpas de soberania que um grupo pequeno pode fazer pelas suas mensagens. Pelo preço de um único assento de ferramenta de chat SaaS você obtém um homeserver federado, criptografado de ponta a ponta cujos handles sobrevivem a qualquer plataforma, cuja moderação é sua, e cuja hospedagem está em uma jurisdição sem mandatos de retenção de dados nem legislação de client-side scanning em ação.
A NordBastion tem opinião nas partes que importam para esse trabalho específico — cadastro de admin KYC-free, jurisdição nórdica, uplink ilimitado — e deliberadamente comum no resto. Docker é Docker. Synapse é Synapse. A Element-HQ entrega a imagem; nós entregamos a máquina.
Reserve uma noite, percorra as seis etapas, valide contra o federation tester, crie o admin. O homeserver sobrevive à noite por anos.
As oito perguntas com que admins Matrix realmente se debatem antes de docker compose up. Delegação well-known é a pergunta dois por uma razão.
Porque o servidor é uma máquina e as mensagens vivem para sempre. Qualquer um com acesso ao disco — um acidente com snapshot, uma imagem forense, um co-admin que vira rebelde, um sucessor quando você eventualmente passa a máquina — vê texto claro se a sala não estiver criptografada. Criptografia de ponta a ponta mantém o homeserver útil (ele relaya, federa, apresenta a UI) ao mesmo tempo que torna o payload da mensagem aritmeticamente ilegível para qualquer coisa que não sejam as chaves de dispositivo do participante. Autohospedagem e E2E são cinto + suspensórios: você controla o relay E o relay não consegue ler seu próprio tráfego.
O Matrix permite que seu domínio voltado ao usuário (example.org) difira do domínio voltado ao servidor (matrix.example.org) servindo dois pequenos arquivos JSON em https://example.org/.well-known/matrix/client e /.well-known/matrix/server. O do client diz ao Element qual URL de homeserver usar; o do server diz aos pares federantes onde alcançar o Synapse para a API s2s. As pessoas tropeçam em três coisas: servir os arquivos com Content-Type errado, CORS não permitindo que outras instâncias os busquem, ou o arquivo do server apontando para uma porta que o firewall não expõe. Valide em federationtester.matrix.org antes de publicar a sala.
Synapse (Python, a implementação de referência) é o que 95% dos homeservers públicos rodam; é o par de federação mais testado e o único que suporta toda funcionalidade que a spec define. Conduit (Rust, binário único, RocksDB) e Dendrite (Go, microsserviços) são mais leves — Conduit é famoso por rodar em um Raspberry Pi. Para um homeserver federado público com usuários, Synapse é a resposta; para um servidor hobbista de usuário único você pode experimentar Conduit em um Sentinel. Este editorial assume Synapse.
Defina enable_registration: false no homeserver.yaml e use o registration_shared_secret para criar contas via API admin para as pessoas que você de fato quer. Alternativamente, enable_registration_without_verification: false combinado com um fluxo de convite por shared-secret hard-coded. A federação Matrix é grande o suficiente para que qualquer homeserver de registro aberto vire fazenda de contas de spambot em dias; a resposta canônica é "registro é curado pelo admin, federação é aberta".
Não — a API C-S do Matrix é o contrato do protocolo, e todo cliente conforme conversa com todo servidor conforme. Element é o padrão e o mais testado; Cinny é um cliente web mais leve que alguns self-hosters preferem empacotar; SchildiChat é um fork do Element com UI ao estilo Telegram; FluffyChat é mobile-first. O homeserver não vê nem se importa com o cliente em que o usuário está. Escolha o que sua comunidade prefere, mude depois, sem migração envolvida.
Cada usuário Matrix tem um conjunto de device keys (por dispositivo, efêmeras) e uma cross-signing key (por conta, de longa duração). A cross-signing master key é o que permite ao usuário adicionar um novo dispositivo sem reverificar tudo; perca-a e o usuário fica trancado de fora das mensagens E2E históricas até refazer as chaves. O recurso "Secure Backup" do Element cifra a cross-signing key com uma passphrase ou chave de recuperação e a guarda server-side como ciphertext opaco — o homeserver guarda o blob, mas não consegue ler. Documente o passo de chave de recuperação para seus usuários no cadastro; é o único pedaço de UX que previne lock-outs evitáveis.
Não diretamente — salas são objetos federados, não registros por servidor, então "mover" uma sala significa fazer upgrade (uma primitiva nativa do Matrix que cria uma sala sucessora e deixa a antiga como stub com redirecionamento) e convidar o mesmo conjunto de participantes. O ID da sala muda, o alias pode acompanhar. Migração direta de conta de usuário entre homeservers é um item de wishlist antigo do Matrix (portabilidade de conta está no roadmap da spec); hoje você cria uma nova conta no seu servidor e pede que as pessoas te readicionem.
O Matrix tem primitivas de moderação por sala (kick, ban, redact, admins de sala) e primitivas por servidor (denylist via Synapse module API, bot MJOLNIR para denylists gerenciadas, modo allowlist a nível de servidor para federação apenas por convite). Para um homeserver comunitário, a inscrição em denylist estilo MJOLNIR é a resposta padrão — você delega identificação de spam/abuso a comunidades mantenedoras de denylist e aplica a política localmente. Sua soberania: você escolhe quais denylists seguir.
Microblogging federado — o protocolo de federação irmão; mesmo padrão de operador, superfície diferente.
Saída VPN com velocidade de kernel em um Sentinel — para o admin de homeserver que quer fazer ssh pelo seu próprio túnel.
Doe banda nórdica para a rede Tor — o vizinho natural de um homeserver criptografado de ponta a ponta no rack do mesmo operador.