Skip to content
Back to BlogGuía

Escritorio remoto autoalojado: Guía completa 2026 (RustDesk + GoDesk Relay)

GoDesk Editorial Team12 min de lectura
Escritorio remoto autoalojado: Guía completa 2026 (RustDesk + GoDesk Relay)

¿Quieres un escritorio remoto donde tu tráfico nunca pase por el servidor de un proveedor? Esta guía explica cómo autoalojar el relay de extremo a extremo en un VPS de $5/mes: qué instalar, cómo endurecerlo y cómo manejar los modos de fallo que la documentación no cubre.

Para la mayoría de usuarios, el relay alojado por el proveedor (de TeamViewer, de AnyDesk, de GoDesk) está bien. El cifrado de extremo a extremo significa que el relay solo ve texto cifrado — no puede leer los fotogramas de pantalla, las pulsaciones de teclas ni los archivos. Pero "bien" no es "ideal" si tienes una de estas restricciones:

  • Cumplimiento: industria regulada donde los datos no deben transitar por infraestructura de terceros (legal, defensa, ciertos sectores de salud).
  • Soberanía: no quieres que nadie recopile los metadatos de acceso remoto (quién se conectó a qué, cuándo y por cuánto tiempo).
  • Costo a escala: si gestionas más de 100 dispositivos a través de un relay, las tarifas del proveedor se acumulan — un relay autoalojado en un VPS de $5/mes maneja miles de sesiones.
  • Redes aisladas o restringidas: el relay del proveedor no es accesible desde tu entorno.

Si cualquiera de esos puntos te describe, esta guía recorre el autoalojamiento de extremo a extremo en un VPS básico. La pila de referencia es la de RustDesk hbbs + hbbr, a la que tanto clientes GoDesk como RustDesk pueden conectarse. Tiempo total de configuración: unos 30 minutos incluyendo TLS.

Qué vas a construir

Dos servicios:

  • hbbs (servidor de rendezvous): maneja el apretón de manos inicial. Ambos clientes se conectan brevemente para descubrirse, intercambiar claves públicas y determinar si P2P directo es posible. Escucha en TCP/UDP 21115-21117.
  • hbbr (servidor de relay): si el P2P directo falla (NAT, firewall), el tráfico pasa por el relay. Escucha en TCP 21117 (y UDP en algunos escenarios).

El relay solo entra en juego cuando el P2P no funciona — lo habitual en escenarios de consumo por culpa del NAT, aunque es raro en la misma LAN. Así que incluso con un relay autoalojado, solo pagas ancho de banda del VPS por las sesiones que lo necesitan.

Paso 1: Elige un VPS

El ancho de banda es el recurso principal. CPU y RAM son mínimos (el relay solo reenvía bytes). Opciones razonables en 2026:

  • Hetzner CX22 (€4/mo, 2 vCPU, 4 GB RAM, 20 TB de ancho de banda, centros de datos en la UE) — la mejor relación precio-ancho de banda.
  • DigitalOcean Basic Droplet ($6/mo, 1 vCPU, 1 GB, 1 TB de ancho de banda) — buena experiencia de usuario, regiones US/EU.
  • OVH VPS Starter (€3.50/mo, 2 vCPU, 2 GB, ancho de banda sin límites) — mejor para escenarios de alto consumo de ancho de banda.
  • Hetzner Storage Box — NO es un VPS, se menciona porque algunos lectores lo preguntan. No funcionará para esto; necesitas un servidor real.

Elige una región cercana a donde estarán los clientes — esto importa para la latencia, ya que el tráfico del relay está limitado por el ida y vuelta.

Paso 2: Prepara el servidor

Levanta un VPS nuevo con Ubuntu 22.04 o Debian 12. Conéctate 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

No omitas el firewall. La configuración por defecto de RustDesk expone solo los puertos necesarios; el resto debe estar bloqueado.

Paso 3: Ejecuta hbbs + hbbr con Docker

Crea /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

Reemplaza your-server.example.com por el nombre de host real. Inícialo:

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

Deberías ver que hbbs imprime una clave pública al iniciarse por primera vez — guárdala desde los logs (id_ed25519.pub en el volumen data) porque los clientes la usan para verificar que se están conectando a TU relay y no a un man-in-the-middle.

Paso 4: Configura DNS

Apunta un registro A para relay.yourdomain.com a la IP del VPS. RustDesk también acepta una IP directa, pero un nombre de host es más flexible si alguna vez migras.

Paso 5: Apunta los clientes al relay autoalojado

Esta es la parte que la mayoría de guías pasa por alto. Cada cliente necesita tres valores de configuración:

  • Servidor de ID = relay.yourdomain.com:21116
  • Servidor de relay = relay.yourdomain.com:21117
  • Clave pública = el contenido de data/id_ed25519.pub de tu VPS

En Windows / macOS / Linux:

  1. Abre el cliente GoDesk o RustDesk.
  2. Configuración → Red → Servidor ID/Relay.
  3. Introduce los tres valores anteriores. Guarda.
  4. Reinicia el cliente.

El indicador de estado debería volverse verde en unos segundos, indicando que está registrado en tu relay. Si permanece rojo, verifica las reglas del firewall y que la clave pública coincida exactamente.

Paso 6: Añadir TLS (opcional pero recomendado)

El protocolo por defecto de RustDesk ya está cifrado en la capa de aplicación (la clave pública que copiaste forma parte de eso). Añadir TLS encima suma una segunda capa y protege contra algunos ataques pasivos en la red. La configuración implica un reverse proxy (nginx o Caddy) delante de los puertos del relay.

Versión con Caddy (más simple):

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

Caddy emite automáticamente el certificado de Let's Encrypt. Actualiza los clientes para usar el puerto 443 con TLS activado.

Paso 7: Haz copia de seguridad de las claves

El directorio data/ contiene el par de claves del servidor de rendezvous. Si lo pierdes, cada cliente deberá reconfigurarse con la nueva clave pública. Haz una copia de seguridad:

# 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/

Almacena la copia en un lugar offline. Si el VPS queda comprometido, quieres poder levantar uno nuevo con las mismas claves para que los clientes existentes sigan funcionando sin reconfiguración.

Modos de fallo que la documentación no menciona

Fallo 1: Los clientes no pueden alcanzar el relay. El 90% de las veces es el firewall. Revisa ufw status, confirma que el grupo de seguridad del proveedor en la nube también permita los mismos puertos, y ejecuta nc -vz relay.yourdomain.com 21116 desde un cliente para verificar la conectividad.

Fallo 2: El P2P siempre cae al relay. NAT simétrico o firewalls corporativos estrictos obligan a que todo pase por el relay. Esto es normal — el rendimiento es bueno pero aplica medición de ancho de banda. Usa relay.yourdomain.com con un plan de VPS de alto ancho de banda.

Fallo 3: El proceso del relay muere y no se reinicia. La opción de Docker restart: unless-stopped cubre la mayoría de casos. Añade docker compose ps a un cron que te alerte sobre contenedores faltantes.

Fallo 4: El certificado SSL expira. Si usas Caddy, esto es automático — renueva 30 días antes del vencimiento. Si usas nginx + certbot, configura un cron para renovar. certbot.eff.org tiene la guía oficial.

Cálculo del ancho de banda

La calidad importa. Aproximación rápida:

  • Baja calidad (trabajo con mucho texto): ~50 KB/s = 180 MB/hora
  • Media (trabajo de oficina general): ~200 KB/s = 720 MB/hora
  • Alta (video, diseño): ~1 MB/s = 3.6 GB/hora

Un Hetzner CX22 con 20 TB/mes de ancho de banda soporta aproximadamente 5,500 horas de sesiones de alta calidad al mes — mucho más de lo que usará cualquier individuo o equipo pequeño. El límite de 20 TB es más relevante para organizaciones con cientos de dispositivos.

Opción preconstruida: el relay autoalojable de GoDesk

Todo lo anterior es la vía manual usando el stack de código abierto de RustDesk. GoDesk publica un bundle autoalojable del mismo stack hbbs/hbbr con valores por defecto sensatos ya preconfigurados. Si no quieres gestionar archivos de Docker compose, consulta nuestra guía de autoalojamiento — misma arquitectura, con un script de instalación de un solo comando que envuelve los pasos anteriores.

Cuándo NO autoalojar

El autoalojamiento añade carga operativa: monitorización, copias de seguridad de claves, actualizaciones de SO, renovación de certificados. Si tu caso de uso es "quiero acceder remotamente a mi PC doméstico", el relay alojado por el proveedor (el plan gratuito de GoDesk ofrece 5 GB/mes) es mucho menos trabajo que mantener tu propio VPS para siempre.

Autoaloja si tienes una razón real — cumplimiento, soberanía, escala. Evítalo si la única motivación es "sería genial"; la carga operativa te alcanzará tarde o temprano.

Resumen

  1. VPS de $5/mes en la región que prefieras.
  2. Docker + UFW + los contenedores hbbs/hbbr de RustDesk.
  3. Registro A de DNS apuntando al VPS.
  4. Tres valores de configuración en cada cliente (Servidor ID, Servidor de relay, clave pública).
  5. Haz copia de seguridad de las claves.
  6. Opcional: TLS mediante Caddy/nginx.

Tiempo de configuración de extremo a extremo: 30 minutos. Mantenimiento continuo: mínimo. El resultado: escritorio remoto donde tu tráfico nunca transita por infraestructura de terceros.

Para más información del lado de GoDesk — documentación de autoalojamiento, el panorama open-source, o el cliente.