Skip to content
Back to BlogGuide

Desktop Remoto Auto-hospedado: O Guia Completo 2026 (RustDesk + GoDesk Relay)

GoDesk Editorial Team12 min de leitura
Desktop Remoto Auto-hospedado: O Guia Completo 2026 (RustDesk + GoDesk Relay)

Quer desktop remoto onde seu tráfego nunca passe pelos servidores de um fornecedor? Este guia mostra como auto-hospedar o relay de ponta a ponta em um VPS de $5/month — o que instalar, como endurecê-lo e como lidar com modos de falha que a documentação ignora.

Para a maioria dos usuários, o relay hospedado pelo fornecedor (TeamViewer, AnyDesk, GoDesk) é aceitável. A criptografia de ponta a ponta faz com que o relay veja apenas texto cifrado — ele não pode ler seus frames de tela, pressionamentos de teclas ou arquivos. Mas "aceitável" não é "ideal" se você tiver uma destas restrições:

  • Conformidade: setor regulado onde os dados não podem transitar por infraestrutura de terceiros (jurídico, defesa, certos cuidados de saúde).
  • Soberania: você não quer que seus metadados de acesso remoto (quem conectou em quê, quando, por quanto tempo) sejam coletados por terceiros.
  • Custo em escala: se você roda 100+ dispositivos através de um relay, as cobranças do fornecedor somam — um relay auto-hospedado em um $5 VPS lida com milhares de sessões.
  • Redes isoladas ou restritas: o relay do fornecedor não é alcançável a partir do seu ambiente.

Se qualquer uma dessas se aplica, este guia mostra como auto-hospedar de ponta a ponta em um VPS básico. A pilha de referência é hbbs + hbbr do RustDesk, na qual tanto clientes GoDesk quanto RustDesk conseguem se conectar. Tempo total de configuração: cerca de 30 minutos incluindo TLS.

O que você vai montar

Dois serviços:

  • hbbs (servidor de rendezvous): lida com o handshake inicial. Ambos os clientes conectam-se a ele brevemente para se descobrirem, trocar chaves públicas e verificar se P2P direto é possível. Escuta em TCP/UDP 21115-21117.
  • hbbr (servidor relay): se o P2P direto falhar (NAT, firewall), o tráfego flui através do relay. Escuta em TCP 21117 (e UDP em alguns cenários).

O relay só entra em cena quando o P2P não funciona — o que ocorre na maioria dos cenários de consumidor por causa de NAT, mas é raro em uma rede local. Então, mesmo com relay auto-hospedado, você paga largura de banda do VPS apenas pelas sessões que precisarem dele.

Passo 1: Escolha um VPS

A largura de banda é o recurso principal. CPU e RAM são mínimos (o relay apenas encaminha bytes). Escolhas razoáveis em 2026:

  • Hetzner CX22 (€4/mo, 2 vCPU, 4 GB RAM, 20 TB de largura de banda, datacenters na EU) — melhor relação preço/largura de banda.
  • DigitalOcean Basic Droplet ($6/mo, 1 vCPU, 1 GB, 1 TB de largura de banda) — boa experiência, regiões US/EU.
  • OVH VPS Starter (€3.50/mo, 2 vCPU, 2 GB, largura de banda ilimitada) — melhor para cenários de alto consumo.
  • Hetzner Storage Box — NÃO é um VPS, citado porque alguns leitores perguntam. Não serve para este caso; você precisa de um servidor de verdade.

Escolha uma região próxima dos clientes que vão se conectar — isso importa para latência, já que o tráfego do relay é sensível ao tempo de ida e volta.

Passo 2: Configure o servidor

Crie um VPS novo com Ubuntu 22.04 ou Debian 12. Acesse por 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 do RustDesk expõe apenas as portas necessárias, mas o resto deve ficar bloqueado.

Passo 3: Execute hbbs + hbbr via Docker

Crie /opt/godesk-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. Inicie:

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

Você deve ver o hbbs imprimir uma chave pública no primeiro início — salve-a dos logs (id_ed25519.pub no volume data) porque os clientes a usam para verificar que estão se conectando AO SEU relay e não a um ataque man-in-the-middle.

Passo 4: Configure o DNS

Aponte um registro A para relay.yourdomain.com para o IP do VPS. O RustDesk também aceita um IP cru, mas um hostname é mais flexível se você migrar depois.

Passo 5: Aponte os clientes para o relay auto-hospedado

Esta é a parte que a maioria dos guias passa por cima. Cada cliente precisa de três valores de configuração:

  • 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 / Linux:

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

O indicador de status deve ficar verde em alguns segundos, mostrando que está registrado no seu relay. Se permanecer vermelho, verifique as regras de firewall e se a chave pública bate exatamente.

Passo 6: Adicione TLS (opcional, mas recomendado)

O protocolo padrão do RustDesk já é criptografado na camada de aplicação (a chave pública que você copiou faz parte disso). Adicionar TLS por cima acrescenta uma segunda camada e protege contra alguns ataques passivos na rede. A configuração envolve um proxy reverso (nginx ou Caddy) na frente das portas do relay.

Versão Caddy (mais simples):

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

O Caddy emite automaticamente o certificado Let's Encrypt. Atualize os clientes para usar a porta 443 com TLS habilitado.

Passo 7: Faça backup das chaves

O diretório data/ contém o par de chaves do servidor de rendezvous. Se você o perder, todos os clientes terão que ser reconfigurados com a nova chave pública. Faça backup:

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

Armazene o backup offline. Se o VPS for comprometido, você quer poder subir outro com as mesmas chaves para que os clientes existentes continuem funcionando sem reconfiguração.

Modos de falha que a documentação não menciona

Falha 1: Clientes não conseguem alcançar o relay. 90% das vezes isso é o firewall. Verifique ufw status, confirme que o grupo de segurança do provedor de nuvem também permite as mesmas portas, e execute nc -vz relay.yourdomain.com 21116 de um cliente para verificar alcançabilidade.

Falha 2: P2P sempre cai para o relay. NAT simétrico ou firewalls corporativos estritos forçam tudo pelo relay. Isso é normal — o desempenho é aceitável, mas aplica-se medição de largura de banda. Use relay.yourdomain.com com um plano VPS de alta largura de banda.

Falha 3: O processo do relay morre e não reinicia. O restart: unless-stopped do Docker cobre a maioria dos casos. Adicione docker compose ps em um cron que alerte você sobre containers ausentes.

Falha 4: O certificado SSL expira. Se você usa Caddy, isso é automático — ele renova 30 dias antes do vencimento. Se usa nginx + certbot, configure um cron para renovar. certbot.eff.org tem o guia oficial.

Cálculo de largura de banda

A qualidade importa aqui. Estimativa aproximada:

  • 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 (vídeo, design): ~1 MB/s = 3.6 GB/hora

Um Hetzner CX22 com 20 TB/mês trata aproximadamente 5.500 horas de sessões de alta qualidade por mês — muito mais do que qualquer indivíduo ou pequena equipe usará. O limite de 20 TB é mais relevante para organizações com centenas de dispositivos.

Opção pré-construída: o relay auto-hospedável da GoDesk

Tudo acima é a rota manual usando a pilha open-source do RustDesk. GoDesk publica um bundle auto-hospedável do mesmo stack hbbs/hbbr com padrões sensatos pré-configurados. Se você não quer gerenciar arquivos Docker compose, veja our self-hosting guide — mesma arquitetura, com um script de instalação one‑command que embrulha os passos acima.

Quando NÃO auto-hospedar

Auto-hospedar adiciona custo operacional: monitoramento, backups de chave, atualizações do SO, renovação de certificados. Se seu caso é "quero acessar meu PC doméstico", o relay hospedado pelo fornecedor (o tier gratuito do GoDesk lida com 5 GB/month) dá muito menos trabalho do que gerenciar um VPS para sempre.

Auto-hospede se você tiver um motivo real — conformidade, soberania, escala. Evite se "seria legal" for a única motivação; o custo operacional alcança você eventualmente.

Resumo

  1. $5/month VPS na sua região preferida.
  2. Docker + UFW + containers hbbs/hbbr do RustDesk.
  3. Registro A de DNS apontando para o VPS.
  4. Três valores de configuração em cada cliente (Servidor de ID, servidor relay, chave pública).
  5. Faça backup das chaves.
  6. Opcional: TLS via Caddy/nginx.

Tempo de configuração fim-a-fim: 30 minutos. Manutenção contínua: mínima. O resultado: desktop remoto onde seu tráfego nunca transita pela infraestrutura de terceiros.

Para mais sobre o lado GoDesk disso — documentação de auto-hospedagem, o panorama open-source, ou o cliente.