RustDesk Docker : guide du serveur RustDesk conteneurisé

Vous cherchez à auto‑héberger RustDesk sans vous battre avec des compilations manuelles, l'enfer des dépendances ou des images VM fragiles. Ce guide montre comment exécuter une pile serveur RustDesk prête pour la production avec Docker et Docker Compose, pour gérer mises à jour, sauvegardes et montée en charge comme un pro des opérations.

Pourquoi utiliser Docker pour RustDesk

Les conteneurs offrent deux avantages immédiats pour une pile d'accès à distance auto‑hébergée : des déploiements reproductibles et de l'isolation. Au lieu de compiler hbbs/hbbr en local ou d'exécuter des paquets spécifiques à une plateforme, vous récupérez une image Docker, montez un volume persistant et démarrez. Cela simplifie les mises à jour, le CI/CD et les migrations d'hôte. Si vous exécutez déjà d'autres services en conteneurs (NGINX, certbot, monitoring), ajouter RustDesk de cette façon garde votre pile cohérente.

Quand ne pas conteneuriser : si vous avez besoin de binaires patchés sur mesure ou d'une intégration noyau profonde pour un relais très haute performance, une installation native peut être préférable. De même, si vous exigez un SLA d'entreprise officiellement supporté par le fournisseur, vérifiez si les conteneurs sont pris en charge par ce fournisseur.

Composants du serveur RustDesk — aperçu

Le rôle serveur de RustDesk se divise au minimum en deux éléments :

hbbs — le serveur d'ID/signaling. Il gère l'enregistrement et le rendez‑vous des clients.
hbbr — le serveur de relay (si la traversée NAT échoue). Il relaie le trafic entre pairs.

En production, vous exécutez généralement les deux. Un hôte léger unique peut faire tourner les deux services ; pour des déploiements plus importants, on les sépare, on place des instances hbbr derrière un load balancer et on ajoute de l'autoscaling pour la capacité de relais.

Démarrage rapide : exemple de déploiement Docker Compose

Prérequis : Ubuntu 22.04 LTS (ou tout Linux avec Docker Engine 20.10+), Docker Compose v2.x, un nom de domaine (ex. : rustdesk.example.com). Prévoyez au moins 512 Mo de RAM pour un petit serveur de test ; 1 Go+ recommandé pour un relais qui gère plusieurs sessions actives.

Ci‑dessous un exemple pratique Docker Compose qui exécute hbbs et hbbr en services séparés, monte des données persistantes et publie les ports standards de RustDesk. Avant d'exécuter, vérifiez les tags officiels de l'image rustdesk/rustdesk-server pour le dernier tag stable et remplacez rustdesk/rustdesk-server:latest si vous souhaitez épingler une version.

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

Explication :

Nous faisons tourner hbbs sur le port TCP/UDP 21115 et hbbr sur 21116 — ce sont les valeurs par défaut courantes pour les builds de serveur RustDesk. Confirmez le mappage de ports pour l'image que vous utilisez (certaines builds communautaires utilisent d'autres valeurs).
Les volumes persistants ./data/hbbs et ./data/hbbr conservent vos données d'enregistrement et de relais entre les redémarrages.
Utilisez restart: unless-stopped pour une résilience basique ; en production, intégrez les politiques de redémarrage de votre plateforme d'orchestration.

Exposition sécurisée : TLS, proxy inverse et pare‑feu

Le signaling et le trafic de relais de RustDesk peuvent être protégés par TLS et des règles de pare‑feu standard. Il existe deux approches courantes :

TLS direct avec un proxy en front de hbbs (recommandé pour la gestion de certificats au niveau web).
Garder hbbr comme relais TCP/UDP brut et sécuriser le réseau de l'hôte (utiliser ufw/nftables) tout en protégeant hbbs avec TLS.

La plupart des configurations utilisent NGINX ou Traefik pour terminer le TLS et transférer le trafic vers hbbs. Exemple de bloc serveur NGINX pour terminer TLS pour 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;
}

Utilisez certbot (Let's Encrypt) ou votre CA pour obtenir les certificats. Si votre relais (hbbr) est exposé en UDP/TCP public, ouvrez directement ces ports en limitant l'accès aux plages d'IP attendues, ou placez les nœuds relais dans un sous‑réseau privé derrière un load balancer.

DNS, clients et traversée de NAT

Pointer un enregistrement DNS A (par ex. rustdesk.example.com) vers l'IP publique de votre serveur. Dans le client RustDesk, définissez l'adresse du serveur sur ce domaine (pour l'ID et la recherche de relais). Les clients utilisent le serveur d'ID pour le rendez‑vous ; si les deux clients sont derrière un NAT restrictif, hbbr relaiera la session via votre serveur de relais.

Si vous contrôlez des machines clientes sur un LAN, vous pouvez exécuter un DNS interne ou distribuer un fichier de configuration qui pointe les clients vers l'IP interne de hbbs pour des connexions locales plus rapides.

Mise à l'échelle et recommandations de ressources

De combien de CPU/RAM un relais a‑t‑il besoin ? Cela dépend du nombre de sessions concurrentes et du type de session :

Petit serveur de test : 1 vCPU, 512 Mo RAM — une poignée de connexions inactives.
Relais de production (usage léger) : 2 vCPU, 1–2 Go RAM — des dizaines de sessions concurrentes.
Relais haut débit : 4+ vCPU, 4+ Go RAM et une capacité réseau adaptée à la bande passante attendue (par ex. 100+ Mbps).

Nous recommandons d'autoscaler les instances hbbr derrière un load balancer si vous attendez des pics (contrôle à haute charge média, partage d'écran). Utilisez de l'orchestration de conteneurs (Kubernetes, Docker Swarm) ou un simple scale horizontal avec un load balancer TCP/UDP (haproxy, cloud LB) qui préserve les IP clients.

Sauvegardes, mises à jour et fixation de version

Montez toujours des volumes persistants pour les données et sauvegardez‑les régulièrement. Un script de sauvegarde minimal :

# 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 {} \;

Pour les mises à jour, épinglez l'image Docker avec un tag au lieu de :latest. Testez en staging avant de mettre à jour l'image serveur en production. Exemple de workflow :

Tirer la nouvelle image : docker pull rustdesk/rustdesk-server:1.3.0 (exemple).
Lancer un conteneur de test avec les mêmes volumes et effectuer des smoke tests.
Planifier une fenêtre de maintenance et remplacer les containers sur les hôtes de production.

Dépannage et problèmes courants

Commencez par les logs : docker logs rustdesk-hbbs et docker logs rustdesk-hbbr. Problèmes typiques :

Les clients ne peuvent pas s'enregistrer : vérifiez que hbbs est joignable sur le domaine et que le TLS est valide.
Les sessions passent par le relais mais les performances sont mauvaises : inspectez le CPU/mémoire et le réseau du relais. Les paquets de relais sont généralement UDP ; assurez‑vous que l'UDP est autorisé par votre pare‑feu et par les security groups cloud.
Versions clientes incompatibles : utilisez des versions client/serveur RustDesk appariées ou compatibles. Si vous épinglez l'image serveur, assurez‑vous que les clients n'utilisent pas de fonctionnalités de protocole obsolètes.

Si la traversée NAT échoue systématiquement pour de nombreux clients, le problème vient généralement d'un NAT symétrique ou de pare‑feux d'entreprise. Dans ces cas, reposez‑vous sur des relais hbbr et surveillez latence/débit pour garantir une UX acceptable.

Considérations de sécurité

L'auto‑hébergement transfère la responsabilité sur vous. Étapes clés :

Terminez le TLS au niveau d'un proxy inverse et utilisez des chiffres robustes. Obtenez des certificats via Let's Encrypt ou une CA de confiance.
Renforcez l'hôte : n'exposez que les ports nécessaires, activez les mises à jour de sécurité automatiques sur l'OS et utilisez un pare‑feu (ufw/nftables).
Limitez l'accès aux interfaces d'administration et surveillez les logs pour détecter les tentatives de force brute. Envisagez la segmentation réseau ; placez les nœuds relais dans un sous‑réseau séparé si possible.

Si vous souhaitez une discussion plus large sur la sécurisation de l'accès à distance, voir nos articles sur remote desktop security et les compromis pratiques dans self‑hosted remote desktop.

Quand un fournisseur géré est préférable

L'auto‑hébergement avec Docker donne le contrôle et la confidentialité, mais si vous avez besoin d'un SLA entièrement géré, de fonctionnalités d'entreprise officielles (gestion des utilisateurs, facturation centralisée) ou d'une intégration Windows AD clé en main, des fournisseurs commerciaux comme TeamViewer ou AnyDesk peuvent être plus adaptés. Soyez honnête sur les compromis : l'auto‑hébergement évite des frais récurrents par siège et garantit la localisation des données, mais demande du temps opérationnel pour maintenir, surveiller et sécuriser l'infrastructure.

Étapes suivantes et références

Liste de contrôle pour passer du labo à la production :

Choisir un hôte avec Docker Engine 20.10+ et Docker Compose v2.x.
Créer des volumes persistants et un job de sauvegarde quotidien.
Épingler l'image serveur et valider les mises à jour en staging.
Terminer le TLS avec NGINX/Traefik et obtenir des certificats via Let's Encrypt.
Surveiller les hôtes relais et scaler hbbr lorsque le CPU ou la bande passante atteint les seuils de santé.

Vous voulez un téléchargement propre à comparer côte à côte avec une approche conteneurisée ? Téléchargez les binaires ou installateurs de Tenvo sur /download et consultez notre page /pricing pour les options de déploiement. Si vous préférez suivre une approche plus large pour l'accès à distance, notre remote access setup guide couvre réseau, authent et utilisabilité entre différents outils.

Exécuter RustDesk sous Docker est une approche solide et maintenable pour la plupart des auto‑hébergeurs : cela simplifie les mises à jour et s'intègre bien aux infrastructures conteneurisées existantes. Si vous avez besoin d'une copie du fichier compose ou d'aide pour adapter ceci à Kubernetes, revenez et je fournirai un manifeste K8s et un exemple de chart Helm.

Prêt à essayer ? Téléchargez les clients nécessaires ou les images de test depuis /download et lancez votre serveur RustDesk conteneurisé dès aujourd'hui.