Escritorio remoto autoalojado: la guía honesta de 2026

Busca "self-hosted remote desktop" y encontrarás una docena de tutoriales que terminan en docker compose up -d. La instalación es la parte fácil, y de verdad lleva 30 minutos. Esta guía la cubre por completo —y luego aborda la parte que decide si debiste haberlo hecho: cuánto cuesta mantenerlo vivo una vez que termina el tutorial.

La respuesta corta

Autoalójalo cuando un requisito te obligue. Usa un relay gestionado cuando nada te obligue. Suena simplista, así que aquí está la prueba real:

• Autoalójalo si: una obligación de cumplimiento escrita dice que el tráfico de sesión no debe transitar por infraestructura de terceros; operas redes aisladas o de acceso restringido donde un relay externo es inalcanzable; o las reglas de residencia de datos nombran una jurisdicción en la que debes permanecer.
• Usa un relay gestionado si: tu razón es cualquier versión de "Prefiero administrarlo yo mismo." Eso es una preferencia válida, pero también constituye un trabajo operativo permanente —revisa la factura más abajo antes de comprometerte.

Vale aclarar qué estás comparando, porque no son dos productos distintos. Tenvo es AGPL-3.0 y el relay gestionado ejecuta la misma arquitectura hbbs/hbbr que instala esta guía. La elección es quién opera la máquina, no qué hace el software.

Primero: qué puede ver realmente un relay

Esto importa antes que nada, porque suele ser la razón para optar por el autoalojamiento —y normalmente se describe mal.

En una conexión peer-to-peer directa, la sesión va de extremo a extremo entre los dos dispositivos. Cuando no se puede establecer una conexión directa —NAT simétrico, firewalls corporativos estrictos— la sesión se relaya y TLS termina en el relay. Quien opere ese relay está, por tanto, en posición de ver el tráfico relayed. No vamos a decir otra cosa sobre el nuestro.

Eso es una propiedad del protocolo, no de quién paga el servidor. Ejecutar el relay tú mismo no cifra nada que un relay de proveedor no cifre; cambia quién ocupa esa posición. Si tu respuesta a "quién puede ocuparla" está escrita en una obligación de cumplimiento, el autoalojamiento es la respuesta correcta y el resto de esta guía es para ti. Si no está escrito en ningún lado, te estás asignando un trabajo operativo para resolver un problema que no tienes.

Qué estás construyendo

Dos servicios:

• hbbs (rendezvous server): maneja el handshake inicial. Ambos clientes se conectan brevemente para descubrirse, intercambiar claves públicas y determinar si el P2P directo es posible. Escucha en TCP/UDP 21115-21117.
• hbbr (relay server): transporta la sesión cuando falla el P2P directo. Escucha en TCP 21117 (y UDP para algunos escenarios).

El relay solo se activa cuando P2P no funciona —común en NAT de consumidor, raro en una configuración LAN local. Así que incluso autoalojado, solo pagas ancho de banda del VPS por las sesiones que realmente necesitan relaying.

Paso 1: Elige un VPS

El recurso que importa es el ancho de banda. CPU y RAM son mínimos, ya que el relay reenvía bytes más que procesarlos.

• Hetzner CX22 (€4/mo, 2 vCPU, 4 GB RAM, 20 TB bandwidth, EU data centres) — mejor relación precio/anchobanda.
• DigitalOcean Basic Droplet ($6/mo, 1 vCPU, 1 GB, 1 TB bandwidth) — buena experiencia, regiones US/EU.
• OVH VPS Starter (€3.50/mo, 2 vCPU, 2 GB, unmetered bandwidth) — mejor para escenarios de alto consumo de ancho de banda.

Elige una región cercana a los clientes que se conectarán. El tráfico de relay está limitado por la ida y vuelta, así que esto es la palanca más importante que tienes sobre la latencia percibida —y, como se cubre más abajo, lo que peor resuelve un único VPS.

Paso 2: Prepara el servidor

Levanta un VPS Ubuntu 22.04 fresco o Debian 12. Haz 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 te saltes el firewall. La configuración por defecto expone solo los puertos necesarios; todo lo demás debe estar bloqueado.

Paso 3: Ejecuta hbbs + hbbr con Docker

Crea /opt/tenvo-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 con el hostname real, luego arráncalo:

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

hbbs imprime una clave pública al iniciarse por primera vez. Guárdala desde los logs (id_ed25519.pub en el volumen data) — los clientes la usan para verificar que se conectan a tu relay y no a un impostor.

Paso 4: Configura DNS

Apunta un registro A para relay.yourdomain.com a la IP del VPS. Una IP directa también funciona, pero un hostname es mucho más manejable si migras en el futuro.

Paso 5: Apunta los clientes a tu relay

La parte que la mayoría de las guías pasa por alto. Cada cliente necesita tres valores:

• ID server = relay.yourdomain.com:21116
• Relay server = relay.yourdomain.com:21117
• Public key = el contenido de data/id_ed25519.pub en tu VPS

En Windows, macOS y Linux:

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

El indicador de estado debería ponerse verde en unos segundos. Si queda en rojo, verifica las reglas del firewall y que la clave pública coincida exactamente —una nueva línea final suele ser la culpable.

Paso 6: Añade TLS

Coloca un reverse proxy delante de los puertos del relay. Caddy es el camino más corto:

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

Caddy emite y renueva el certificado Let's Encrypt por ti. Actualiza los clientes para usar el puerto 443 con TLS activado —esto además te permite pasar por firewalls salientes restrictivos que solo permiten 443.

Paso 7: Haz backup de las claves

El directorio data/ contiene el par de claves del servidor rendezvous. Si lo pierdes, tienes que reconfigurar cada cliente con una nueva clave pública —a mano, en cada máquina.

# Local backup
rsync -avz vps:/opt/tenvo-relay/data/ ~/tenvo-relay-backup-$(date +%Y%m%d)/
# OR copy the two key files
scp vps:/opt/tenvo-relay/data/id_ed25519* ~/tenvo-keys/

Almacénalo fuera de línea. Si el VPS se ve comprometido en algún momento, querrás reconstruir en una máquina fresca con las mismas claves para que los clientes existentes sigan funcionando sin cambios.

Los modos de fallo que las guías omiten

Los clientes no pueden alcanzar el relay. Casi siempre es el firewall. Revisa ufw status, verifica que el grupo de seguridad del proveedor cloud permite los mismos puertos, y ejecuta nc -vz relay.yourdomain.com 21116 desde un cliente para confirmar alcance.

Todo cae al relay. NAT simétrico y firewalls corporativos estrictos fuerzan cada sesión a través del relay. El rendimiento se mantiene, pero tu factura de ancho de banda pasa a ser la historia completa en lugar de la excepción.

El relay muere y no vuelve. restart: unless-stopped de Docker cubre los casos comunes. No cubre disco lleno, un OOM kill o un kernel panic —para eso necesitas monitorización que notifique a alguien, y ese alguien eres tú.

El certificado expira. Automático con Caddy. Con nginx + certbot es un trabajo cron que tienes que recordar que te pertenece; certbot.eff.org tiene la guía oficial.

La factura que las guías no te muestran

El VPS de €4 es la línea más barata en la factura, y citarlo como el costo del autoalojamiento es la misma jugada que citar el precio de compra de un coche como el costo de conducirlo. El resto:

• Estás de guardia para tu propio relay. Cuando falle a las 2 a. m., el acceso remoto es lo que ya no tendrás para arreglarlo.
• Parcheo del sistema operativo, para siempre. Una máquina pública en Internet es una máquina de la que eres responsable de mantener actualizada.
• Custodia de claves. Pierde data/ y reconfiguras cada cliente a mano. Ese backup ahora es algo que debes verificar de verdad, no solo programar.
• Renovación de certificados. Automática hasta el día en que no lo sea.
• Una región, una máquina. Un único VPS es una localización y sin conmutación por error. Los clientes al otro lado del mundo pagan eso en latencia; si la máquina cae, todos caen.

El ancho de banda es el único costo que es genuinamente fácil de estimar. Cifras aproximadas por sesión relayed:

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

Los 20 TB/mes de un Hetzner CX22 cubren aproximadamente 5,500 horas de sesiones relayed de alta calidad. Para un individuo o un equipo pequeño ese techo rara vez es la limitante —que es precisamente el punto. Si el ancho de banda era la razón por la que ibas a autoalojar, no es una buena razón. Las limitantes reales son las cuatro viñetas anteriores.

Lo que hace el relay gestionado en su lugar

Misma arquitectura, diferente operador. La flota de relays es multiregión en lugar de un VPS, así que los clientes se conectan a algo cerca de ellos en vez de cerca de ti. Está monitorizada por personas cuyo trabajo es ese. La custodia de claves, el parcheo y la renovación de certificados dejan de ser tu problema. Cuando algo falla a las 2 a. m., la persona notificada no eres tú.

Eso es lo que compra la suscripción: Free at $0, Lite at $2.99/mo, Pro at $7.99/mo — consulta pricing para ver qué incluye cada nivel, o the business plans si despliegas en un equipo. Frente a un VPS de €4 y tu propia rotación de guardias, la aritmética no está a tu favor para la mayoría de la gente.

Cuando el autoalojamiento es realmente la decisión correcta

Es la decisión correcta cuando una obligación lo exige: trabajo regulado donde el tráfico no puede cruzar infraestructura de terceros, redes aisladas o restringidas donde un relay externo es inalcanzable, o reglas de residencia que te atan a una jurisdicción. En esos casos el costo operativo no es un overhead, es el requisito, y esta guía es exactamente lo que necesitas.

También importa que la opción exista. Tenvo es AGPL-3.0 y la pila del servidor es open source, así que el relay gestionado es una comodidad que compras y no un cerrojo que aceptas. Si alguna vez dejamos de ser útiles, la salida es la guía de arriba —ese es el sentido de publicarla. Mira cómo se compara la build gestionada con RustDesk plain, o cómo funciona el modelo de seguridad.

Recapitulación

1. Un VPS en la región más cercana a tus clientes.
2. Docker, UFW y los contenedores hbbs/hbbr.
3. Un registro A en DNS apuntando al VPS.
4. Tres valores de configuración en cada cliente: ID server, relay server, public key.
5. Un backup offline de data/ que hayas restaurado de verdad al menos una vez.
6. TLS vía Caddy y monitorización que te notifique.

Treinta minutos para levantarlo; indefinidamente para poseerlo. Si un requisito te obliga a estar en ese asiento, los pasos anteriores son todo el trabajo. Si nada lo hace, empieza con el relay gestionado — download the client, y vuelve a esta página el día en que un formulario de cumplimiento lo haga relevante.