Como hospedar um servidor SimpleX em uma VPS

O que faz um servidor SimpleX de chat autoalojado

Para autoalojar um servidor SimpleX de chat, execute um daemon numa VPS: smp-server, o relay do SMP (simplex messaging protocol). Este serviço mantém as filas de mensagens nas quais os seus contactos escrevem e que consultam. Um segundo daemon opcional, chamado xftp-server, encaminha transferências de ficheiros. Ambos pertencem ao mesmo projeto, simplexmq, e cada um consiste num binário único, num ficheiro de configuração e num log apenas de adição.

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 sob a sua responsabilidade é a disponibilidade do serviço, algum espaço em disco e os metadados que passam pelo seu servidor.

Todos os comandos, caminhos, portas e flags abaixo provê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 de segurança do protocolo. Quando um número é relevante, a página de origem é indicada junto dele.

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, onde uma das partes escreve e a outra lê. Dois dos seus contactos não partilham nenhum identificador que um servidor possa associar.

Essas filas ainda têm de existir em algum lugar, por uma razão simples. Dois telemóveis raramente estão online no mesmo segundo. Algo tem de aceitar uma mensagem agora e mantê-la até o outro dispositivo a solicitar. Essa é toda a função de um relay SMP. Isto também significa que os dois dispositivos nunca se ligam diretamente um ao outro, pelo que nenhum deles fica a saber 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 partilhar a partir dele. Tenha isto em mente ao ler o modelo de ameaças perto do fim.

O que um relay pode e não pode ver

O projeto apresenta este modelo de ameaça em protocol/security.md. Vale a pena lê-lo antes de instalar qualquer componente, porque, depois deste guia, esse relay será seu. Um relay, incluindo um relay totalmente controlado por um atacante, não consegue descobrir o conteúdo nem o tipo das mensagens. Também não consegue adicionar, duplicar ou corromper mensagens individuais sem ser detetado. Além disso, não consegue quebrar a encriptação de 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 coloca ambos sob a sua responsabilidade.

O que é necessário antes de começar

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

Em uma instância ARM, use o asset 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. Ainda assim, fixe a versão: se o binário de um relay mudar sem controlo, será difícil determinar a causa quando algo falhar.

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 utilize 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 diretório de configuração onde possa escrever.

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 como propriedade de root. O serviço é executado como smp, portanto um comprometimento do serviço não pode 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 somente para anexação 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 no 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 comando de inicialização 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.

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

Trate a inicialização como um passo único. A impressão digital no seu endereço vem da autoridade que o comando gera, portanto regenerar essa autoridade cria um endereço diferente e inutiliza o endereço que distribuiu.

Execute-o no 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 fornecida pelo projeto 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 sejam root. Sem essa linha, o daemon não consegue associar-se às portas 80 ou 443. Adicione-a se disponibilizar esses serviços nessas 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, o que fornece 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 privilégios 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 shell root.

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 respetivo 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-lhe a partir do próprio servidor com nc 127.0.0.1 5224. Ela mostra 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 conceitos básicos do ufw num VPS explicam a ordem das regras e como evitar bloquear o seu próprio acesso.

Há 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, ainda assim, o tráfego ser descartado antes de chegar ao servidor.

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

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

Essa linha é 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 salienta que o código QR inclui a palavra-passe. Por isso, quem o ler também pode receber mensagens através do seu servidor.

Há 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 permanecem 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.

Adicionando 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 de 256kb, 1mb ou 4mb, cujo acesso é autorizado por credenciais anónimas. O remetente pode distribuir os blocos de um ficheiro por vários relays. Por isso, o seu servidor armazena partes, não ficheiros completos.

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 processo de inicialização apresenta um endereço xftp:// no mesmo formato que o endereço SMP, com a sua própria impressão digital em /etc/opt/simplex-xftp/fingerprint.

É necessário planear uma colisão de portas. A porta documentada do servidor XFTP é 443, e a configuração SMP também indica 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. O custo é 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 utilizar um segundo VPS.

Defina a quota com base no espaço realmente disponível. -q '20gb' é uma reserva de espaço em disco que precisa de conseguir cumprir. O relay de ficheiros é o componente que mais 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

Há dois diretórios 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 de estatísticas diário.

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 perceber 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 ao fim de 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 perante os seus contactos. Cifre-o e mantenha-o fora do servidor.

A vantagem é a restauração. Coloque /etc/opt/simplex num VPS novo, aponte o mesmo nome DNS para ele e a impressão digital permanece igual, pelo que todos os endereços que forneceu continuam a funcionar. Se perder esse diretório, não há recuperação: uma instalação nova significa uma nova impressão digital, que significa um novo endereço, e todos os contactos encaminhados pelo seu relay deixam de estar acessíveis.

TLS: dois certificados com funções diferentes

O transporte SMP não usa 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 usa o outro certificado. A secção [WEB] indica static_path, https: 443, cert: /etc/opt/simplex/web.crt e key: /etc/opt/simplex/web.key. Um browser nunca ouviu falar da sua autoridade privada, portanto este é o único local onde deve ser usado um certificado publicamente confiável. O início rápido da documentação com Docker coloca o Caddy à frente do servidor exatamente 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 dá aos clientes uma forma de acesso que nunca revela o respetivo endereço IP, mas o próprio servidor continua localizável pelo seu IP público. O hostname onion de /var/lib/tor/simplex-smp/hostname é acrescentado no fim do endereço do servidor, depois de uma vírgula. Se também quiser ocultar a localização do servidor, essa é uma configuração diferente, e executar um serviço onion real numa VPS aborda essa decisão. A diferença entre aquilo que cada ferramenta oculta é o tema de Tor em comparação com uma VPN e aplica-se diretamente neste caso.

Modelo de ameaça: o que o self-hosting muda

O que você ganha. Os metadados — quais filas existem, quando são lidas e quais endereços se conectam — ficam numa máquina que você controla, e você define por quanto tempo qualquer um desses dados é mantido. Você também deixa de fazer parte de um grande conjunto de utilizadores cujos dados podem ser solicitados de uma só vez.

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

• A encriptação não muda. As mensagens já tinham encriptação de ponta a ponta antes de você criar isto e continuam a tê-la depois. O self-hosting é uma decisão sobre metadados, não sobre criptografia.
• O seu provedor de VPS vê o tráfego destinado ao seu endereço IP e mantém os seus dados de faturação. Você transferiu a confiança de um operador de mensagens para um operador de alojamento. Não eliminou essa confiança.
• O seu relay é um grupo pequeno. Se ele atender apenas uma residência, a ligação a esse relay identifica essa residência, e o nome de host aparece em cada link de convite que você enviar a partir dele. Um relay público movimentado oferece mais anonimato nesse aspeto, e essa é a verdadeira compensação.
• A disponibilidade passa a ser responsabilidade sua. Um disco cheio ou uma máquina indisponível interrompe a entrega das mensagens, e os seus contactos não têm como contornar essa falha.

O mesmo raciocínio aplica-se a qualquer serviço privado que você coloque numa máquina que controla, seja este relay ou uma VPN WireGuard na sua própria VPS. Você está a escolher qual entidade vê os metadados. Não está a fazê-los 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 processo não conseguiu usar. Em seguida, execute sudo ss -tlnp | grep :443 para ver qual processo já a está a utilizar. Num servidor acabado de instalar, 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 como 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 alcançar o relay. Confirme se o nome resolve para o endereço correto com dig +short smp1.example.com. Depois, 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. Este é um controlo separado do ufw.

Um contacto não consegue ligar-se através do seu relay. A impressão digital no endereço que partilhou tem de corresponder ao conteúdo atual de /etc/opt/simplex/fingerprint. Se definir create_password em [AUTH], o endereço também tem de 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. Esse comportamento é esperado. Apenas os novos contactos usam o relay recém-adicionado. Os contactos existentes mantêm as filas que já tinham.

FAQ

Um servidor SimpleX auto-hospedado torna as minhas mensagens mais seguras?

Não, e isso é intencional. O SimpleX cifra as mensagens de ponta a ponta entre dispositivos, por isso o relay nunca tem as chaves, independentemente de quem o execute. O auto-hospedagem 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 auto-hospedar o serviço for obter uma cifragem mais forte, essa cifragem já existia.

O que pode realmente ver um operador de relay SimpleX?

O protocol/security.md do projeto descreve isso. Um relay não pode ler o conteúdo nem os tipos das mensagens, não pode alterá-las individualmente sem ser detetado e não pode quebrar a cifragem de ponta a ponta através de um ataque ativo. Pode 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 mentir 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 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://. 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 distribuiu deixam de funcionar. Esse diretório contém a autoridade de certificação cuja impressão digital está incorporada no endereço do servidor, por isso 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 tiver 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, por isso ambos pretendem 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. Dimensione também a quota de armazenamento de acordo com o espaço em disco disponível, porque o relay de ficheiros é o componente que consome disco e largura de banda.