Installation self-hosted RustDesk — guide complet Docker + Caddy TLS

Vous essayez d'auto-héberger RustDesk mais butez sur les mêmes obstacles : NAT et pare-feu, composants serveur confus, et la question récurrente de savoir si TLS est nécessaire en plus du chiffrement propre de RustDesk. Ce guide accompagne un lecteur technique dans une…
Vous essayez d'auto-héberger RustDesk mais butez sur les mêmes obstacles : NAT et pare-feu, composants serveur confus, et la question récurrente de savoir si TLS est nécessaire en plus du chiffrement propre de RustDesk. Ce guide accompagne un lecteur technique à travers une installation complète et reproductible de rustdesk self hosted sur un seul VPS — Docker Compose pour hbbs/hbbr, et TLS en frontal avec Caddy pour que les clients puissent se connecter sur le port 443 depuis des réseaux restrictifs.
Ce que nous construisons et pourquoi
Objectif : un rendez-vous + relais RustDesk sur un seul VPS, accessible par vos clients via un nom DNS. Composants impliqués :
- rustdesk server components (hbbs and hbbr) exécutés dans Docker — testé ici avec les images rustdesk-server v1.2.1.
- Caddy v2 (gestion des certificats via Let's Encrypt) pour fournir une porte d'entrée TLS sur le port 443 afin que les clients atteignent votre relais même lorsque le port sortant 21115 est bloqué.
- Passage UDP optionnel ou relais supplémentaires pour la mise à l'échelle (traité dans les notes).
Pourquoi faire cela ? Le protocole de RustDesk fournit déjà du chiffrement de bout en bout pour la session distante, mais de nombreux réseaux n'autorisent que les sorties vers 443/80. Terminer TLS sur votre VPS (et laisser Caddy obtenir et renouveler automatiquement les certificats) est un moyen pratique de rendre le service joignable sans ouvrir de ports non standard. Si vous ne souhaitez qu'un accès LAN ou contrôler le NAT avec des tunnels inverses, voyez notre article sur remote-desktop-without-port-forwarding.
Prérequis et choix
Ce que j'ai utilisé lors de la rédaction :
- Ubuntu 22.04 LTS sur un VPS public (1 vCPU / 2 GB RAM suffit pour des tests ; pour plusieurs clients, passer à 4+ CPU et surveiller CPU/RAM).
- Docker 24.x et Docker Compose v2 (syntaxe CLI compose V2).
- Image Docker rustdesk-server (tag v1.2.1 dans ce guide) — adaptez si des versions stables plus récentes existent.
- Caddy v2.6+ (l'ACME automatique de Caddy rend les renouvellements de certificats indolores).
- Un enregistrement DNS A tel que rustdesk.example.com pointant vers l'IP publique de votre VPS, et les ports 80/443 autorisés (Caddy a besoin de 80/443 pour la validation).
Remarques sur les cas où un produit commercial hébergé est préférable : si vous avez besoin d'un SLA de niveau entreprise, d'audit de session avancé ou de support commercial, TeamViewer/AnyDesk peuvent être plus adaptés — voir rustdesk-vs-anydesk et nos articles de comparaison tarifaire. L'auto-hébergement est préférable si vous souhaitez le contrôle, des coûts récurrents plus faibles ou éviter des serveurs tiers.
Étape 1 — Déployer le serveur rustdesk avec Docker Compose
Créez un répertoire de projet sur le VPS et déposez-y le docker-compose.yml ci-dessous. Cet exemple expose les ports typiques du serveur RustDesk sur l'hôte. Remplacez les variables d'environnement et les tags d'image selon votre environnement.
mkdir -p ~/rustdesk-server
cd ~/rustdesk-server
cat > docker-compose.yml <<'EOF'
version: '3.8'
services:
rustdesk-server:
image: rustdesk/rustdesk-server:1.2.1
container_name: rustdesk-server
restart: unless-stopped
ports:
- "21115:21115/tcp" # rendezvous / TCP relay
- "21115:21115/udp" # optional UDP relay (if your image supports it)
- "21116:21116/udp" # additional UDP (some builds use multiple UDP ports)
volumes:
- ./data:/root/.config/rustdesk-server
environment:
- RUSTDESK_RELAY_IPV4=0.0.0.0
- RUSTDESK_RELAY_PORT=21115
EOF
Montez le service :
docker compose up -d # watch logs docker compose logs -f rustdesk-server
Vérifiez que le conteneur a démarré et écoute sur 21115. Sur votre VPS, lancez :
ss -tuln | grep 21115
Si l'image que vous utilisez expose d'autres ports ou a un style de configuration différent, consultez le README de cette image. Certains opérateurs compilent hbbs/hbbr manuellement et utilisent des ports personnalisés ; adaptez ces étapes en conséquence.
Étape 2 — Utiliser Caddy pour placer TLS devant le relais (443)
Il existe deux approches courantes pour rendre RustDesk accessible sur le port 443 :
- Terminaison TLS TCP avec Caddy 2.6+ (Caddy termine TLS et achemine le TCP brut vers le relais rustdesk). Caddy a ajouté des fonctionnalités TCP améliorées en v2.6 ; avec cette approche vous avez des certificats ACME automatiques et des renouvellements.
- Laisser Caddy gérer uniquement les certificats, et utiliser un proxy TCP (stunnel, HAProxy ou Nginx stream) pour consommer ces fichiers de certificats. C'est une solution de repli si votre version de Caddy ou votre environnement ne supporte pas les fonctionnalités proxy TCP nécessaires.
Ci-dessous une configuration Caddy minimale et pragmatique qui utilise Caddy pour faire du TLS sur le port 443 et rediriger la connexion TCP brute vers le relais RustDesk à localhost:21115. Cela nécessite Caddy v2.6+ (vérifiez avec caddy version).
# Caddyfile (save as ./Caddyfile in the same folder as docker-compose.yml)
rustdesk.example.com:443 {
# Caddy will obtain/renew certificates automatically
reverse_proxy 127.0.0.1:21115 {
# Use plain TCP transport; Caddy will accept TLS from clients and connect to the backend via TCP
transport http {
# We don't speak HTTP to the backend; keep minimal transport settings
}
}
}
Extrait docker-compose pour exécuter Caddy à côté du serveur rustdesk (même projet) :
cat >> docker-compose.yml <<'EOF'
caddy:
image: caddy:2.6.4
container_name: caddy
restart: unless-stopped
ports:
- "80:80"
- "443:443"
volumes:
- ./Caddyfile:/etc/caddy/Caddyfile:ro
- caddy_data:/data
- caddy_config:/config
volumes:
caddy_data:
caddy_config:
EOF
docker compose up -d caddy
Mise en garde importante : le reverse_proxy intégré de Caddy est orienté HTTP, donc le comportement lors du proxying de TCP brut non HTTP dépend de la version de Caddy et des options de transport. En pratique, de nombreux opérateurs utilisent les fonctionnalités de proxying TCP introduites en 2.6 pour terminer TLS pour des backends TCP arbitraires. Si vous rencontrez des problèmes de protocole, utilisez l'option (2) ci-dessus : laissez Caddy gérer les certificats et confiez les fichiers de certificats à une petite couche TLS TCP (stunnel ou HAProxy stream) qui proxy ensuite le TCP simple vers rustdesk.
Exemple : Caddy en gestionnaire de certificats + stunnel pour la terminaison TLS (aperçu rapide).
# 1) Ensure Caddy is running and has issued certs for rustdesk.example.com # 2) Copy cert/key from Caddy storage into a place stunnel can read, or mount the same volume. # 3) Run stunnel with a config that points TLS 443 -> 127.0.0.1:21115 # stunnel.conf snippet [rustdesk] accept = 443 connect = 127.0.0.1:21115 cert = /etc/stunnel/fullchain.pem key = /etc/stunnel/privkey.pem # In Docker world, mount Caddy's certificate files into the stunnel container path above.
Chaque approche vous donne un nom d'hôte (rustdesk.example.com) et le port 443 pour les clients. Testez la connectivité depuis une autre machine avec : nc -vz rustdesk.example.com 443 — vous devriez établir une poignée de main TLS si Caddy/stunnel sont configurés correctement.
Étape 3 — Pointer les clients vers votre serveur auto-hébergé
Les clients RustDesk permettent des serveurs ID/relay personnalisés dans les paramètres. L'interface exacte varie selon la plateforme et la version, mais les valeurs essentielles sont :
- ID Server / Rendezvous: rustdesk.example.com:443 (ou votre domaine et port)
- Relay Server: rustdesk.example.com:443
Sur Windows : Ouvrez RustDesk > Settings > ID/Server et définissez Id server et Relay server sur rustdesk.example.com:443. Sur Linux et macOS, les mêmes réglages se trouvent dans Preferences. Pour les installations headless, le client peut parfois être configuré via des flags en ligne de commande ou un fichier de configuration — consultez le dépôt client pour les détails.
Assurez-vous que les clients sont récents (1.2.x ou plus récent au moment de la rédaction). Les clients récents incluent des corrections de protocole et une meilleure traversal NAT. Si vous utilisez un client beaucoup plus ancien, le comportement peut varier.
Dépannage et durcissement
Problèmes courants et comment les diagnostiquer :
- Pare-feu : confirmez que le pare-feu du VPS (ufw/iptables/fournisseur cloud) autorise les entrées sur 80/443. Pour le conteneur RustDesk qui écoute localement sur 21115, assurez-vous que le socket TCP existe (ss/netstat).
- Émission de certificats : si Let's Encrypt ne peut pas valider, Caddy journalisera une erreur. Vérifiez que votre enregistrement DNS A pointe vers le VPS et que le port 80 est joignable pendant l'émission initiale.
- Incompatibilité de protocole : si vous voyez une poignée de main TLS réussie mais des échecs de connexion côté client, il se peut que vous fassiez du proxy HTTP uniquement avec Caddy par erreur. Utilisez l'approche stunnel dans ces cas.
- Relais UDP : les performances de RustDesk s'améliorent avec UDP pour les trames d'écran ; si UDP est nécessaire et que votre chemin réseau bloque UDP, vous basculerez sur le relais TCP. Exposez/transmettez les ports UDP seulement si vous contrôlez votre réseau et savez ce que vous faites.
Conseils de durcissement :
- Exécutez le rustdesk server sous un utilisateur non privilégié dédié et maintenez les images Docker à jour.
- Activez fail2ban ou l'équivalent pour limiter les tentatives répétées échouées, et surveillez les logs (
docker compose logs -f rustdesk-server). - Sauvegardez régulièrement le répertoire de données du rustdesk server (dans l'exemple c'est ./data).
- Envisagez d'exécuter le relais derrière un réseau privé ou un VPC si vous exploitez plusieurs relais.
Notes de montée en charge : un relais unique convient pour de petites équipes. Pour des déploiements plus importants, exécutez plusieurs processus hbbr sur des machines séparées et utilisez un équilibrage DNS ou un vrai load balancer L4. Si vous avez besoin de fonctionnalités centralisées d'entreprise comme l'audit, les solutions commerciales peuvent avoir l'avantage. Consultez nos articles sur self-hosted-remote-desktop et rustdesk-vs-anydesk pour les compromis.
Maintenance, coûts et recommandations finales
Les coûts opérationnels sont principalement l'hébergement VPS et votre temps. Un petit VPS typique (1–2 CPU, 2–4 GB) se trouve pour $5–10/month (DigitalOcean, Vultr, Hetzner). Caddy et RustDesk server sont open-source ; le coût récurrent principal est l'hébergement. Si vous avez besoin d'une facturation GUI ou de support entreprise, les fournisseurs commerciaux facturent par siège ou par session — voyez nos comparaisons tarifaires comme anydesk-pricing-explained et godeskflow-vs-teamviewer-pricing pour le contexte.
Recommandations :
- Commencez avec un seul VPS et la structure Docker Compose ci-dessus. Testez les connexions depuis les réseaux exacts où se trouveront vos utilisateurs (FAI domestiques, pare-feu d'entreprise).
- Si les clients sont fréquemment derrière des pare-feu très restrictifs, placez votre relais sur le port 443 et vérifiez que la terminaison TLS fonctionne de façon fiable ; utilisez Caddy+stunnel si le proxy TCP natif de Caddy pose problème.
- Automatisez les sauvegardes du répertoire de données du serveur et suivez les mises à jour d'image. Les versions du RustDesk server évoluent ; testez les upgrades en staging si vous dépendez de la disponibilité production.
Si vous voulez un guide plus court sur les schémas d'accès distant ou des alternatives, lisez nos articles liés : remote-access-setup-guide et remote-desktop-security.
Vous avez fini de lire ? Si vous voulez essayer un bureau à distance entièrement open-source qui s'intègre bien à l'auto-hébergement, téléchargez GoDesk ou comparez ses tarifs — voir GoDesk download et GoDesk pricing. Si vous êtes prêt à déployer cette configuration RustDesk, commencez par créer le docker-compose.yml et le Caddyfile ci-dessus puis lancez docker compose up -d. Pour un démarrage rapide, allez sur /download pour récupérer les clients et vous connecter.
More articles
Bureau à distance sans redirection de port : comment ça marche réellement
9 min de lecture
Le bureau à distance est-il sécurisé ? Un modèle de menace honnête
10 min de lecture
RustDesk vs AnyDesk : Guide d'achat 2026 (et la troisième option souvent ignorée par les critiques)
11 min de lecture