Escritorio remoto autohospedado: por qué, cómo y qué falla

Autohospedar tu propio relay de escritorio remoto te da soberanía de datos y cero tarifas recurrentes, pero a cambio implica carga operacional de DevOps. Aquí explicamos qué implica ejecutar RustDesk, MeshCentral o Apache Guacamole y cuándo vale la pena autohospedar.
"Escritorio remoto autohospedado" normalmente significa una de dos cosas: alojar tu propia infraestructura de relay/rendezvous para una herramienta como RustDesk, o alojar una plataforma completa de acceso remoto basada en web como Apache Guacamole o MeshCentral. Ambas son aproximaciones válidas; tienen distintos compromisos. Este artículo recorre por qué podrías autohospedar, las tres herramientas serias en este espacio, cómo se ve realmente la sobrecarga operacional y cuándo autohospedar es genuinamente mejor que usar un servicio administrado.
TL;DR: Autohospeda si tienes requisitos estrictos de soberanía de datos (GDPR, industrias reguladas, despliegues internos), si quieres costo cero de licenciamiento recurrente a escala, o si prefieres administrar tu propia infraestructura. No autohospedes si eres un equipo pequeño sin DevOps dedicado, si necesitas certificaciones listas para compra, o si prefieres pagar $7.99/mo para eliminar el problema.
¿Por qué autohospedar?
Soberanía de datos
La razón número uno por la que las organizaciones se autohospedan. Si estás sujeto a GDPR, HIPAA o regulaciones sectoriales (banca alemana, administración pública francesa, contratistas de defensa), enrutar sesiones de escritorio remoto a través de un SaaS de terceros, aunque tenga cifrado fuerte, puede no satisfacer a tus auditores. Autohospedar en infraestructura que posees (o alquilas en una región que controlas) elimina la dependencia de terceros por completo. Nuestro relay administrado termina TLS, así que "el relay es nuestro" es una posición de cumplimiento materialmente más fuerte que confiar esa función a otra entidad.
Despliegues internos
Si tu tráfico de escritorio remoto nunca debe salir de tu red —por ejemplo, un sistema de control industrial aislado de internet, o una LAN hospitalaria con filtrado de salida estricto— un servicio en la nube administrado es estructuralmente inapropiado. Necesitas un relay que viva en tu LAN, accesible solo para tus dispositivos autorizados.
Costo a escala
Para despliegues muy grandes (1000+ endpoints), la facturación por asientos gestionados se acumula. Un relay autohospedado que corre en un VPS de $40/month puede atender miles de sesiones simultáneas si tu ancho de banda lo permite. El punto de equilibrio frente al precio gestionado depende de la herramienta, pero a escala MSP y empresarial, autohospedar gana en costo puro.
Personalización y control
Autohospedar te permite modificar el código fuente (bajo las obligaciones de AGPL-3.0), personalizar la marca sin pagar por la capa white-label y ajustar el comportamiento del relay a tu topología de red específica.
Los compromisos que aceptas
Autohospedar no es gratis. La factura llega en sobrecarga de DevOps, no en dólares por mes. Concretamente:
- Provisionamiento y mantenimiento de servidores: Necesitas un servidor Linux con IP pública (para la alcanzabilidad del relay), monitoreo, rotación de logs, parcheo del SO y, probablemente, infraestructura de backups. Planifica 2-4 horas/mes de mantenimiento en estado estable, más durante incidentes.
- Configuración de NAT y firewall: El relay debe ser alcanzable desde internet en puertos específicos (21115-21119 para la configuración por defecto de RustDesk). Si estás en una red con NAT, necesitas forwarding de puertos desde el borde hasta el host del relay.
- Gestión de certificados: Si quieres TLS en la interfaz de administración (deberías), necesitas certbot de Let's Encrypt o similar. Renovaciones cada 60-90 días, automatizadas con cron.
- Planificación de capacidad: Un solo relay puede manejar mucho tráfico, pero en algún punto necesitarás un segundo y luego balanceo de carga. Ahora eres un equipo de infraestructura.
- Sin soporte del proveedor: Cuando algo falla a las 2 AM, no hay línea de soporte. Lo depuras tú o esperas a que la comunidad responda.
Las tres herramientas serias
RustDesk (y forks como Tenvo)
La más simple arquitectónicamente de las tres. Dos binarios: hbbs (servidor de rendezvous, ~30 MB RAM) y hbbr (relay, ~50 MB RAM). Ambos son binarios Rust estáticos sin dependencias externas. La configuración es más o 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)La huella de recursos es mínima, un droplet DigitalOcean de $5/month maneja docenas de sesiones simultáneas. El servidor RustDesk Pro oficial (de pago) añade consola web de administración, logs de auditoría, LDAP/OIDC y funcionalidades tipo broker para despliegues más grandes.
Apache Guacamole
Arquitectura distinta: Guacamole es una aplicación web HTML5 sin cliente. Los usuarios se conectan vía navegador; el backend de Guacamole (guacd) traduce RDP, VNC y SSH a flujos HTML5 canvas/WebSocket. No hay cliente nativo que instalar en la máquina de control, lo cual es útil para flujos de soporte donde no puedes instalar software en el equipo controlador.
La complejidad operacional es mayor que RustDesk: Guacamole corre como Java + Tomcat con una base de datos (MySQL o Postgres) para la gestión de usuarios/conexiones, más el daemon guacd. El despliegue con Docker Compose mitiga mucho esto, pero estarás ejecutando 3-4 contenedores en vez de 2 binarios.
Guacamole es la elección correcta si quieres acceso basado en navegador sin software cliente. Es la elección equivocada si necesitas que la herramienta resuelva traversal de NAT entre dos endpoints por sí sola; Guacamole asume que el servidor Guacamole ya puede alcanzar la máquina objetivo vía RDP/VNC/SSH.
MeshCentral
MeshCentral es una plataforma de gestión remota basada en Node.js creada por Ylian Saint-Hilaire (antes en Intel). Soporta escritorio remoto, transferencia de archivos, terminal, consola web y una UI de gestión de flota. Arquitectónicamente es una sola app Node + base de datos (NeDB por defecto, Postgres opcional), accesible por HTTPS.
MeshCentral es más una herramienta de gestión de flotas que un simple relay de escritorio remoto; piénsalo como RustDesk + inventario de dispositivos + UI web administrativa. La instalación es directa (un único npm install + archivo de configuración), y ha sido desplegada en producción por organizaciones de cierto tamaño, incluida Intel.
Donde MeshCentral se queda corto: la UI es densa y no especialmente pulida, los clientes móviles son más débiles que los de RustDesk, y el códec/rendimiento para streaming de escritorio no está tan optimizado como RustDesk o AnyDesk. Es mejor cuando quieres una consola administrativa web unificada para una flota; menos ideal como herramienta de escritorio remoto de un solo propósito.
Cómo se ve realmente un relay RustDesk autohospedado
Paso a paso en un VPS Hetzner CX11 ($4/month) con Ubuntu 24.04:
- Provisiona el VPS con una IPv4 pública. Establece una contraseña root fuerte y habilita autenticación por clave SSH.
- Abre el firewall:
sudo ufw allow OpenSSH sudo ufw allow 21115:21119/tcp sudo ufw allow 21116/udp sudo ufw enable - Instala los binarios del servidor RustDesk desde la página de releases de GitHub. Colócalos bajo
/opt/rustdesk-server/. - Crea unidades systemd para
hbbsyhbbrpara que se reinicien al arrancar. La wiki de RustDesk tiene units de referencia; mantenemos una copia de confianza en nuestro centro de ayuda. - Obtén la clave pública que imprime hbbs en el primer arranque. Distribúyela a tus clientes junto con el hostname del servidor.
- Configura los clientes: en la configuración del cliente Tenvo, establece ID Server, Relay Server y Public Key. El cliente ahora usa tu relay en lugar del nuestro.
- Opcional: terminación TLS con Caddy si quieres servir una consola web de administración (RustDesk Pro) en 443 con certificados Let's Encrypt que se renuevan automáticamente.
Tiempo total en un VPS nuevo: alrededor de 30 minutos la primera vez, 10 minutos si ya lo hiciste antes. Mantenimiento continuo: apt update && apt upgrade semanalmente, vigila los logs del relay, reinicia si hay fugas de memoria (raro). Para detalles de despliegue en Linux véase nuestra página de plataforma Linux.
La posición de Tenvo sobre el autohospedaje
Te permitimos autohospedar el relay incluso en las capas de pago, si así lo quieres. El cliente Pro está configurado para hablar con nuestro relay administrado por defecto, pero puedes cambiarlo a tu propio relay en la configuración en cualquier momento. No hay un "add-on empresarial on-prem" que te bloquee. Esto es intencional: la licencia AGPL-3.0 te da el derecho a autohospedar, y queremos que eso sea real.
La mayoría de los usuarios no se molesta. Nuestro relay administrado simplemente funciona, tiene PoPs globales y está incluido en la suscripción base. Si tu historia de soberanía de datos requiere "ningún relay de terceros en el camino", autohospeda. Si no, ahórrate el tiempo de DevOps y usa el relay administrado; para eso sirve la suscripción. Para la arquitectura completa de seguridad que opera debajo de cualquiera de los despliegues, véase nuestra página de seguridad.
Cuándo autohospedar es la decisión equivocada
- Eres un equipo pequeño sin capacidad de DevOps. La sobrecarga de mantenimiento es real. Si no tienes a alguien cuya descripción incluya "aplica parches a servidores Linux", autohospedar es un impuesto recurrente.
- Necesitas documentación del proveedor para compras. Auditores que piden informes SOC 2 no aceptarán "ejecutamos nuestro propio servidor" como respuesta. Los servicios administrados con certificaciones formales son más sencillos en este aspecto.
- Sólo tienes 5-20 endpoints. El punto de equilibrio entre autohospedar y un plan administrado de $7.99/mo requiere cientos de dólares/año en ahorro de tiempo de DevOps. Con 20 endpoints, lo gestionado es inequívocamente más barato.
- Lo haces por ahorro en un solo asiento. Un VPS de $5/month más 2 horas/mes de administración a cualquier tarifa razonable ya cuesta más que una sola licencia gestionada.
Conclusión
El escritorio remoto autohospedado es una opción real, y para algunas organizaciones es la correcta. RustDesk (y forks como Tenvo) es la historia de autohospedaje más sencilla; Guacamole es la opción adecuada para acceso basado en navegador; MeshCentral es el generalista de gestión de flotas. El intercambio siempre es tiempo de DevOps versus dinero. Si tienes requisitos de soberanía de datos, autohospeda. Si tienes $7.99/month y prefieres construir producto que operar infraestructura, usa el relay administrado. Ver precios o descargar Tenvo y prueba primero el flujo administrado; siempre puedes migrar a autohospedado más adelante cambiando una línea de configuración.
FAQ
¿Puedo autohospedar el relay y seguir usando la UI / cuentas del cliente Tenvo?
Sí. Apunta el cliente a tu relay en la configuración. Las funciones de cuenta que dependen del plano de control de Tenvo (facturación, gestión de equipos) siguen funcionando; solo el tráfico de sesión se mueve a tu relay.
¿Qué hardware necesito para un relay RustDesk autohospedado?
Un VPS pequeño: 1 vCPU, 1 GB RAM, 1 TB/mes de ancho de banda maneja docenas de sesiones simultáneas. Hetzner CX11, DigitalOcean basic o AWS t4g.nano funcionan. A escala, el ancho de banda suele ser la limitación, no la CPU.
¿El RustDesk autohospedado soporta 2FA / SSO?
El servidor gratuito y de código abierto (hbbs/hbbr) no lo hace. El servidor RustDesk Pro (de pago, licencia separada) añade consola web, OIDC y logs de auditoría. La capa Pro de Tenvo en gestionado incluye 2FA por defecto.
¿Puedo alojar el relay en AWS Lightsail / Cloudflare / etc.?
Cualquier proveedor con una IPv4 pública y la posibilidad de abrir puertos UDP/TCP personalizados funciona. El proxy estándar de Cloudflare termina TCP en el puerto 443 solamente; necesitarías Cloudflare Spectrum (de pago) o un listener TCP dedicado para los puertos de RustDesk.
¿Cómo interactúa el autohospedaje con GDPR?
Si tu relay está en la UE y tus datos nunca salen de ella, no aplican las reglas de transferencia transfronteriza de GDPR. Esta es la razón principal por la que despliegues del sector público y de salud en la UE eligen autohospedar.
¿Listo para probarlo?
Gratis para 30 dispositivos, sin tarjeta de crédito. En funcionamiento y conectado en dos minutos.