Como hospedar um servidor SimpleX em uma VPS

O que faz um servidor SimpleX de chat autoalojado

Para alojar o seu próprio servidor SimpleX, execute um daemon numa VPS: smp-server, o relay do SMP (simplex messaging protocol). Este mantém as filas de mensagens onde os seus contactos escrevem e a partir das quais leem. Um segundo daemon opcional, chamado xftp-server, retransmite transferências de ficheiros. Ambos fazem parte do mesmo projeto, simplexmq, e cada um consiste num único binário, num ficheiro de configuração e num log apenas de acréscimos.

Este texto destina-se ao operador, não ao utilizador da aplicação. O relay não mantém contas, listas de contactos nem histórico de conversas. Mantém filas, algum texto cifrado não entregue e um certificado que o identifica. O que fica a seu cargo é a disponibilidade, algum espaço em disco e os metadados que passam pelo seu servidor.

Todos os comandos, caminhos, portas e flags abaixo vêm da documentação do próprio projeto: a página de alojamento do servidor SMP, a página do servidor XFTP e o documento sobre a segurança do protocolo. Quando um número é relevante, a página de origem é indicada a seguir.

Por que uma rede sem identificadores de utilizador ainda precisa de relays

O SimpleX não tem nomes de utilizador, números de telefone nem IDs de conta. Um contacto é uma fila unidirecional: um endereço num relay para onde uma das partes escreve e a outra lê. Dois dos seus contactos não partilham nenhum identificador que um servidor pudesse associar.

Essas filas ainda têm de ficar alojadas em algum lugar, por uma razão simples. Dois telefones raramente estão online no mesmo segundo. Algo tem de aceitar uma mensagem agora e mantê-la até que o outro dispositivo a peça. Essa é toda a função de um relay SMP. Isso também significa que os dois dispositivos nunca estabelecem uma ligação entre si, pelo que nenhum deles fica a conhecer o endereço IP (Internet Protocol) do outro. O relay absorve essa exposição.

O hostname do relay faz parte do endereço da fila, pelo que aparece em todas as ligações de convite que distribuir a partir dele. Tenha isso em conta quando ler o modelo de ameaças perto do fim.

O que um relay pode e não pode ver

O projeto apresenta isto como um modelo de ameaças em protocol/security.md. Vale a pena ler essa informação antes de instalar qualquer componente, porque, depois deste guia, esse relay será seu. Um relay, incluindo um totalmente controlado por um atacante, não pode descobrir o conteúdo nem o tipo das mensagens. Também não pode adicionar, duplicar ou corromper mensagens individuais sem ser detetado. Além disso, não pode quebrar a encriptação ponta a ponta através de um ataque ativo.

A mesma página lista o que um relay pode fazer. Pode saber quando um destinatário de uma fila está online. Pode contar quantas mensagens passam por uma fila. Pode descobrir o endereço IP de um destinatário. Pode eliminar todas as mensagens futuras de uma fila ou mentir sobre o estado dessa fila.

A separação é clara. A confidencialidade é responsabilidade do cliente, e o self-hosting não a altera. Os metadados e a disponibilidade são responsabilidade do operador do relay, e o self-hosting transfere ambos para si.

O que você precisa antes de começar

• Uma VPS com Ubuntu 22.04 ou 24.04. O projeto publica binários de release criados especificamente para essas duas versões, em x86-64 e aarch64.
• Um nome de domínio com um registo A apontado para a VPS, além de um registo AAAA se tiver IPv6. A documentação usa smp1.example.com como exemplo.
• Acesso root ou sudo, e uma segunda sessão SSH aberta enquanto altera a firewall.
• Um local fora do servidor para guardar uma cópia de segurança, porque o diretório de configuração é a identidade do servidor.

Numa instância ARM, use o ativo aarch64 em vez de x86-64. Nada mais neste guia muda, e a escolha entre planos de VPS ARM e x86 depende do preço e da velocidade por núcleo, não de o software ser executado ou não.

Instale uma versão fixa, não a versão "latest"

O projeto disponibiliza um script de instalação que obtém a versão atual e regista um comando simplex-servers-update. Funciona. Mesmo assim, fixe a versão: um relay cujo binário muda sem controlo é um relay que não pode analisar de forma previsível quando algo falha.

Em agosto de 2026, a versão atual do simplexmq é v6.5.0, publicada em 29 de abril de 2026. Consulte a página de versões para escolher a tag pretendida e use essa tag em todos os comandos abaixo.

sudo useradd -m smp
sudo install -d -o smp -g smp -m 755 /etc/opt/simplex /var/opt/simplex

useradd -m smp não define uma palavra-passe, portanto ninguém inicia sessão diretamente como smp. Crie os dois diretórios manualmente antes de executar qualquer outra coisa, porque /etc/opt pertence a root e tem o modo 755. Assim, o utilizador smp não fica sem um local onde possa escrever o seu próprio diretório de configuração.

VER=v6.5.0
curl -fL "https://github.com/simplex-chat/simplexmq/releases/download/$VER/smp-server-ubuntu-24_04-x86-64" -o /tmp/smp-server
sha256sum /tmp/smp-server

Compare esse hash com os checksums SHA2-256 publicados nas notas da versão da mesma tag. O projeto também assina os checksums das versões com a chave do SimpleX Chat FB44AF81A45BDE327319797C85107E357D4A17FC, documentada na página do servidor. Assim, pode verificar a assinatura em vez de confiar na página de onde obteve o hash.

sudo install -m 755 -o root -g root /tmp/smp-server /usr/local/bin/smp-server

Instale-o deliberadamente com root como proprietário. O serviço é executado como smp, portanto, se o serviço for comprometido, não poderá reescrever o binário a partir do qual é iniciado.

Inicialize o servidor e guarde os dois segredos que ele imprime

sudo su smp -c "smp-server init --yes --store-log --daily-stats --no-password --fqdn=smp1.example.com"

• --store-log (-l) grava um log append-only das filas em /var/opt/simplex/smp-server-store.log, para que o relay sobreviva a um reinício. Sem ele, um reinício elimina todas as filas, o que faz com que todos os contactos encaminhados através de si deixem de funcionar.
• --daily-stats (-s) grava contadores em formato CSV em /var/opt/simplex/smp-server-stats.daily.log.
• --fqdn inclui o seu domínio no certificado gerado. Use --ip se não tiver um domínio.
• --no-password permite que qualquer pessoa crie uma fila no seu relay. Para o manter privado, defina create_password em [AUTH] dentro de /etc/opt/simplex/smp-server.ini depois da inicialização, em vez de passar --password aqui, porque uma linha de comandos fica visível no histórico da shell e na lista de processos enquanto é executada.

O init gera um certificado e imprime os dois valores que tem de guardar. O primeiro é a impressão digital, uma cadeia base64 que também é gravada em /etc/opt/simplex/fingerprint. O segundo é o endereço completo do servidor, que consiste na impressão digital e no nome do host. Copie ambos agora.

O init também cria /etc/opt/simplex/ca.key, e a documentação indica que deve mover esse ficheiro para armazenamento offline. O motivo é importante: os clientes fixam a impressão digital dessa autoridade de certificação, por isso qualquer pessoa que tenha ca.key pode emitir um novo certificado de servidor que os seus clientes aceitam como sendo seu. Só precisa dele novamente para rodar o certificado do servidor mais tarde com smp-server cert.

Trate o init como uma operação única. A impressão digital no seu endereço vem da autoridade que ele gera, por isso regenerar essa autoridade cria um endereço diferente e invalida o endereço que distribuiu.

Execute-o com systemd como um utilizador sem privilégios

Escreva /etc/systemd/system/smp-server.service, exatamente como aparece na documentação:

[Unit]
Description=SMP server systemd service

[Service]
User=smp
Group=smp
Type=simple
ExecStart=/usr/local/bin/smp-server start +RTS -N -RTS
ExecStopPost=/usr/bin/env sh -c '[ -e "/var/opt/simplex/smp-server-store.log" ] && cp "/var/opt/simplex/smp-server-store.log" "/var/opt/simplex/smp-server-store.log.bak"'
LimitNOFILE=65535
KillSignal=SIGINT
TimeoutStopSec=infinity

[Install]
WantedBy=multi-user.target

A unidade upstream também inclui AmbientCapabilities=CAP_NET_BIND_SERVICE. Essa linha existe porque o processo é executado como smp, e as portas abaixo de 1024 estão fechadas para processos que não são root. Sem ela, o daemon não consegue associar-se às portas 80 ou 443. Adicione-a se disponibilizar essas portas. LimitNOFILE=65535 é importante porque cada cliente subscrito mantém uma ligação TCP aberta, e o limite predefinido é muito inferior ao necessário para um relay ocupado. ExecStopPost copia o log do store para um ficheiro .bak em cada paragem, fornecendo um ponto de rollback gratuito.

sudo systemctl daemon-reload
sudo systemctl enable --now smp-server
sudo systemctl status smp-server
sudo journalctl -fu smp-server

Um arranque normal regista o endereço do servidor. Em seguida, confirme se os sockets estão realmente abertos:

sudo ss -tlnp | grep -E ':(443|5223)'

Ambas as linhas devem indicar smp-server. Executar o daemon com a sua própria conta, sem permissões sudo, segue a mesma prática descrita em contas por serviço num VPS e impede que um erro num daemon de rede se transforme num root shell.

Quais portas abrir e qual manter fechada

A documentação lista três: 5223/tcp, 443/tcp e 80/tcp. A porta 5223 é o transporte SMP. A configuração fornecida define port: 5223,443 em [TRANSPORT], por isso o mesmo protocolo também responde na porta 443. Isto é importante porque muitas redes restritivas permitem tráfego de saída na porta 443 e bloqueiam todas as outras. A porta 80 só é necessária para a página de informações opcional e para o redirecionamento para HTTPS.

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 5223/tcp
sudo ufw enable

Não abra a porta 5224. Essa é a porta de controlo, e a documentação acede a ela a partir do próprio servidor com nc 127.0.0.1 5224. Ela apresenta o estado do servidor e elimina filas, por isso deve ficar limitada ao loopback, com as palavras-passe de administrador e de utilizador definidas em [AUTH]. Se ainda não conhece a ferramenta, os princípios básicos do ufw num VPS explicam a ordem das regras e como evitar perder o acesso ao servidor.

Há ainda outro controlo que costuma causar problemas. A maioria dos fornecedores executa uma firewall de rede no painel, separada do ufw no servidor. Uma porta pode estar aberta no ufw e, mesmo assim, ser bloqueada antes de o tráfego chegar ao servidor.

O endereço do servidor de que os seus clientes precisam

smp://<fingerprint>[:<password>]@<public_hostname>[,<onion_hostname>]

Essa string é toda a configuração do lado do cliente. Cole-a nas definições do servidor da aplicação ou permita que alguém leia o código QR apresentado pela aplicação. A documentação informa que o código QR inclui a palavra-passe. Por isso, a pessoa que o ler também poderá receber mensagens através do seu servidor.

Existe um comportamento documentado que surpreende toda a gente. Adicionar o seu servidor na aplicação só afeta os contactos criados a partir desse momento. Os contactos existentes continuam nos relays onde as respetivas filas foram criadas e não são migrados. É também por isso que não pode desligar um relay no dia seguinte à sua substituição.

Adicionar um relay de ficheiros XFTP

O XFTP (protocolo de transferência de ficheiros SimpleX) é a parte de ficheiros da rede. É um daemon separado com o seu próprio endereço. De acordo com o anúncio do XFTP do projeto, os relays não têm metadados de ficheiros: veem apenas blocos individuais, cada um com 256kb, 1mb ou 4mb, cujo acesso é autorizado por credenciais anónimas. Um remetente pode distribuir os blocos de um ficheiro por vários relays. Por isso, o seu servidor armazena partes, não ficheiros.

sudo useradd -m xftp
sudo install -d -o xftp -g xftp -m 755 /etc/opt/simplex-xftp /var/opt/simplex-xftp /srv/xftp
curl -fL "https://github.com/simplex-chat/simplexmq/releases/download/$VER/xftp-server-ubuntu-24_04-x86-64" -o /tmp/xftp-server
sudo install -m 755 -o root -g root /tmp/xftp-server /usr/local/bin/xftp-server
sudo su xftp -c "xftp-server init -l --fqdn=xftp1.example.com -q '20gb' -p /srv/xftp/"

A configuração fica em /etc/opt/simplex-xftp/, o estado fica em /var/opt/simplex-xftp/ e os blocos de ficheiros ficam no caminho indicado por -p. A unidade systemd tem a mesma estrutura, com User=xftp e ExecStart=/usr/local/bin/xftp-server start +RTS -N -RTS. O Init apresenta um endereço xftp:// no mesmo formato do endereço SMP, com a sua própria impressão digital em /etc/opt/simplex-xftp/fingerprint.

É necessário planear um conflito. A porta documentada do servidor XFTP é 443, e a configuração SMP também lista a porta 443. Dois processos não podem associar a mesma porta ao mesmo endereço. Por isso, num único VPS, é necessário alterar uma das configurações. A solução mais simples é definir port: 5223 na secção [TRANSPORT] do SMP e deixar a porta 443 para o relay de ficheiros. A desvantagem é perder o fallback na porta 443 para clientes em redes restritivas. As alternativas são adicionar um segundo endereço IP ao mesmo VPS ou usar um segundo VPS.

Defina a quota de forma realista. -q '20gb' representa uma reserva do espaço em disco disponível. O relay de ficheiros é o componente que consome disco e largura de banda. O relay de mensagens quase não consome nenhum dos dois.

O que fica no disco e o que um backup restaura

Dois diretórios são importantes. /etc/opt/simplex/ é a identidade: smp-server.ini, o certificado e a chave do servidor, ca.key e fingerprint. /var/opt/simplex/ é o estado: smp-server-store.log contém as filas e, quando restore_messages: on, as mensagens não entregues, juntamente com o ficheiro diário de estatísticas.

sudo systemctl stop smp-server
sudo tar czf /root/simplex-backup.tgz -C / etc/opt/simplex var/opt/simplex
sudo chmod 600 /root/simplex-backup.tgz
sudo systemctl start smp-server

É importante saber o que esse arquivo contém. Não é um arquivo de mensagens: os itens em fila são texto cifrado para chaves que o relay nunca teve, e a configuração [STORE_LOG] fornecida expira as mensagens após 21 dias. É uma cópia da identidade do servidor, incluindo ca.key, por isso qualquer pessoa que obtenha o ficheiro pode apresentar-se como o seu relay aos seus contactos. Cifre-o e mantenha-o fora do servidor.

A vantagem aparece na restauração. Coloque /etc/opt/simplex novamente num VPS novo, aponte o mesmo nome DNS para ele e a impressão digital permanecerá igual, pelo que todos os endereços que distribuiu continuarão a funcionar. Se perder esse diretório, não há recuperação: uma instalação nova terá uma impressão digital nova, o que significa um endereço novo e, portanto, todos os contactos encaminhados pelo seu relay serão perdidos.

TLS: dois certificados com funções diferentes

O transporte SMP não utiliza uma autoridade de certificação pública. O Init gera uma autoridade privada e um certificado de servidor, e a impressão digital dessa autoridade é incluída no endereço do servidor. O cliente compara o que o servidor apresenta com essa impressão digital fixada. É isso que o projeto descreve como proteção da ligação entre o cliente e o servidor contra ataques machine-in-the-middle. Não há nenhum cliente ACME (automatic certificate management environment) para executar nessa porta, e a rotação é uma execução manual de smp-server cert com SMP_SERVER_CFG_PATH definido.

A página de informações opcional utiliza o outro certificado. A sua secção [WEB] identifica static_path, https: 443, cert: /etc/opt/simplex/web.crt e key: /etc/opt/simplex/web.key. Um navegador nunca ouviu falar da sua autoridade privada. Por isso, é nesta página que deve ser utilizado um certificado confiado publicamente. O início rápido da documentação para Docker coloca o Caddy à frente do servidor precisamente para esse fim e emite o certificado automaticamente.

Aceder ao relay através do Tor

A documentação inclui uma secção sobre o Tor que instala o Tor a partir do repositório do Tor Project e adiciona um serviço oculto em /etc/tor/torrc:

SOCKSPort 0
HiddenServiceNonAnonymousMode 1
HiddenServiceSingleHopMode 1
HiddenServiceDir /var/lib/tor/simplex-smp/
HiddenServicePort 5223 localhost:5223
HiddenServicePort 443 localhost:443

Leia atentamente as duas linhas de modo. Single hop e non-anonymous significam que a localização do próprio relay não fica oculta. O endereço onion é rápido e fornece aos clientes uma forma de acesso que nunca revela o respetivo endereço IP, mas o servidor continua localizável através do seu IP público. O nome de host onion de /var/lib/tor/simplex-smp/hostname deve ser colocado no fim do endereço do servidor, depois de uma vírgula. Se também quiser ocultar a localização do servidor, essa é outra configuração, e executar um serviço onion real numa VPS aborda esse compromisso. A diferença entre aquilo que cada ferramenta oculta é o tema de Tor comparado com uma VPN, e aplica-se diretamente neste caso.

Modelo de ameaças: o que muda com o self-hosting

O que ele oferece. Os metadados (quais filas existem, quando são lidas e quais endereços se ligam) ficam numa máquina que controla, e define durante quanto tempo qualquer um deles é mantido. Também deixa de fazer parte de um grupo grande que pode ser solicitado de uma só vez.

O que ele não oferece, de forma clara:

• A encriptação não muda. As mensagens já tinham encriptação ponta a ponta antes de configurar isto e continuam a tê-la depois. O self-hosting é uma decisão sobre metadados, não sobre criptografia.
• O fornecedor do VPS vê o tráfego destinado ao seu endereço IP e guarda os seus dados de faturação. Transferiu a confiança de um operador de mensagens para um operador de alojamento. Não a eliminou.
• O seu relay é um grupo pequeno. Se servir uma única casa, ligar-se a ele identifica essa casa, e o seu hostname aparece em todas as ligações de convite que enviar a partir dele. Um relay público com muito movimento oferece mais anonimato nesse aspeto, e essa é a verdadeira troca. Um servidor de pesquisa privado tem a mesma característica, e é por isso que o que o SearXNG realmente oculta no seu próprio VPS depende de quantas pessoas partilham a instância consigo.
• A disponibilidade passa a ser da sua responsabilidade. Um disco cheio ou um equipamento parado faz com que as mensagens deixem de ser entregues, e os seus contactos não têm forma de contornar o problema.

O mesmo raciocínio aplica-se a qualquer serviço privado que coloque numa máquina sua, seja este relay ou uma VPN WireGuard no seu próprio VPS. Está a escolher qual das partes vê os metadados. Não os está a fazer desaparecer.

Quando não funciona

O serviço inicia e para imediatamente. Consulte sudo journalctl -u smp-server -n 50. Uma falha de bind indica a porta que o serviço não conseguiu ocupar. Em seguida, execute sudo ss -tlnp | grep :443 para ver qual processo já está a utilizá-la. Num servidor recém-instalado, normalmente é o nginx, o Caddy ou o servidor XFTP que instalou há uma hora.

O Init não consegue escrever a configuração. Executar smp-server init com o utilizador smp antes de /etc/opt/simplex existir gera um erro de permissões, porque /etc/opt pertence ao root. Crie primeiro o diretório com o proprietário correto e execute novamente o init.

Os clientes não conseguem chegar ao relay. Confirme se o nome resolve para o endereço correto com dig +short smp1.example.com. Em seguida, teste a porta a partir do seu portátil, não do servidor: nc -vz smp1.example.com 5223. Se a ligação falhar externamente enquanto ss mostra o socket aberto no servidor, o problema está na firewall de rede do fornecedor. Esse é um controlo separado do ufw.

Um contacto não consegue ligar-se através do seu relay. A impressão digital no endereço partilhado deve corresponder ao conteúdo atual de /etc/opt/simplex/fingerprint. Se definir create_password em [AUTH], o endereço também deve incluir essa palavra-passe. Caso contrário, o cliente não pode criar uma fila.

Nada foi transferido depois de adicionar o servidor na aplicação. Isso é esperado. Apenas os novos contactos utilizam o relay adicionado. Os contactos existentes mantêm as filas que já tinham.

FAQ

Um servidor SimpleX autoalojado torna as minhas mensagens mais seguras?

Não, e isso é intencional. O SimpleX cifra as mensagens de ponta a ponta entre dispositivos, pelo que o relay nunca tem as chaves, independentemente de quem o executa. O autoalojamento altera quem observa os metadados associados a essas mensagens: que filas existem, quando são lidas e que endereços IP estabelecem ligação. É uma decisão sobre metadados. Se o motivo para autoalojar o serviço for obter uma cifragem mais forte, a cifragem já existia.

O que consegue realmente ver um operador de relay SimpleX?

O protocol/security.md do projeto especifica estes limites. Um relay não consegue ler o conteúdo nem os tipos das mensagens, alterá-las individualmente sem ser detetado ou quebrar a cifragem de ponta a ponta através de um ataque ativo. Consegue ver quando o destinatário de uma fila está online, contar as mensagens que passam por uma fila, descobrir o endereço IP de um destinatário, eliminar mensagens futuras de uma fila ou fornecer informações falsas sobre o estado dessa fila. Esses são os poderes que passa a ter quando o relay é seu.

Preciso de um nome de domínio e de um certificado TLS?

Precisa de um domínio para ter uma configuração utilizável, e o smp-server init aceita --ip se realmente não tiver nenhum. Não precisa de um certificado emitido por uma autoridade pública para a porta de mensagens: o init gera a sua própria autoridade, e o cliente fixa a impressão digital apresentada no endereço smp:// do servidor. Só precisa de um certificado publicamente confiável para a página Web opcional com informações, configurada como cert e key na secção [WEB] de smp-server.ini.

O que acontece se eu perder /etc/opt/simplex?

Todos os endereços que forneceu deixam de funcionar. Esse diretório contém a autoridade de certificação cuja impressão digital está incorporada no endereço do servidor, pelo que uma reconstrução produz uma impressão digital diferente e, consequentemente, um servidor diferente. Os contactos cujas filas estão nesse relay não podem ser reparados do lado do cliente. Faça uma cópia de segurança cifrada do diretório fora do servidor e guarde ca.key offline, conforme indicado na documentação, porque quem o possuir pode fazer-se passar pelo seu relay.

Posso executar o relay SMP e o relay de ficheiros XFTP na mesma VPS?

Sim, mas é necessário resolver um conflito. A porta documentada do servidor XFTP é 443 e a configuração SMP predefinida lista port: 5223,443, pelo que ambos tentam usar o mesmo socket. Atribua a porta 443 a um deles: defina port: 5223 para o servidor SMP ou mova o relay de ficheiros para um segundo endereço IP ou para uma segunda VPS. Defina também a quota de armazenamento de acordo com o espaço em disco disponível, porque é o relay de ficheiros que consome disco e largura de banda.