Desktop Remoto Autohospedado: Por que, como e o que pode quebrar

"Self-hosted remote desktop" geralmente significa uma de duas coisas: hospedar sua própria infraestrutura de relay/rendezvous para uma ferramenta como RustDesk, ou hospedar uma plataforma completa de acesso remoto baseada na web como Apache Guacamole ou MeshCentral. Ambas são abordagens legítimas; têm tradeoffs diferentes. Este artigo descreve por que você pode querer hospedar por conta própria, as três ferramentas sérias neste espaço, como é o overhead operacional na prática, e quando hospedar por conta própria é realmente melhor do que usar um serviço gerenciado.

Resumo: Hospede por conta própria se você tem requisitos rígidos de soberania de dados (GDPR, indústrias reguladas, implantações apenas internas), se quer custo zero contínuo de licenciamento em escala, ou se prefere genuinamente operar sua própria infraestrutura. Evite hospedar por conta própria se você é uma equipe pequena sem DevOps dedicado, se precisa de certificações aceitas em processos de compra, ou se prefere pagar $7.99/mo para eliminar o problema.

Por que hospedar por conta própria?

Soberania de dados

A razão número um para organizações autohospedarem. Se você está sujeito a GDPR, HIPAA, ou regulamentos setoriais (bancos alemães, governo francês, contratantes de defesa), rotear sessões de desktop remoto através de um SaaS de terceiros, mesmo com criptografia forte, pode não satisfazer seus auditores. Hospedar por conta própria em infraestrutura que você possui (ou aluga em uma região que você controla) elimina totalmente a dependência de terceiros. Nosso relay gerenciado termina o TLS, então "o relay é nosso" é uma posição de conformidade materialmente mais forte do que confiar essa função a outra parte.

Implantações apenas internas

Se seu tráfego de desktop remoto nunca deve sair da sua rede — por exemplo, um sistema de controle industrial em air-gap da internet, ou uma LAN hospitalar com filtragem de saída rigorosa — um serviço em nuvem gerenciado é estruturalmente inadequado. Você quer um relay que viva na sua LAN, acessível apenas para seus dispositivos autorizados.

Custo em escala

Para implantações muito grandes (1000+ endpoints), preços gerenciados por assento somam rápido. Um relay autohospedado rodando em um $40/month VPS pode servir milhares de sessões simultâneas se sua largura de banda permitir. O ponto de equilíbrio em relação ao preço gerenciado depende da ferramenta, mas em escala MSP e enterprise, autohospedar vence no custo bruto.

Customização e controle

Hospedar por conta própria permite modificar o código-fonte (sob as obrigações do AGPL-3.0), customizar a marca sem pagar pelo nível white-label, e ajustar o comportamento do relay para sua topologia de rede específica.

As compensações que você assume

Hospedar por conta própria não é grátis. A fatura vem em overhead de DevOps, não em dólares por mês. Concretamente:

• Provisionamento e manutenção de servidores: Você precisa de um servidor Linux com IP público (para alcançabilidade do relay), monitoramento, rotação de logs, patching do SO e provavelmente infraestrutura de backup. Conte com 2-4 horas/mês de manutenção em estado estável, mais durante incidentes.
• Configuração de NAT e firewall: O relay precisa ser alcançável da internet em portas específicas (21115-21119 para a configuração padrão do RustDesk). Se você estiver em uma rede NATed, precisa de encaminhamento de portas da borda até o host do relay.
• Gerenciamento de certificados: Se você quer TLS na interface de gerenciamento (você deveria), precisa de Let's Encrypt certbot ou similar. Renovações a cada 60-90 dias, automatizadas via cron.
• Planejamento de capacidade: Um único relay pode lidar com muito tráfego, mas em algum ponto você precisa de um segundo, depois balanceamento de carga. Você agora é uma equipe de infraestrutura.
• Sem suporte do fornecedor: Quando algo quebra às 2 AM, não há linha de suporte. Você depura sozinho ou espera a comunidade acordar.

As três ferramentas sérias

RustDesk (e forks como Tenvo)

Arquiteturalmente a opção mais simples das três. Dois binários: hbbs (rendezvous server, ~30 MB RAM) e hbbr (relay, ~50 MB RAM). Ambos são binários estáticos em Rust sem dependências externas. A configuração é mais ou menos:

# On a Linux VPS with a public IP
wget https://github.com/rustdesk/rustdesk-server/releases/latest/download/rustdesk-server-linux-amd64.zip
unzip rustdesk-server-linux-amd64.zip

# Start hbbs (rendezvous) and hbbr (relay) as services
sudo ./hbbs -r your.public.ip
sudo ./hbbr

# Open ports 21115/tcp, 21116/tcp+udp, 21117/tcp, 21118/tcp, 21119/tcp
sudo ufw allow 21115:21119/tcp
sudo ufw allow 21116/udp

# Point clients at your server: in client settings,
# ID Server = your.public.ip, Relay Server = your.public.ip,
# Public Key = (printed by hbbs on first start, or check id_ed25519.pub)

A pegada de recursos é pequena; um droplet de $5/month da DigitalOcean lida com dezenas de sessões simultâneas. O servidor RustDesk Pro oficial (pago) adiciona console web de administração, logs de auditoria, LDAP/OIDC e recursos estilo broker para implantações maiores.

Apache Guacamole

Arquitetura diferente: Guacamole é uma aplicação web HTML5 sem cliente. Usuários conectam via navegador; o backend do Guacamole (guacd) traduz RDP, VNC e SSH em streams HTML5 canvas/WebSocket. Não há cliente nativo para instalar no lado do usuário, o que é útil em fluxos de suporte onde não se pode instalar software na máquina controladora.

A complexidade operacional é maior que a do RustDesk: Guacamole roda como Java + Tomcat com um banco de dados (MySQL ou Postgres) para gerenciamento de usuários/conexões, mais o daemon guacd. O Docker Compose facilita bastante, mas você estará executando 3-4 containers ao invés de 2 binários.

Guacamole é a escolha certa se você precisa especificamente de acesso via navegador sem software cliente. É a escolha errada se você quer uma ferramenta que resolva NAT traversal entre dois endpoints fora da caixa; Guacamole assume que o servidor Guacamole já consegue alcançar a máquina alvo via RDP/VNC/SSH.

MeshCentral

MeshCentral é uma plataforma de gerenciamento remoto baseada em Node.js criada por Ylian Saint-Hilaire (ex-Intel). Suporta desktop remoto, transferência de arquivos, terminal, console web e uma UI de gerenciamento de frota. Arquiteturalmente é um único app Node + banco de dados (NeDB por padrão, Postgres opcional), acessível via HTTPS.

MeshCentral é mais uma ferramenta de gerenciamento de frota do que um simples relay de desktop remoto — pense nele como RustDesk + inventário de dispositivos + UI web de administração. A configuração é direta (um único npm install + arquivo de configuração), e já foi implantado em produção por organizações de porte, incluindo a Intel.

Onde o MeshCentral deixa a desejar: a UI é densa e não especialmente polida, os clientes móveis são mais fracos que os do RustDesk, e o codec/desempenho para streaming de desktop não é tão otimizado quanto o do RustDesk ou AnyDesk. É melhor quando você quer um console web unificado para uma frota; é menos ideal como ferramenta única de desktop remoto.

Como é na prática um relay RustDesk autohospedado

Passo a passo em um VPS Hetzner CX11 ($4/month) com Ubuntu 24.04:

1. Provisionar o VPS com um IPv4 público. Defina uma senha root forte e habilite autenticação por chave SSH.
2. Abrir o firewall:

   sudo ufw allow OpenSSH
   sudo ufw allow 21115:21119/tcp
   sudo ufw allow 21116/udp
   sudo ufw enable

3. Instalar os binários do servidor RustDesk a partir da página de releases do GitHub. Coloque-os em /opt/rustdesk-server/.
4. Criar arquivos unit systemd para hbbs e hbbr para que reiniciem no boot. O wiki do RustDesk tem unidades de referência; mantemos uma cópia conhecida no nosso help center.
5. Obter a chave pública impressa pelo hbbs no primeiro boot. Distribua-a aos seus clientes junto com o hostname do servidor.
6. Configurar clientes: nas configurações do cliente Tenvo, defina ID Server, Relay Server e Public Key. O cliente agora usa seu relay em vez do nosso.
7. Opcional: terminação TLS via Caddy se quiser servir um console web de administração (RustDesk Pro) na porta 443 com certificados Let's Encrypt auto-renováveis.

Tempo total em um VPS novo: cerca de 30 minutos na primeira vez, 10 minutos se você já fez antes. Manutenção contínua: apt update && apt upgrade semanalmente, monitore os logs do relay, reinicie se houver vazamentos de memória (raro). Para detalhes de implantação no Linux, veja nossa página de plataforma Linux.

Posição da Tenvo sobre autohospedagem

Permitimos que você hospede por conta própria o relay mesmo em planos pagos, se quiser. O cliente do Pro está configurado para falar com nosso relay gerenciado por padrão, mas você pode mudar para seu próprio relay nas configurações a qualquer momento. Não existe uma trava de "enterprise on-prem add-on". Isso é intencional: a licença AGPL-3.0 te dá o direito de autohospedar, e queremos manter isso real.

A maioria dos usuários não se dá ao trabalho. Nosso relay gerenciado simplesmente funciona, tem PoPs globais e está incluído na assinatura base. Se sua história de soberania de dados exige "nenhum relay de terceiros em qualquer ponto do caminho", autohospede. Caso contrário, economize o tempo de DevOps e use o relay gerenciado — é isso que a assinatura compra para você. Para toda a arquitetura de segurança que roda por baixo de qualquer uma das implantações, veja nossa página de segurança.

Quando autohospedar é a escolha errada

• Você é uma equipe pequena sem capacidade de DevOps. O overhead de manutenção é real. Se você não tem alguém cujo trabalho inclua "patchar servidores Linux", autohospedar é um imposto recorrente.
• Você precisa de papelada do fornecedor para compras. Auditores que pedem relatórios SOC 2 não aceitarão "rodamos nosso próprio servidor" como resposta. Serviços gerenciados com certificações formais são mais fáceis nesse caso.
• Você tem apenas 5-20 endpoints. O ponto de equilíbrio entre autohospedar e um plano gerenciado de $7.99/mo envolve centenas de dólares/ano de tempo de DevOps economizado. Em 20 endpoints, o gerenciado é inequivocamente mais barato.
• Você está fazendo isso para economizar em uma única licença. Um VPS de $5/mo mais 2 horas/mês de administração já custa mais do que uma única licença gerenciada por assento, a preços razoáveis de hora de trabalho.

Conclusão

O desktop remoto autohospedado é uma opção real e, para algumas organizações, a escolha correta. RustDesk (e forks como Tenvo) é a história de autohospedagem séria mais fácil; Guacamole é a escolha certa para acesso via navegador; MeshCentral é o generalista de gerenciamento de frota. A compensação é sempre tempo de DevOps versus dólares. Se você tem requisitos de soberania de dados, autohospede. Se você tem $7.99/month e prefere construir produto do que ops, use o relay gerenciado. Veja os preços ou baixe o Tenvo e experimente o fluxo gerenciado primeiro — você sempre pode migrar para autohospedado depois, mudando uma única linha de configuração.

FAQ

Posso hospedar por conta própria o relay e ainda usar a UI/contas do cliente Tenvo?
Sim. Aponte o cliente para seu relay nas configurações. Recursos de conta que dependem do plano de controle da Tenvo (billing, team management) continuam funcionando; apenas o tráfego de sessão passa a usar seu relay.

Que hardware eu preciso para um relay RustDesk autohospedado?
Um VPS pequeno: 1 vCPU, 1 GB RAM, 1 TB/month de largura de banda suporta dezenas de sessões simultâneas. Hetzner CX11, DigitalOcean basic ou AWS t4g.nano funcionam. Em escala, a largura de banda geralmente é a limitação, não a CPU.

O RustDesk autohospedado dá suporte a 2FA / SSO?
O servidor open-source gratuito (hbbs/hbbr) não. O servidor RustDesk Pro (pago, licença separada) adiciona console web, OIDC e logs de auditoria. O tier Pro da Tenvo em managed inclui 2FA pronto para uso.

Posso hospedar o relay na AWS Lightsail / Cloudflare / etc.?
Qualquer provedor com um IPv4 público e a capacidade de abrir portas UDP/TCP customizadas funciona. O proxy padrão da Cloudflare termina TCP apenas na porta 443; você precisaria do Cloudflare Spectrum (pago) ou de um listener TCP dedicado para as portas do RustDesk.

Como autohospedar interage com GDPR?
Se seu relay está na UE e seus dados nunca saem dela, as regras de transferência transfronteiriça do GDPR não se aplicam. Esta é a razão mais importante pela qual implantações do setor público e de saúde na UE escolhem autohospedar.