Desktop remoto auto-hospedado: o guia honesto de 2026

Procure por desktop remoto auto-hospedado e você encontra uma dúzia de tutoriais que terminam em docker compose up -d. A instalação é a parte fácil, e leva genuinamente 30 minutos. Este guia cobre tudo — e depois cobre a parte que decide se você deveria ter feito isso: quanto custa manter a coisa funcionando depois que o tutorial acaba.

Resposta curta

Auto-hospede quando um requisito o obrigar. Use um relay gerenciado quando nada o fizer. Isso soa simplista, então aqui está o teste real:

• Auto-hospede se: uma obrigação de conformidade por escrito exigir que o tráfego de sessão não transite por infraestrutura de terceiros; você opera redes air-gapped ou de outra forma restritas onde um relay externo é inacessível; ou regras de residência de dados especificam uma jurisdição na qual você deve permanecer.
• Use um relay gerenciado se: seu motivo for qualquer versão de "Prefiro executar eu mesmo." Isso é uma preferência legítima, e também é uma tarefa operacional permanente — veja a conta abaixo antes de se comprometer.

Vale esclarecer o que você está escolhendo, porque não são dois produtos diferentes. Tenvo é AGPL-3.0 e o relay gerenciado executa a mesma arquitetura hbbs/hbbr que este guia instala. A escolha é quem opera a máquina, não o que o software faz.

Primeiro: o que um relay realmente pode ver

Isso importa antes de qualquer outra coisa, porque normalmente é a razão pela qual as pessoas recorrem à auto-hospedagem — e normalmente é descrito incorretamente.

Numa conexão peer-to-peer direta, a sessão ocorre end-to-end entre os dois dispositivos. Quando uma conexão direta não pode ser estabelecida — symmetric NAT, firewalls corporativos restritivos — a sessão é então retransmitida através de um relay, e o TLS termina no relay. Quem opera esse relay, portanto, está em posição de ver o tráfego retransmitido. Não vamos dizer o contrário sobre o nosso.

Isso é uma propriedade do protocolo, não de quem paga pelo servidor. Executar o relay você mesmo não criptografa nada que um relay de fornecedor não criptografaria; muda quem ocupa essa posição. Se sua resposta para "quem está autorizado a ocupá-la" está escrita numa obrigação de conformidade, auto-hospedar é a resposta correta e o resto deste guia é para você. Se não estiver escrita em lugar nenhum, você está assumindo um trabalho operacional para resolver um problema que não tem.

O que você está construindo

Dois serviços:

• hbbs (rendezvous server): lida com o handshake inicial. Ambos os clientes conectam-se brevemente a ele para se descobrirem, trocar chaves públicas e verificar se P2P direto é possível. Escuta em TCP/UDP 21115-21117.
• hbbr (relay server): transporta a sessão quando o P2P direto falha. Escuta em TCP 21117 (e UDP em alguns cenários).

O relay só entra em ação quando o P2P não funciona — comum em NAT de consumidor, raro em uma configuração na mesma LAN. Então, mesmo auto-hospedado, você só paga a largura de banda do VPS pelas sessões que realmente precisam do relay.

Passo 1: Escolha um VPS

Largura de banda é o recurso que importa. CPU e RAM são mínimos, já que o relay encaminha bytes em vez de processá-los.

• Hetzner CX22 (€4/mo, 2 vCPU, 4 GB RAM, 20 TB bandwidth, EU data centres) — melhor relação preço/largura de banda.
• DigitalOcean Basic Droplet ($6/mo, 1 vCPU, 1 GB, 1 TB bandwidth) — boa UX, regiões US/EU.
• OVH VPS Starter (€3.50/mo, 2 vCPU, 2 GB, unmetered bandwidth) — melhor para cenários de alta largura de banda.

Escolha uma região próxima aos clientes que vão se conectar. O tráfego do relay é limitado pelo tempo de ida e volta, então este é o maior fator que você tem sobre latência percebida — e, como abordado abaixo, aquele em que um único VPS é pior.

Passo 2: Configure o servidor

Crie um VPS novo com Ubuntu 22.04 ou Debian 12. Faça SSH como root.

# Update + harden basics
apt update && apt upgrade -y
apt install -y ufw fail2ban docker.io docker-compose-plugin
ufw allow 22/tcp     # SSH
ufw allow 21115:21119/tcp
ufw allow 21115:21119/udp
ufw enable
systemctl enable --now docker

Não pule o firewall. A configuração padrão expõe apenas as portas necessárias; todo o resto deve ser bloqueado.

Passo 3: Rode hbbs + hbbr via Docker

Crie /opt/tenvo-relay/docker-compose.yml:

services:
  hbbs:
    image: rustdesk/rustdesk-server:latest
    container_name: hbbs
    restart: unless-stopped
    ports:
      - "21115:21115/tcp"
      - "21116:21116/tcp"
      - "21116:21116/udp"
      - "21118:21118/tcp"
    command: hbbs -r your-server.example.com:21117
    volumes:
      - ./data:/root
  hbbr:
    image: rustdesk/rustdesk-server:latest
    container_name: hbbr
    restart: unless-stopped
    ports:
      - "21117:21117/tcp"
      - "21119:21119/tcp"
    command: hbbr
    volumes:
      - ./data:/root

Substitua your-server.example.com pelo hostname real, então inicie:

cd /opt/tenvo-relay
mkdir -p data
docker compose up -d
docker compose logs --tail 20

O hbbs imprime uma chave pública na primeira inicialização. Salve-a a partir dos logs (id_ed25519.pub no volume data) — os clientes a usam para verificar que estão se conectando ao seu relay e não a um impostor.

Passo 4: Configure o DNS

Aponte um registro A para relay.yourdomain.com para o IP do VPS. Um endereço IP funciona também, mas um nome de host é muito mais fácil de usar se você migrar.

Passo 5: Aponte os clientes para o seu relay

A parte que a maioria dos guias ignora. Cada cliente precisa de três valores:

• Servidor de ID = relay.yourdomain.com:21116
• Servidor relay = relay.yourdomain.com:21117
• Chave pública = o conteúdo de data/id_ed25519.pub do seu VPS

No Windows, macOS e Linux:

1. Abra o cliente Tenvo ou RustDesk.
2. Settings → Network → ID/Relay server.
3. Insira os três valores acima e salve.
4. Reinicie o cliente.

O indicador de status deve ficar verde em alguns segundos. Se permanecer vermelho, verifique as regras do firewall e se a chave pública corresponde exatamente — uma quebra de linha no final é o culpado mais comum.

Passo 6: Adicione TLS

Coloque um reverse proxy na frente das portas do relay. Caddy é o caminho mais curto:

relay.yourdomain.com {
    reverse_proxy /ws/* localhost:21118
    reverse_proxy * localhost:21115
}

Caddy emite e renova o certificado Let's Encrypt para você. Atualize os clientes para usar a porta 443 com TLS habilitado — o que também permite passar por firewalls de saída restritivos que só permitem 443.

Passo 7: Faça backup das chaves

O diretório data/ contém o par de chaves do servidor rendezvous. Se você perdê-lo, cada cliente precisará ser reconfigurado com uma nova chave pública — manualmente, em cada máquina.

# Local backup
rsync -avz vps:/opt/tenvo-relay/data/ ~/tenvo-relay-backup-$(date +%Y%m%d)/
# OR copy the two key files
scp vps:/opt/tenvo-relay/data/id_ed25519* ~/tenvo-keys/

Armazene-o offline. Se o VPS for comprometido, você vai querer reconstruir em uma máquina nova com as mesmas chaves, para que os clientes existentes continuem funcionando sem alterações.

Os modos de falha que os tutoriais ignoram

Clientes não conseguem alcançar o relay. Quase sempre é o firewall. Verifique ufw status, verifique se o grupo de segurança do provedor cloud permite as mesmas portas, e execute nc -vz relay.yourdomain.com 21116 a partir de um cliente para confirmar a conectividade.

Tudo cai para o relay. Symmetric NAT e firewalls corporativos restritivos forçam toda sessão pelo relay. O desempenho se mantém, mas sua conta de largura de banda passa a ser a história inteira, não a exceção.

O relay morre e não volta. A opção do Docker restart: unless-stopped cobre os casos comuns. Não cobre disco cheio, um OOM kill ou um kernel panic — para esses você precisa de monitoramento que alerte alguém, e essa pessoa é você.

O certificado expira. Automático com Caddy. Com nginx + certbot é um cron que você precisa lembrar que é sua responsabilidade; certbot.eff.org tem o guia oficial.

A conta que os tutoriais não mostram

O VPS de €4 é a linha mais barata na fatura, e citá-lo como o custo da auto-hospedagem é o mesmo truque de citar o preço de compra de um carro como o custo de dirigir. O resto dele:

• Você está de plantão pelo seu próprio relay. Quando ele morrer às 2h, o acesso remoto é justamente o que você não terá para consertá-lo.
• Atualização do SO, para sempre. Uma máquina voltada para a internet é uma máquina pela qual você é responsável manter atualizada.
• Custódia das chaves. Perder data/ e você terá que reconfigurar cada cliente manualmente. Esse backup agora é algo que você precisa realmente verificar, não apenas agendar.
• Renovação de certificado. Automática até o dia em que não é.
• Uma região, uma máquina. Um único VPS é uma localização e sem failover. Clientes do outro lado do mundo pagam por isso em latência de ida e volta; se a máquina cair, todos caem.

A largura de banda é o único custo que é realmente fácil de estimar. Valores aproximados por sessão retransmitida:

• Baixa qualidade, trabalho com muito texto: ~50 KB/s = 180 MB/hora
• Média, trabalho de escritório geral: ~200 KB/s = 720 MB/hora
• Alta, trabalho com vídeo e design: ~1 MB/s = 3.6 GB/hora

Os 20 TB/mês de uma Hetzner CX22 cobrem aproximadamente 5.500 horas de sessões retransmitidas de alta qualidade. Para um indivíduo ou uma pequena equipe esse teto raramente é o fator limitante — que é justamente o ponto. Se largura de banda era o motivo para você se auto-hospedar, não é um bom motivo. Os fatores limitantes são os quatro marcadores acima.

O que o relay gerenciado faz em vez disso

Mesma arquitetura, operador diferente. A frota de relays é multi-região em vez de um VPS, então os clientes se conectam a algo próximo a eles em vez de próximo a você. É monitorado por pessoas cujo trabalho é isso. Material de chaves, aplicação de patches e renovação de certificados deixam de ser seu problema. Quando algo quebra às 2h, a pessoa acionada não é você.

Isso é o que a assinatura compra: Free at $0, Lite at $2.99/mo, Pro at $7.99/mo — veja preços para o que cada nível inclui, ou planos empresariais se você estiver implantando em uma equipe. Em comparação com um VPS de €4 mais sua própria escala de plantões, a aritmética não é parelha para a maioria das pessoas.

Quando auto-hospedar é realmente a escolha correta

É a escolha certa quando uma obrigação a exige: trabalho regulado onde o tráfego não pode atravessar infraestrutura de terceiros, redes air-gapped ou restritas onde um relay externo é inacessível, ou regras de residência que te prendem a uma jurisdição. Nesses casos o custo operacional não é uma sobrecarga, é o requisito, e este guia é exatamente o que você precisa.

Também importa que a opção exista. Tenvo é AGPL-3.0 e o stack de servidor é open source, então o relay gerenciado é uma conveniência que você compra, não uma trava que você aceita. Se algum dia deixarmos de valer a pena, a saída é o guia acima — esse é o objetivo de publicá-lo. Veja como a build gerenciada se compara ao RustDesk puro, ou como o modelo de segurança funciona.

Recapitulação

1. Um VPS na região mais próxima dos seus clientes.
2. Docker, UFW, e os containers hbbs/hbbr.
3. Um registro A no DNS apontando para o VPS.
4. Três valores de configuração em cada cliente: Servidor de ID, servidor relay, chave pública.
5. Um backup offline de data/ que você já tenha realmente restaurado pelo menos uma vez.
6. TLS via Caddy, e monitoramento que alerte você.

Trinta minutos para levantar; indefinidamente para possuir. Se um requisito te coloca nessa posição, os passos acima são o trabalho completo. Se nada o faz, comece com o relay gerenciado — faça o download do cliente, e volte a esta página no dia em que um formulário de conformidade tornar isso relevante.