Self-hosted remote desktop: der ehrliche Leitfaden 2026

Suchen Sie nach "self-hosted remote desktop" und Sie finden dutzende Tutorials, die bei docker compose up -d enden. Die Installation ist der einfache Teil, und sie dauert tatsächlich 30 Minuten. Diese Anleitung deckt die komplette Einrichtung ab — und dann den Teil, der entscheidet, ob Sie das überhaupt hätten tun sollen: was es kostet, das System nach dem Tutorial am Laufen zu halten.

Die kurze Antwort

Hosten Sie selbst, wenn eine Anforderung Sie dazu zwingt. Nutzen Sie ein managed Relay, wenn nichts Sie dazu zwingt. Das klingt knapp; hier ist der eigentliche Test:

• Selbst hosten, wenn: eine schriftliche Compliance-Vorgabe besagt, dass Sitzungsdaten nicht über Infrastruktur Dritter übertragen werden dürfen; Sie abgeschottete oder anderweitig eingeschränkte Netzwerke betreiben, in denen ein externes Relay unerreichbar ist; oder Datenresidenz-Regeln eine Gerichtsbarkeit vorschreiben, in der Sie bleiben müssen.
• Managed Relay nutzen, wenn: Ihr Grund irgendeine Variante von "Ich möchte es lieber selbst betreiben" ist. Das ist eine legitime Präferenz, aber es ist gleichzeitig eine dauerhafte Betriebsaufgabe — sehen Sie sich die Rechnung unten an, bevor Sie sich dafür anmelden.

Wichtig ist, klarzustellen, zwischen was Sie wählen, denn es sind nicht zwei verschiedene Produkte. Tenvo ist AGPL-3.0 und das managed Relay betreibt dieselbe hbbs/hbbr-Architektur, die diese Anleitung installiert. Die Wahl betrifft, wer die Maschine betreibt, nicht was die Software tut.

Zuerst: was ein Relay tatsächlich sehen kann

Das ist vor allem deshalb relevant, weil es gewöhnlich der Grund ist, warum Leute Self-Hosting in Erwägung ziehen — und es wird meist falsch beschrieben.

Bei einer direkten Peer-to-Peer-Verbindung läuft die Sitzung Ende-zu-Ende zwischen den beiden Geräten. Wenn eine direkte Verbindung nicht möglich ist — symmetrisches NAT, strikte Firmen-Firewalls — wird die Sitzung stattdessen über ein Relay geführt und TLS terminiert am Relay. Wer auch immer dieses Relay betreibt, kann daher den gerelayten Verkehr einsehen. Wir werden nicht behaupten, dass das bei unserem Relay anders ist.

Das ist eine Eigenschaft des Protokolls, nicht davon abhängig, wer die Serverkosten trägt. Das eigene Betreiben des Relays verschlüsselt nichts, was ein Provider-Relay nicht ebenfalls verschlüsseln würde; es ändert wer diese Position innehat. Wenn in Ihrer Compliance-Vorgabe festgeschrieben ist, wer diese Position einnehmen darf, ist Self-Hosting die korrekte Antwort und der Rest dieser Anleitung ist für Sie. Wenn das nirgends schriftlich steht, übernehmen Sie eine Betriebsaufgabe, um ein Problem zu lösen, das Sie nicht haben.

Was Sie aufbauen

Zwei Dienste:

• hbbs (Rendezvous-Server): übernimmt das initiale Handshake. Beide Clients verbinden sich kurz mit ihm, um einander zu finden, öffentliche Schlüssel auszutauschen und zu prüfen, ob eine direkte P2P-Verbindung möglich ist. Hört auf TCP/UDP 21115-21117.
• hbbr (Relay-Server): trägt die Sitzung, wenn direkte P2P-Verbindungen fehlschlagen. Hört auf TCP 21117 (und in manchen Szenarien auf UDP).

Das Relay greift nur ein, wenn P2P nicht funktioniert — häufig bei Consumer-NAT, selten im selben LAN. Selbst beim Self-Hosting bezahlen Sie VPS-Bandbreite nur für die Sitzungen, die tatsächlich relayed werden müssen.

Schritt 1: Wählen Sie einen VPS

Bandbreite ist die Ressource, die zählt. CPU und RAM sind minimal, da das Relay Bytes weiterleitet statt sie zu verarbeiten.

• Hetzner CX22 (€4/mo, 2 vCPU, 4 GB RAM, 20 TB bandwidth, EU data centres) — bestes Preis-Bandbreite-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 Szenarien mit hohem Bandbreitenbedarf.

Wählen Sie eine Region in der Nähe der Clients, die sich verbinden werden. Relay-Traffic ist round-trip-gebunden, daher ist dies der wichtigste Hebel für wahrgenommene Latenz — und, wie unten beschrieben, der Punkt, bei dem ein einzelner VPS am schlechtesten abschneidet.

Schritt 2: Server einrichten

Starten Sie ein frisches Ubuntu 22.04 oder Debian 12 VPS. SSH als root einloggen.

# 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. Die Standardkonfiguration öffnet nur die benötigten Ports; alles andere sollte geschlossen sein.

Schritt 3: hbbs + hbbr per Docker starten

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

Ersetzen Sie your-server.example.com durch den tatsächlichen Hostnamen und starten Sie dann:

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

hbbs gibt beim ersten Start einen öffentlichen Schlüssel aus. Speichern Sie ihn aus den Logs (id_ed25519.pub im Daten-Volume) — Clients nutzen ihn, um zu verifizieren, dass sie sich mit Ihrem Relay und nicht mit einem Imposter verbinden.

Schritt 4: DNS konfigurieren

Richten Sie einen A-Record für relay.yourdomain.com auf die VPS-IP. Eine IP-Adresse funktioniert ebenfalls, aber ein Hostname ist deutlich einfacher zu handhaben, falls Sie später migrieren.

Schritt 5: Clients auf Ihr Relay zeigen

Der Teil, den die meisten Anleitungen übergehen. Jeder Client benötigt drei Werte:

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

Unter Windows, macOS und Linux:

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

Die Statusanzeige sollte innerhalb weniger Sekunden grün werden. Bleibt sie rot, prüfen Sie die Firewall-Regeln und ob der öffentliche Schlüssel exakt übereinstimmt — ein nachgestellter Zeilenumbruch ist die übliche Ursache.

Schritt 6: TLS hinzufügen

Setzen Sie einen Reverse-Proxy vor die Relay-Ports. Caddy ist der kürzeste Weg:

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

Caddy stellt und erneuert das Let's Encrypt-Zertifikat für Sie aus. Aktualisieren Sie die Clients auf Port 443 mit aktiviertem TLS — das bringt Sie auch durch restriktive ausgehende Firewalls, die nur 443 erlauben.

Schritt 7: Schlüssel sichern

Das Verzeichnis data/ enthält das Schlüsselpaar des Rendezvous-Servers. Verlieren Sie es, müssen alle Clients per Hand mit einem neuen öffentlichen Schlüssel neu konfiguriert werden — auf jeder Maschine.

# 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/

Bewahren Sie es offline auf. Falls die VPS kompromittiert wird, sollten Sie auf einer frischen Maschine mit denselben Schlüsseln neu aufbauen können, sodass bestehende Clients unverändert weiterarbeiten.

Die Fehlerfälle, die die Tutorials auslassen

Clients erreichen das Relay nicht. Fast immer die Firewall. Prüfen Sie ufw status, prüfen Sie, dass die Sicherheitsgruppe des Cloud-Providers dieselben Ports erlaubt, und führen Sie nc -vz relay.yourdomain.com 21116 von einem Client aus, um die Erreichbarkeit zu bestätigen.

Alles fällt auf das Relay zurück. Symmetrisches NAT und strikte Firmen-Firewalls zwingen jede Sitzung durch das Relay. Die Performance hält in der Regel stand, aber Ihre Bandbreitenrechnung wird dann zur Hauptgeschichte statt zur Ausnahme.

Das Relay stirbt und kommt nicht zurück. Dockers restart: unless-stopped deckt die üblichen Fälle ab. Es deckt keinen vollen Datenträger, einen OOM-Kill oder einen Kernel-Panic ab — dafür brauchen Sie Monitoring, das jemanden per Pager alarmiert, und diese Person sind Sie.

Das Zertifikat läuft ab. Automatisch mit Caddy. Bei nginx + certbot ist es ein Cron-Job, an den Sie sich erinnern müssen; certbot.eff.org hat die offizielle Anleitung.

Die Rechnung, die die Tutorials nicht zeigen

Der €4-VPS ist die billigste Position auf der Rechnung, und ihn als Kosten des Self-Hostings zu zitieren ist derselbe Trick wie den Kaufpreis eines Autos als die einzigen Kosten des Fahrens anzugeben. Der Rest:

• Sie sind on-call für Ihr Relay. Wenn es um 2 Uhr morgens ausfällt, ist der Remote-Zugriff genau das, was Sie nicht mehr haben, um es zu reparieren.
• OS-Patching, für immer. Ein öffentlich erreichbarer Server im Internet ist ein Server, für dessen Patch-Stand Sie verantwortlich sind.
• Schlüsselverwaltung. Verlieren Sie data/, konfigurieren Sie jeden Client per Hand neu. Dieses Backup müssen Sie tatsächlich verifizieren, nicht nur planen.
• Zertifikats-Erneuerung. Automatisch, bis zu dem Tag, an dem sie es nicht mehr ist.
• Eine Region, eine Maschine. Ein einzelner VPS ist ein Standort und ohne Failover. Clients auf der anderen Seite der Welt bezahlen dafür mit Round-Trip-Latenz; ist die Maschine down, sind alle down.

Bandbreite ist die eine Kostenposition, die sich wirklich leicht schätzen lässt. Grobe Zahlen pro relayed Sitzung:

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

Die 20 TB/Monat eines Hetzner CX22 decken grob 5.500 Stunden hochqualitativer relayed Sitzungen ab. Für eine Einzelperson oder ein kleines Team ist diese Obergrenze selten bindend — genau das ist der Punkt. Wenn Bandbreite Ihr Grund für Self-Hosting war, ist es kein guter Grund. Die bindenden Einschränkungen sind die vier Bulletpoints weiter oben.

Was das managed Relay stattdessen übernimmt

Gleiche Architektur, anderer Betreiber. Die Relay-Flotte ist multi-regional statt ein einzelner VPS, sodass Clients mit etwas in ihrer Nähe verbinden statt mit Ihrem VPS. Es wird von Personen überwacht, deren Aufgabe das ist. Schlüsselmaterial, Patching und Zertifikatserneuerung sind dann nicht mehr Ihr Problem. Wenn nachts um 2 Uhr etwas kaputtgeht, werden andere Leute gerufen, nicht Sie.

Das ist es, was das Abonnement kauft: Free at $0, Lite at $2.99/mo, Pro at $7.99/mo — sehen Sie pricing für die Inhalte der einzelnen Stufen, oder the business plans, wenn Sie im Team ausrollen. Gegenüber einem €4-VPS plus eigener On-Call-Rotation ist die Rechnung für die meisten Leute eindeutig.

Wann Self-Hosting wirklich die richtige Entscheidung ist

Es ist die richtige Entscheidung, wenn eine Vorgabe es verlangt: regulierte Arbeit, bei der Traffic nicht über Infrastruktur Dritter laufen darf; abgeschottete oder eingeschränkte Netzwerke, in denen ein externes Relay unerreichbar ist; oder Residenz-Regeln, die Sie an eine Gerichtsbarkeit binden. In diesen Fällen sind die Betriebskosten kein Overhead, sondern die Anforderung, und diese Anleitung ist genau das, was Sie brauchen.

Es ist außerdem relevant, dass die Option überhaupt existiert. Tenvo ist AGPL-3.0 und der Server-Stack ist Open Source, daher ist das managed Relay ein Komfort, den Sie kaufen, statt ein Lock-in, das Sie akzeptieren. Falls wir jemals aufhören, nützlich zu sein, ist der Ausstieg die oben beschriebene Anleitung — genau dafür haben wir sie veröffentlicht. Siehe how the managed build compares to plain RustDesk, oder how the security model works.

Zusammenfassung

1. Ein VPS in der Region, die Ihren Clients am nächsten ist.
2. Docker, UFW und die hbbs/hbbr-Container.
3. Ein DNS-A-Record, der auf den VPS zeigt.
4. Drei Konfigurationswerte auf jedem Client: ID server, relay server, public key.
5. Ein Offline-Backup von data/, das Sie tatsächlich einmal wiederhergestellt haben.
6. TLS via Caddy und Monitoring, das Sie alarmiert.

30 Minuten, um es aufzusetzen; unbegrenzt, um es zu besitzen. Wenn eine Vorgabe Sie an diesen Platz setzt, sind die oben stehenden Schritte der gesamte Job. Wenn nichts Sie zwingt, starten Sie mit dem managed Relay — download the client — und kommen Sie hierher zurück, an dem Tag, an dem ein Compliance-Formular es relevant macht.