Docker para RustDesk: guia do servidor RustDesk containerizado

Você quer hospedar o RustDesk sem lidar com builds manuais, inferno de dependências ou imagens de VM frágeis. Este guia mostra como executar uma stack de servidor RustDesk pronta para produção com Docker e Docker Compose, para que você gerencie atualizações, backups e escalabilidade como um profissional de operações — não um entusiasta.

Por que usar Docker para RustDesk

Containers oferecem duas vantagens imediatas para uma stack de acesso remoto autohospedada: implantações reproduzíveis e isolamento. Em vez de compilar hbbs/hbbr localmente ou rodar pacotes específicos da plataforma, você puxa uma imagem Docker, monta um volume persistente e inicia. Isso simplifica upgrades, CI/CD e migrações de host. Se você já executa outros serviços em containers (NGINX, certbot, monitoramento), adicionar RustDesk dessa forma mantém sua stack consistente.

Quando não containerizar: se você precisa de binários com patches personalizados ou integração profunda com o kernel para um relay de altíssimo desempenho, uma instalação nativa pode ser preferível. Além disso, se precisar de um SLA empresarial oficialmente suportado pelo fornecedor, verifique se containers são suportados por esse fornecedor.

Componentes do servidor RustDesk — visão geral

O RustDesk divide o papel do servidor em pelo menos duas partes:

• hbbs — o servidor de ID/sinalização. Responsável pelo registro e pelo rendezvous dos clientes.
• hbbr — o servidor de relay (quando a travessia de NAT falha). Ele relaya o tráfego entre pares.

Em produção normalmente você executa ambos. Um único host leve pode rodar os dois serviços; implantações maiores os separam, colocam instâncias hbbr atrás de um balanceador de carga e adicionam autoscaling para capacidade de relay.

Início rápido: exemplo de implantação com Docker Compose

Pré-requisitos: Ubuntu 22.04 LTS (ou qualquer Linux com Docker Engine 20.10+), Docker Compose v2.x, um nome de domínio (exemplo: rustdesk.example.com). Aloque pelo menos 512 MB de RAM para um servidor de teste pequeno; 1 GB+ é recomendado para um relay que vai lidar com múltiplas sessões ativas.

Abaixo está um exemplo prático de Docker Compose que executa hbbs e hbbr em serviços separados, monta dados persistentes e publica as portas padrão do RustDesk. Antes de executar, verifique as tags oficiais da imagem rustdesk/rustdesk-server para o último tag estável e substitua rustdesk/rustdesk-server:latest se você quiser uma versão fixada.

version: '3.8'

services:
  hbbs:
    image: rustdesk/rustdesk-server:latest
    container_name: rustdesk-hbbs
    command: ["hbbs", "--listen", "0.0.0.0:21115"]
    ports:
      - "21115:21115/tcp"
      - "21115:21115/udp"
    volumes:
      - ./data/hbbs:/data
    restart: unless-stopped

  hbbr:
    image: rustdesk/rustdesk-server:latest
    container_name: rustdesk-hbbr
    command: ["hbbr", "--listen", "0.0.0.0:21116", "--relay", "0.0.0.0:21116"]
    ports:
      - "21116:21116/tcp"
      - "21116:21116/udp"
    volumes:
      - ./data/hbbr:/data
    restart: unless-stopped

networks:
  default:
    external: false

Explicação:

• Executamos hbbs nas portas TCP/UDP 21115 e hbbr na 21116 — esses são os defaults comuns para builds do RustDesk. Confirme o mapeamento de portas para a imagem que você usa (algumas builds comunitárias usam defaults diferentes).
• Volumes persistentes ./data/hbbs e ./data/hbbr mantêm seus dados de registro e relay entre reinicializações.
• Use restart: unless-stopped para uma resiliência básica; em produção, integre-se às políticas de reinício da sua plataforma de orquestração.

Expor com segurança: TLS, proxy reverso e firewall

O tráfego de sinalização e relay do RustDesk pode ser protegido por TLS e regras padrão de firewall. Existem duas abordagens comuns:

1. TLS direto com um proxy à frente do hbbs (recomendado para gestão de certificados em nível web).
2. Manter hbbr como relay TCP/UDP puro e proteger a rede do host (use ufw/nftables) enquanto protege o hbbs com TLS.

A maioria das configurações usa NGINX ou Traefik para terminar TLS e encaminhar o tráfego para hbbs. Exemplo de bloco de servidor NGINX para terminar TLS para rustdesk.example.com:

server {
  listen 443 ssl;
  server_name rustdesk.example.com;

  ssl_certificate /etc/letsencrypt/live/rustdesk.example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/rustdesk.example.com/privkey.pem;

  location / {
    proxy_pass http://127.0.0.1:21115;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
  }
}

# Optional: redirect http to https
server {
  listen 80;
  server_name rustdesk.example.com;
  return 301 https://$host$request_uri;
}

Use certbot (Let's Encrypt) ou sua CA para obter certificados. Se seu relay (hbbr) estiver em público via UDP/TCP, exponha essas portas diretamente e limite o firewall aos intervalos de IP que você espera, ou coloque os nós de relay em uma sub-rede privada atrás de um balanceador de carga.

DNS, clientes e travessia de NAT

Aponte um registro DNS A (por exemplo, rustdesk.example.com) para o IP público do seu servidor. No cliente RustDesk, defina o endereço do servidor para esse domínio (para lookup de ID e relay). Os clientes usam o servidor de ID para rendezvous; se ambos os clientes estiverem atrás de NAT restritivo, hbbr relayará a sessão pelo seu servidor de relay.

Se você controla máquinas clientes em uma LAN, pode rodar um DNS interno ou distribuir um arquivo de configuração que aponte os clientes para o IP interno do hbbs para conexões locais mais rápidas.

Dimensionamento e orientação de recursos

Quanto CPU/RAM um relay precisa? Depende de sessões concorrentes e do tipo de sessão:

• Servidor de teste pequeno: 1 vCPU, 512 MB RAM — poucas conexões ociosas.
• Relay de produção (uso leve): 2 vCPU, 1–2 GB RAM — dezenas de sessões concorrentes.
• Relay de alta taxa: 4+ vCPU, 4+ GB RAM e capacidade de rede compatível com a largura de banda esperada (por exemplo, 100+ Mbps).

Recomendamos autoscaling de instâncias hbbr atrás de um balanceador de carga se você espera picos (controle remoto com mídia, compartilhamento de tela). Use orquestração de containers (Kubernetes, Docker Swarm) ou escalonamento horizontal simples com um balanceador TCP/UDP (haproxy, cloud LB) que preserve IPs dos clientes.

Backups, atualizações e fixação de versão

Monte sempre volumes persistentes para dados e faça backups regulares. Um script de backup mínimo:

# daily-backup.sh
TIMESTAMP=$(date +%F)
mkdir -p /backups/rustdesk/$TIMESTAMP
rsync -a ./data /backups/rustdesk/$TIMESTAMP/
# rotate: keep 14 days
find /backups/rustdesk -maxdepth 1 -type d -mtime +14 -exec rm -rf {} \;

Para atualizações, fixe a imagem Docker com uma tag em vez de :latest. Execute um teste em staging ao atualizar a imagem do servidor. Fluxo de trabalho exemplo:

1. Puxe a nova imagem: docker pull rustdesk/rustdesk-server:1.3.0 (exemplo).
2. Suba um container de teste com os mesmos volumes e execute smoke tests.
3. Agende uma janela de manutenção e substitua os containers nos hosts de produção.

Solução de problemas e armadilhas comuns

Comece pelos logs: docker logs rustdesk-hbbs e docker logs rustdesk-hbbr. Problemas típicos:

• Clientes não conseguem se registrar: verifique se o hbbs é alcançável pelo domínio e se o TLS é válido.
• As sessões caem para relay mas o desempenho é ruim: inspecione CPU/memória e rede do host de relay. Pacotes de relay são tipicamente UDP; garanta que UDP esteja permitido pelo firewall e pelo grupo de segurança da nuvem.
• Clientes mostram versões incompatíveis: use versões compatíveis de cliente/servidor RustDesk. Se você fixar a imagem do servidor, garanta que os clientes não estejam usando recursos de protocolo obsoletos.

Se a travessia de NAT falhar consistentemente para muitos clientes, o problema geralmente é NAT simétrico ou firewalls corporativos. Nesses casos, apoie-se em relays hbbr e monitore latência/largura de banda para garantir UX aceitável.

Considerações de segurança

Autohospedar transfere a responsabilidade para você. Passos-chave:

• Termine TLS em um proxy reverso e use cifras fortes. Obtenha certificados do Let's Encrypt ou de uma CA confiável.
• Endureça o host: abra apenas as portas necessárias, habilite atualizações de segurança automáticas no SO e use um firewall (ufw/nftables).
• Limite acesso às interfaces administrativas e monitore logs em busca de tentativas de força bruta. Considere segmentação de rede; coloque nós de relay em uma sub-rede separada quando possível.

Se quiser uma discussão mais ampla sobre como travar o acesso remoto, veja nossos artigos sobre segurança de desktop remoto e as considerações práticas em desktop remoto autohospedado.

Quando um fornecedor gerenciado é melhor

Autohospedar com Docker oferece controle e privacidade, mas se você precisa de um SLA totalmente gerenciado, funcionalidades enterprise oficiais (gerenciamento de usuários, faturamento centralizado) ou integração pronta com Windows AD, fornecedores comerciais como TeamViewer ou AnyDesk podem ser opções melhores. Seja realista sobre os trade-offs: autohospedar reduz taxas recorrentes por assento e garante localidade de dados, mas consome tempo de operações para manter, monitorar e proteger a solução.

Próximos passos e referências

Checklist para ir do laboratório à produção:

1. Escolha um host com Docker Engine 20.10+ e Docker Compose v2.x.
2. Crie volumes persistentes e um job de backup diário.
3. Fixe a imagem do servidor e valide atualizações em staging.
4. Termine TLS com NGINX/Traefik e obtenha certificados do Let's Encrypt.
5. Monitore os hosts de relay e escale hbbr quando CPU ou largura de banda atingirem limiares de saúde.

Quer um download limpo para comparar lado a lado com a abordagem em containers? Baixe os binários ou instaladores do Tenvo em /download e verifique nossa página /pricing para opções de implantação. Se preferir seguir um guia mais amplo de acesso remoto, nosso guia de configuração de acesso remoto cobre rede, autenticação e usabilidade entre ferramentas.

Executar o RustDesk com Docker é uma abordagem sólida e de fácil manutenção para a maioria dos autohospedeiros: simplifica upgrades e se integra bem com infra de containers existente. Se quiser uma cópia do arquivo compose ou ajuda para adaptar isso ao Kubernetes, me avise e eu fornecerei um manifesto K8s e um exemplo de Helm chart.

Pronto para testar? Baixe os clientes necessários ou as imagens de teste em /download e coloque seu servidor RustDesk containerizado em funcionamento hoje.