Skip to content
Back to BlogGuide

Self-Hosted Remote Desktop: Der vollständige Leitfaden 2026 (RustDesk + GoDesk Relay)

GoDesk Editorial Team12 Min. Lesezeit
Self-Hosted Remote Desktop: Der vollständige Leitfaden 2026 (RustDesk + GoDesk Relay)

Möchten Sie einen Remote-Desktop, dessen Datenverkehr niemals über die Server eines Anbieters läuft? Dieser Leitfaden beschreibt das Self-Hosting des Relays Ende-zu-Ende auf einem $5/month VPS — was zu installieren ist, wie man es härtet und wie man mit Ausfallmodi umgeht, die die offiziellen Docs auslassen.

Für die meisten Nutzer ist das vom Anbieter gehostete Relay (TeamViewer's, AnyDesk's, GoDesk's) in Ordnung. Ende-zu-Ende-Verschlüsselung bedeutet, dass das Relay nur Chiffretext sieht — es kann Ihre Bildschirmdaten, Tastatureingaben oder Dateien nicht lesen. Aber „in Ordnung“ ist nicht „ideal“, wenn eine der folgenden Bedingungen zutrifft:

  • Compliance: regulierte Branche, in der Daten keine Drittinfrastruktur passieren dürfen (rechtlich, Verteidigung, bestimmte Gesundheitsbereiche).
  • Sovereignty: Sie möchten nicht, dass Metadaten zum Remote-Zugriff (wer sich wann und wie lange verbunden hat) von Dritten gesammelt werden.
  • Cost at scale: wenn Sie 100+ Geräte über ein Relay betreiben, summieren sich Anbietergebühren — ein selbstgehostetes Relay auf einem $5/month VPS verarbeitet tausende Sitzungen.
  • Air-gapped or restricted networks: das Anbieter-Relay ist aus Ihrer Umgebung nicht erreichbar.

Trifft eine dieser Aussagen auf Sie zu, führt dieser Leitfaden durch das Self-Hosting Ende-zu-Ende auf einem einfachen VPS. Der Referenz-Stack ist RustDesk's hbbs + hbbr, mit denen sich sowohl GoDesk- als auch RustDesk-Clients verbinden können. Gesamte Einrichtungszeit: etwa 30 Minuten inklusive TLS.

Was Sie aufbauen

Zwei Dienste:

  • hbbs (Rendezvous-Server): übernimmt das Initial-Handshake. Beide Clients verbinden sich kurz mit ihm, um sich zu finden, öffentliche Schlüssel auszutauschen und zu prüfen, ob direktes P2P möglich ist. Hört auf TCP/UDP 21115-21117.
  • hbbr (Relay-Server): wenn direktes P2P fehlschlägt (NAT, Firewall), fließt der Datenverkehr durch das Relay. Hört auf TCP 21117 (und UDP in einigen Szenarien).

Das Relay schaltet nur ein, wenn P2P nicht funktioniert — das ist in den meisten Consumer-Szenarien wegen NAT der Fall, aber selten im selben LAN. Selbst mit selbstgehostetem Relay zahlen Sie VPS-Bandbreite nur für die Sitzungen, die sie tatsächlich benötigen.

Schritt 1: VPS auswählen

Bandbreite ist die wichtigste Ressource. CPU und RAM sind minimal (das Relay leitet nur Bytes weiter). Vernünftige Optionen in 2026:

  • Hetzner CX22 (€4/mo, 2 vCPU, 4 GB RAM, 20 TB bandwidth, EU data centers) — bestes Preis-/Bandbreiten-Verhältnis.
  • DigitalOcean Basic Droplet ($6/mo, 1 vCPU, 1 GB, 1 TB bandwidth) — gute UX, US/EU-Regionen.
  • OVH VPS Starter (€3.50/mo, 2 vCPU, 2 GB, unmetered bandwidth) — am besten für hochvolumige Bandbreite.
  • Hetzner Storage Box — KEIN VPS, hier nur erwähnt, weil Leser danach fragen. Funktioniert nicht für diesen Zweck; Sie brauchen einen echten Server.

Wählen Sie eine Region in der Nähe der verbindenden Clients — das beeinflusst die Latenz, da Relay-Verkehr round-trip-gebunden ist.

Schritt 2: Server einrichten

Starten Sie ein frisches Ubuntu 22.04- oder Debian 12-VPS. SSH als 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

Überspringen Sie die Firewall nicht. RustDesk's Standardkonfiguration öffnet nur die benötigten Ports, aber der Rest sollte geschlossen sein.

Schritt 3: hbbs + hbbr per Docker ausführen

Erstellen Sie /opt/godesk-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

Ersetzen Sie your-server.example.com durch den tatsächlichen Hostnamen. Starten:

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

Beim ersten Start sollte hbbs einen öffentlichen Schlüssel ausgeben — speichern Sie ihn aus den Logs (oder id_ed25519.pub im Daten-Volume), weil Clients ihn nutzen, um zu verifizieren, dass sie sich mit IHREM Relay und nicht mit einem Man-in-the-Middle verbinden.

Schritt 4: DNS konfigurieren

Richten Sie einen A-Record für relay.yourdomain.com auf die IP des VPS. RustDesk akzeptiert auch eine bare IP, aber ein Hostname ist flexibler, falls Sie später migrieren.

Schritt 5: Clients auf das selbstgehostete Relay zeigen

Dieser Teil wird in den meisten Anleitungen übergangen. Jeder Client braucht drei Konfigurationswerte:

  • ID server = relay.yourdomain.com:21116
  • Relay server = relay.yourdomain.com:21117
  • Public key = der Inhalt von data/id_ed25519.pub auf Ihrem VPS

Auf Windows / macOS / Linux:

  1. Öffnen Sie den GoDesk- oder RustDesk-Client.
  2. Einstellungen → Netzwerk → ID/Relay-Server.
  3. Geben Sie die drei oben genannten Werte ein. Speichern.
  4. Starten Sie den Client neu.

Die Statusanzeige sollte innerhalb weniger Sekunden grün werden und zeigen, dass der Client beim Relay registriert ist. Bleibt sie rot, prüfen Sie die Firewall-Regeln und ob der öffentliche Schlüssel exakt übereinstimmt.

Schritt 6: TLS hinzufügen (optional, aber empfohlen)

Das standardmäßige RustDesk-Protokoll ist bereits auf Anwendungsebene verschlüsselt (der öffentliche Schlüssel, den Sie kopiert haben, ist Teil davon). TLS oben drauf fügt eine zweite Schutzschicht hinzu und schützt gegen einige passive Netzwerkangriffe. Die Einrichtung besteht aus einem Reverse-Proxy (nginx oder Caddy) vor den Relay-Ports.

Caddy-Variante (einfacher):

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

Caddy stellt automatisch das Let's Encrypt-Zertifikat aus. Aktualisieren Sie die Clients, damit sie Port 443 mit aktiviertem TLS verwenden.

Schritt 7: Schlüssel sichern

Das data/-Verzeichnis enthält das Schlüsselpaar des Rendezvous-Servers. Wenn Sie es verlieren, müssen alle Clients mit dem neuen öffentlichen Schlüssel neu konfiguriert werden. Sichern Sie es:

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

Lagern Sie das Backup offline. Falls der VPS kompromittiert wird, möchten Sie schnell eine neue Instanz mit denselben Schlüsseln aufsetzen, damit bestehende Clients ohne Neukonfiguration weiterarbeiten.

Ausfallmodi, die die Docs nicht erwähnen

Failure 1: Clients erreichen das Relay nicht. In 90 % der Fälle ist das die Firewall. Prüfen Sie ufw status, prüfen Sie, ob die Sicherheitsgruppen des Cloud-Anbieters dieselben Ports erlauben, und führen Sie nc -vz relay.yourdomain.com 21116 von einem Client aus, um die Erreichbarkeit zu verifizieren.

Failure 2: P2P fällt immer auf das Relay zurück. Symmetrisches NAT oder strikte Unternehmensfirewalls zwingen alles durch das Relay. Das ist normal — die Performance ist akzeptabel, aber die Bandbreite wird abgerechnet. Verwenden Sie relay.yourdomain.com mit einem VPS-Tarif, der hohe Bandbreite bietet.

Failure 3: Der Relay-Prozess stirbt und startet nicht neu. Dockers restart: unless-stopped deckt die meisten Fälle ab. Fügen Sie docker compose ps zu einem Cron-Job hinzu, der Sie bei fehlenden Containern alarmiert.

Failure 4: SSL-Zertifikat läuft ab. Wenn Sie Caddy nutzen, geschieht die Erneuerung automatisch — Caddy erneuert 30 Tage vor Ablauf. Bei nginx + certbot richten Sie einen Cron-Job zur Erneuerung ein. certbot.eff.org enthält die offizielle Anleitung.

Bandbreitenrechnung

Die Qualität ist hier entscheidend. Grobe Faustregeln:

  • Niedrige Qualität (textlastige Arbeit): ~50 KB/s = 180 MB/Stunde
  • Mittlere Qualität (allgemeine Büroarbeit): ~200 KB/s = 720 MB/Stunde
  • Hohe Qualität (Video, Design): ~1 MB/s = 3,6 GB/Stunde

Ein Hetzner CX22 mit 20 TB/Monat Bandbreite bewältigt grob 5.500 Stunden hochqualitativer Sitzungen pro Monat — deutlich mehr, als ein Einzelner oder kleines Team benötigt. Die 20 TB-Grenze ist relevanter für Organisationen mit hunderten Geräten.

Fertige Option: GoDesk's self-hostable relay

Alles oben ist der manuelle Weg mit dem Open-Source-Stack von RustDesk. GoDesk veröffentlicht ein Self-Host-Bundle desselben hbbs/hbbr-Stacks mit sinnvollen Default-Einstellungen. Wenn Sie keine Docker-Compose-Dateien verwalten möchten, sehen Sie unsere Self-Hosting-Anleitung — gleiche Architektur, mit einem One-Command-Installationsskript, das die oben genannten Schritte umschließt.

Wann Sie NICHT self-hosten sollten

Self-Hosting erzeugt betrieblichen Aufwand: Monitoring, Schlüssel-Backups, OS-Updates, Zertifikatserneuerung. Wenn Ihr Anwendungsfall „Ich will mich auf meinen Heim-PC verbinden“ ist, ist das vom Anbieter gehostete Relay (die kostenlose GoDesk-Stufe deckt 5 GB/Monat) deutlich weniger Aufwand als ein VPS, den Sie dauerhaft betreiben.

Self-Hosten Sie nur bei echtem Bedarf — Compliance, Sovereignty, Skalierung. Lassen Sie es sein, wenn „es wäre cool“ der einzige Grund ist; die Betriebskosten holen Sie früher oder später ein.

Zusammenfassung

  1. $5/month VPS in Ihrer bevorzugten Region.
  2. Docker + UFW + RustDesk's hbbs/hbbr-Container.
  3. DNS A-Record, der auf den VPS zeigt.
  4. Drei Konfigurationswerte auf jedem Client (ID server, relay server, public key).
  5. Sichern Sie die Schlüssel.
  6. Optional: TLS über Caddy/nginx.

Einrichtungsdauer: ca. 30 Minuten. Laufender Aufwand: minimal. Ergebnis: Remote-Desktop, dessen Datenverkehr niemals über die Infrastruktur Dritter läuft.