rustdesk docker: guía para servidor RustDesk en contenedores

Estás intentando autoalojar RustDesk sin lidiar con compilaciones manuales, dependencias problemáticas o imágenes VM frágiles. Esta guía muestra cómo ejecutar una pila de servidor RustDesk lista para producción con Docker y Docker Compose, para que puedas gestionar actualizaciones, respaldos y escalado como personal de operaciones —no como un aficionado.

¿Por qué usar Docker para RustDesk?

Los contenedores ofrecen dos beneficios inmediatos para una pila de acceso remoto autoalojada: despliegues reproducibles y aislamiento. En lugar de compilar hbbs/hbbr localmente o ejecutar paquetes específicos de plataforma, obtienes una imagen Docker, montas un volumen persistente y arrancas el servicio. Eso simplifica las actualizaciones, CI/CD y migraciones de host. Si ya ejecutas otros servicios en contenedores (NGINX, certbot, monitoring), añadir RustDesk de esta forma mantiene tu stack consistente.

Cuándo no contenerizar: si necesitas binarios parcheados a medida o integración profunda con el kernel para un relay de muy alto rendimiento, una instalación nativa puede ser preferible. También, si requieres un SLA empresarial oficialmente soportado por el proveedor, verifica si ese proveedor admite contenedores.

Componentes del servidor de RustDesk — resumen breve

RustDesk divide el rol de servidor en al menos dos componentes:

• hbbs — servidor de ID/señalización. Maneja el registro y el encuentro (rendezvous) de los clientes.
• hbbr — servidor de retransmisión (si la conexión directa a través de NAT falla). Reenvía el tráfico entre pares.

En producción normalmente ejecutas ambos. Un host ligero puede correr los dos servicios; en despliegues más grandes se separan, se colocan instancias hbbr detrás de un balanceador de carga y se añade autoscaling para la capacidad de relay.

Inicio rápido: ejemplo de despliegue con Docker Compose

Requisitos: Ubuntu 22.04 LTS (o cualquier Linux con Docker Engine 20.10+), Docker Compose v2.x, un nombre de dominio (ejemplo: rustdesk.example.com). Asigna al menos 512 MB de RAM para un servidor de prueba pequeño; 1 GB+ recomendado para un relay que maneje múltiples sesiones activas.

Abajo hay un ejemplo práctico de Docker Compose que ejecuta hbbs y hbbr en servicios separados, monta datos persistentes y publica los puertos estándar de RustDesk. Antes de ejecutarlo, revisa las etiquetas de imagen oficiales rustdesk/rustdesk-server para el tag estable más reciente y reemplaza rustdesk/rustdesk-server:latest si prefieres una versión fijada.

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

Explicación:

• Ejecutamos hbbs en los puertos TCP/UDP 21115 y hbbr en 21116 — estos son los valores predeterminados comunes para las compilaciones del servidor RustDesk. Confirma el mapeo de puertos de la imagen que uses (algunas compilaciones comunitarias usan defaults diferentes).
• Los volúmenes persistentes ./data/hbbs y ./data/hbbr conservan tus datos de registro y relay a través de reinicios.
• Usa restart: unless-stopped para resiliencia básica; en producción intégralo con las políticas de reinicio de tu plataforma de orquestación.

Exponer de forma segura: TLS, proxy inverso y firewall

El tráfico de señalización y retransmisión de RustDesk puede protegerse con TLS y reglas de firewall estándar. Hay dos enfoques comunes:

1. TLS directo con un proxy delante de hbbs (recomendado para la gestión de certificados a nivel web).
2. Mantener hbbr como un relay TCP/UDP sin terminación y asegurar la red del host (usar ufw/nftables) mientras se protege hbbs con TLS.

La mayoría de las configuraciones usan NGINX o Traefik para terminar TLS y reenviar tráfico a hbbs. Ejemplo de bloque 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;
}

Usa certbot (Let's Encrypt) o tu CA para obtener certificados. Si tu relay (hbbr) corre en UDP/TCP público, expón esos puertos directamente y limita el acceso en el firewall a los rangos IP esperados, o pon los nodos relay en una subred privada detrás de un balanceador de carga.

DNS, clientes y atravesamiento de NAT

Apunta un registro A de DNS (por ejemplo, rustdesk.example.com) a la IP pública de tu servidor. En el cliente RustDesk, establece la dirección del servidor a ese dominio (para búsqueda de ID y relay). Los clientes usan el servidor de ID para el encuentro; si ambos clientes están detrás de NAT restrictivos, hbbr reenviará la sesión a través de tu servidor relay.

Si controlas máquinas cliente en una LAN, puedes ejecutar un DNS interno o distribuir un archivo de configuración que apunte a los clientes hacia la IP interna de hbbs para conexiones locales más rápidas.

Escalado y recomendaciones de recursos

¿Cuánta CPU/RAM necesita un relay? Depende de las sesiones concurrentes y el tipo de sesión:

• Servidor de prueba pequeño: 1 vCPU, 512 MB RAM — un puñado de conexiones inactivas.
• Relay de producción (uso ligero): 2 vCPU, 1–2 GB RAM — docenas de sesiones concurrentes.
• Relay de alto rendimiento: 4+ vCPU, 4+ GB RAM y capacidad de red acorde al ancho de banda esperado (por ejemplo, 100+ Mbps).

Recomendamos autoscalar instancias hbbr detrás de un balanceador de carga si esperas picos (control remoto con mucha media, screen sharing). Usa orquestación de contenedores (Kubernetes, Docker Swarm) o escalado horizontal simple con un balanceador TCP/UDP (haproxy, cloud LB) que preserve las IPs cliente.

Respaldos, actualizaciones y fijado de versiones

Siempre monta volúmenes persistentes para los datos y respáldalos regularmente. Un script mínimo de respaldo:

# 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 actualizaciones, fija la imagen Docker con un tag en lugar de :latest. Ejecuta pruebas en staging al actualizar la imagen del servidor. Ejemplo de flujo:

1. Descarga la nueva imagen: docker pull rustdesk/rustdesk-server:1.3.0 (ejemplo).
2. Levanta un contenedor de prueba con los mismos volúmenes y ejecuta pruebas de humo.
3. Programa una ventana de mantenimiento y reemplaza los contenedores en los hosts de producción.

Solución de problemas y errores comunes

Empieza por los logs: docker logs rustdesk-hbbs y docker logs rustdesk-hbbr. Problemas típicos:

• Los clientes no pueden registrarse: verifica que hbbs sea accesible en el dominio y que el TLS sea válido.
• Las sesiones caen al relay pero el rendimiento es pobre: revisa CPU/memoria y red del host relay. Los paquetes de relay suelen ser UDP; asegúrate de que UDP esté permitido en tu firewall y en el security group de la nube.
• Los clientes muestran versiones incompatibles: usa versiones compatibles de cliente/servidor RustDesk. Si fijas la imagen del servidor, asegúrate de que los clientes no estén usando características de protocolo obsoletas.

Si el atravesamiento de NAT falla de forma consistente para muchos clientes, el problema suele ser NAT simétrico o firewalls empresariales. En esos casos, confía en los relays hbbr y monitoriza latencia/ancho de banda para asegurar una UX aceptable.

Consideraciones de seguridad

El autoalojamiento traslada la responsabilidad a usted. Pasos clave:

• Termina TLS en un proxy inverso y usa cifrados fuertes. Obtén certificados de Let's Encrypt o de una CA de confianza.
• Endurece el host: abre solo los puertos necesarios, habilita actualizaciones de seguridad automáticas en el SO y usa un firewall (ufw/nftables).
• Limita el acceso a interfaces administrativas y monitoriza logs por intentos de fuerza bruta. Considera segmentación de red; coloca los nodos relay en una subred separada si es posible.

Si quieres una discusión más amplia sobre cómo asegurar el acceso remoto, consulta nuestros artículos sobre seguridad de escritorio remoto y las compensaciones prácticas en escritorio remoto autoalojado.

Cuándo es mejor un proveedor gestionado

Autoalojar con Docker ofrece control y privacidad, pero si necesitas un SLA totalmente gestionado, funciones empresariales oficiales (gestión de usuarios, facturación centralizada) o integración lista para usar con Windows AD, proveedores comerciales como TeamViewer o AnyDesk pueden ser mejores opciones. Sé honesto sobre las compensaciones: el autoalojamiento ahorra en tarifas recurrentes por asiento y da localidad de los datos, pero consume tiempo de operaciones para mantener, monitorizar y asegurar.

Siguientes pasos y referencias

Lista de verificación para pasar del laboratorio a producción:

1. Elige un host con Docker Engine 20.10+ y Docker Compose v2.x.
2. Crea volúmenes persistentes y un job de respaldo diario.
3. Fija la imagen del servidor y valida las actualizaciones en staging.
4. Termina TLS con NGINX/Traefik y obtén certificados de Let's Encrypt.
5. Monitoriza los hosts relay y escala hbbr cuando CPU o ancho de banda alcancen umbrales de salud.

¿Quieres una descarga limpia para comparar lado a lado con el enfoque en contenedores? Descarga los binarios o instaladores de Tenvo en /download y revisa nuestra página /pricing para opciones de despliegue. Si prefieres seguir una guía más amplia de acceso remoto, nuestra guía de configuración de acceso remoto cubre red, autenticación y usabilidad entre herramientas.

Ejecutar RustDesk bajo Docker es un enfoque sólido y mantenible para la mayoría de quienes se autoalojan: simplifica actualizaciones e encaja bien con la infraestructura de contenedores existente. Si necesitas una copia del archivo compose o ayuda para adaptar esto a Kubernetes, vuelve y te proporcionaré un manifiesto K8s y un ejemplo de chart Helm.

¿Listo para probarlo? Descarga los clientes necesarios o imágenes de prueba desde /download y pon tu servidor RustDesk en contenedores en funcionamiento hoy mismo.