Selbstgehosteter Remote Desktop: Warum, wie und was schiefgehen kann

„Selbstgehosteter Remote Desktop“ bedeutet in der Regel eines von zwei Dingen: Sie hosten Ihre eigene Relay/Rendezvous-Infrastruktur für ein Tool wie RustDesk, oder Sie betreiben eine komplette webbasierte Remote‑Access‑Plattform wie Apache Guacamole oder MeshCentral. Beides sind valide Ansätze mit unterschiedlichen Kompromissen. Dieser Artikel erklärt, warum Sie selbst hosten könnten, stellt die drei relevanten Tools vor, zeigt, wie der operative Aufwand aussieht, und wann Selbst‑Hosting wirklich besser ist als ein verwalteter Dienst.

Kurzfassung: Hosten Sie selbst, wenn Sie strikte Anforderungen an Datenhoheit haben (GDPR, regulierte Branchen, interne Deployments), wenn Sie auf lange Sicht null laufende Lizenzkosten wollen oder wenn Sie grundsätzlich Ihre eigene Infrastruktur betreiben möchten. Verzichten Sie aufs Selbst‑Hosting, wenn Sie ein kleines Team ohne dediziertes DevOps sind, wenn Sie beschaffungsreife Zertifikate benötigen oder wenn Sie lieber $7.99/Monat zahlen, um das Problem zu vermeiden.

Warum selbst hosten?

Datenhoheit

Der Hauptgrund, warum Organisationen selbst hosten. Wenn Sie GDPR, HIPAA oder branchenspezifischen Vorschriften (deutsches Bankwesen, französische Verwaltung, Verteidigungsauftragnehmer) unterliegen, reicht es für Auditoren unter Umständen nicht aus, Remote‑Desktop‑Sitzungen durch einen Drittanbieter‑SaaS zu leiten, selbst wenn dieser starke Verschlüsselung bietet. Selbst‑Hosting auf Infrastruktur, die Sie besitzen (oder in einer von Ihnen kontrollierten Region mieten), entfernt die Drittparteienabhängigkeit vollständig. Unser verwalteter Relay terminiert TLS, daher ist „der Relay gehört uns“ eine deutlich stärkere Compliance‑Position als jemand anderem diese Rolle zu überlassen.

Nur interne Bereitstellungen

Wenn Ihr Remote‑Desktop‑Verkehr Ihr Netzwerk niemals verlassen darf — etwa ein industrielles Steuerungssystem, das vom Internet getrennt ist, oder ein Krankenhaus‑LAN mit striktem Egress‑Filtering — ist ein verwalteter Cloud‑Dienst strukturell ungeeignet. Sie benötigen einen Relay, der im LAN lebt und nur für autorisierte Geräte erreichbar ist.

Kosten bei Skalierung

Bei sehr großen Deployments (1000+ Endpunkte) summieren sich per‑Seat‑Preise schnell. Ein selbst gehosteter Relay auf einem $40/Monat VPS kann bei ausreichender Bandbreite tausende gleichzeitige Sitzungen bedienen. Der Break‑even gegenüber verwalteter Preisgestaltung hängt vom Tool ab, aber auf MSP‑ und Enterprise‑Ebene gewinnt Selbst‑Hosting bei reinen Kosten.

Anpassung und Kontrolle

Selbst‑Hosting erlaubt es Ihnen, den Quellcode (unter den AGPL-3.0‑Pflichten) anzupassen, Branding ohne White‑Label‑Kosten zu ändern und das Relay‑Verhalten an Ihre spezifische Netzwerktopologie anzupassen.

Die Kompromisse, die Sie eingehen

Selbst‑Hosting ist nicht kostenlos. Die Rechnung kommt in Form von DevOps‑Aufwand, nicht unbedingt in monatlichen Kosten. Konkret:

• Server‑Provisionierung und Wartung: Sie benötigen einen Linux‑Server mit öffentlicher IP (für Relay‑Erreichbarkeit), Monitoring, Logrotation, OS‑Patching und wahrscheinlich Backup‑Infrastruktur. Planen Sie 2–4 Stunden/Monat Wartung im Normalbetrieb ein, mehr bei Vorfällen.
• NAT‑ und Firewall‑Konfiguration: Das Relay muss aus dem Internet auf spezifischen Ports erreichbar sein (21115-21119 für RustDesk‑Standardkonfiguration). Bei NAT benötigen Sie Port‑Forwarding von Ihrem Edge‑Router zum Relay‑Host.
• Zertifikatsverwaltung: Wenn Sie TLS auf dem Management‑Interface wollen (sollten Sie), brauchen Sie Let's Encrypt/Certbot oder Ähnliches. Erneuerungen alle 60–90 Tage, automatisiert per Cron.
• Kapazitätsplanung: Ein einzelner Relay kann viel Traffic handeln, aber irgendwann brauchen Sie einen zweiten und dann Load‑Balancing. Sie sind jetzt ein Infrastrukturteam.
• Kein Vendor‑Support: Wenn um 2 Uhr nachts etwas ausfällt, gibt es keine Support‑Hotline. Sie debuggen selbst oder warten, bis die Community reagiert.

Die drei relevanten Tools

RustDesk (und Forks wie Tenvo)

Architektonisch das simpelste der drei. Zwei Binaries: hbbs (Rendezvous‑Server, ~30 MB RAM) und hbbr (Relay, ~50 MB RAM). Beides sind statische Rust‑Binaries ohne externe Abhängigkeiten. Die Einrichtung sieht grob so aus:

# On a Linux VPS with a public IP
wget https://github.com/rustdesk/rustdesk-server/releases/latest/download/rustdesk-server-linux-amd64.zip
unzip rustdesk-server-linux-amd64.zip

# Start hbbs (rendezvous) and hbbr (relay) as services
sudo ./hbbs -r your.public.ip
sudo ./hbbr

# Open ports 21115/tcp, 21116/tcp+udp, 21117/tcp, 21118/tcp, 21119/tcp
sudo ufw allow 21115:21119/tcp
sudo ufw allow 21116/udp

# Point clients at your server: in client settings,
# ID Server = your.public.ip, Relay Server = your.public.ip,
# Public Key = (printed by hbbs on first start, or check id_ed25519.pub)

Der Ressourcenbedarf ist sehr gering; ein $5/Monat DigitalOcean‑Droplet bewältigt dutzende gleichzeitige Sitzungen. Der offizielle RustDesk Pro‑Server (kostenpflichtig) fügt eine Web‑Admin‑Konsole, Audit‑Logs, LDAP/OIDC und Broker‑Features für größere Deployments hinzu.

Apache Guacamole

Anderer Architekturansatz: Guacamole ist eine clientlose HTML5‑Webanwendung. Nutzer verbinden sich über den Browser; das Backend (guacd) übersetzt RDP, VNC und SSH in HTML5‑Canvas/WebSocket‑Streams. Es gibt keinen nativen Client, den man auf der steuernden Maschine installieren muss — praktisch für Support‑Workflows, in denen keine Software installiert werden darf.

Die operative Komplexität ist höher als bei RustDesk: Guacamole läuft als Java + Tomcat mit einer Datenbank (MySQL oder Postgres) für User/Connection‑Management, plus dem guacd‑Daemon. Docker Compose reduziert die Hürden deutlich, aber Sie betreiben 3–4 Container statt zwei Binaries.

Guacamole ist die richtige Wahl, wenn Sie speziell browserbasierten Zugriff ohne Client‑Software wollen. Es ist die falsche Wahl, wenn Sie ein Tool wollen, das NAT‑Traversal zwischen zwei Endpunkten von Haus aus übernimmt; Guacamole geht davon aus, dass der Guacamole‑Server bereits RDP/VNC/SSH‑Zugriff auf die Zielmaschine hat.

MeshCentral

MeshCentral ist eine Node.js‑basierte Remote‑Management‑Plattform von Ylian Saint‑Hilaire (ehemals Intel). Sie unterstützt Remote‑Desktop, Dateiübertragung, Terminal, Web‑Konsole und eine Flottenverwaltungs‑UI. Architektonisch ist es eine einzelne Node‑App + Datenbank (standardmäßig NeDB, Postgres optional), erreichbar über HTTPS.

MeshCentral ist eher ein Flottenverwaltungs‑Tool als ein reines Remote‑Desktop‑Relay — denken Sie an RustDesk + Geräteinventar + Web‑Admin‑UI. Die Einrichtung ist einfach (ein npm install + Konfigurationsdatei) und wurde bereits produktiv von einigen größeren Organisationen, darunter Intel, eingesetzt.

Wo MeshCentral Schwächen zeigt: Die UI ist dicht und nicht besonders poliert, mobile Clients sind schwächer als bei RustDesk, und der Codec/ die Performance für Desktop‑Streaming ist nicht so optimiert wie bei RustDesk oder AnyDesk. Es ist am besten, wenn Sie eine einheitliche Web‑Admin‑Konsole für eine Flotte wollen, weniger ideal als Single‑Purpose‑Remote‑Desktop‑Tool.

Wie ein selbst gehosteter RustDesk‑Relay tatsächlich aussieht

Schritt‑für‑Schritt auf einem Hetzner CX11 ($4/month) Ubuntu 24.04 VPS:

1. Provisionieren Sie den VPS mit einer öffentlichen IPv4. Setzen Sie ein starkes Root‑Passwort und aktivieren Sie SSH‑Key‑Auth.
2. Öffnen Sie die Firewall:

   sudo ufw allow OpenSSH
   sudo ufw allow 21115:21119/tcp
   sudo ufw allow 21116/udp
   sudo ufw enable

3. Installieren Sie die RustDesk‑Server‑Binaries von der GitHub‑Releases‑Seite. Legen Sie sie unter /opt/rustdesk-server/ ab.
4. Erstellen Sie systemd‑Unit‑Dateien für hbbs und hbbr, damit sie beim Reboot neu starten. Das RustDesk‑Wiki hat Referenz‑Units; wir pflegen eine geprüfte Kopie in unserem Hilfecenter.
5. Holen Sie den Public Key, den hbbs beim ersten Start ausgibt. Verteilen Sie ihn an Ihre Clients zusammen mit dem Server‑Hostname.
6. Konfigurieren Sie die Clients: Stellen Sie in den Tenvo‑Client‑Einstellungen ID Server, Relay Server und Public Key ein. Der Client verwendet nun Ihr Relay statt unseres.
7. Optional: TLS‑Termination via Caddy, wenn Sie eine Web‑Admin‑Konsole (RustDesk Pro) auf 443 mit automatisch erneuernden Let's Encrypt‑Zertifikaten betreiben wollen.

Gesamtzeit auf einem frischen VPS: bei erstmaliger Einrichtung etwa 30 Minuten, bei Wiederholung ca. 10 Minuten. Laufende Wartung: apt update && apt upgrade wöchentlich, Relay‑Logs überwachen, bei Memory‑Lecks neu starten (selten). Für Linux‑Deployment‑Details siehe unsere Linux‑Plattformseite.

Tenvos Position zum Selbst‑Hosting

Wir erlauben Ihnen, das Relay auch in den kostenpflichtigen Tarifen selbst zu hosten, wenn Sie das möchten. Der Pro‑Client ist standardmäßig auf unseren verwalteten Relay konfiguriert, aber Sie können jederzeit in den Einstellungen auf Ihr eigenes Relay umstellen. Es gibt keinen „Enterprise‑On‑Prem‑Add‑On“‑Schranken. Das ist Absicht: die AGPL-3.0‑Lizenz gibt Ihnen das Recht zum Selbst‑Hosting, und wir wollen das real halten.

Die meisten Nutzer kümmern sich nicht darum. Unser verwalteter Relay funktioniert einfach, hat globale PoPs und ist im Basistarif enthalten. Wenn Ihre Datenhoheitsanforderung „kein Dritt‑Relay irgendwo im Pfad“ verlangt, hosten Sie selbst. Andernfalls sparen Sie die DevOps‑Zeit und nutzen das verwaltete Relay — dafür zahlt das Abonnement. Für die vollständige Sicherheitsarchitektur, die beiden Deployment‑Optionen zugrunde liegt, siehe unsere Security‑Seite.

Wann Selbst‑Hosting die falsche Entscheidung ist

• Sie sind ein kleines Team ohne DevOps‑Kapazität. Der Wartungsaufwand ist real. Wenn niemand in Ihrem Team die Aufgabe „patcht Linux‑Server“ hat, ist Selbst‑Hosting eine wiederkehrende Belastung.
• Sie benötigen Beschaffungs‑Papiere. Auditoren, die SOC 2‑Berichte verlangen, akzeptieren nicht einfach „wir betreiben unseren eigenen Server“. Verwaltete Dienste mit formalen Zertifikaten sind hier einfacher.
• Sie haben nur 5–20 Endpunkte. Der Break‑even gegenüber einem $7.99/Monat‑Managed‑Plan liegt bei Hunderten Dollar/Jahr eingesparter DevOps‑Zeit. Bei 20 Endpunkten ist Managed eindeutig günstiger.
• Sie tun das nur wegen Kostenersparnis für einen einzelnen Sitz. Ein $5/Monat VPS plus 2 Stunden/Monat Admin‑Aufwand zu marktüblichen Stundensätzen kostet bereits mehr als ein einzelner Managed‑Seat.

Fazit

Selbstgehosteter Remote Desktop ist eine reale Option und für bestimmte Organisationen die richtige. RustDesk (und Forks wie Tenvo) bietet die einfachste ernstzunehmende Selbst‑Hosting‑Route; Guacamole ist die richtige Wahl für browserbasierten Zugriff; MeshCentral ist der Flottenverwaltungs‑Generalist. Der Kompromiss ist immer DevOps‑Zeit versus Geld. Wenn Sie Datenhoheitsanforderungen haben, hosten Sie selbst. Wenn Sie $7.99/Monat haben und lieber Produkt statt Ops bauen möchten, nutzen Sie den verwalteten Relay. Siehe Preise oder laden Sie Tenvo herunter und testen Sie zuerst den verwalteten Flow — Sie können jederzeit durch Ändern einer Konfigurationszeile auf Selbst‑Hosting migrieren.

FAQ

Können Sie den Relay selbst hosten und trotzdem die Tenvo‑Client‑UI / Konten verwenden?
Ja. Zeigen Sie den Client in den Einstellungen auf Ihr Relay. Account‑Funktionen, die vom Tenvo‑Control‑Plane abhängen (Abrechnung, Team‑Management), funktionieren weiterhin; nur der Sitzungs‑Traffic läuft über Ihr Relay.

Welche Hardware benötigen Sie für ein selbst gehostetes RustDesk‑Relay?
Ein kleiner VPS: 1 vCPU, 1 GB RAM, 1 TB/Monat Bandbreite reicht für dutzende gleichzeitige Sitzungen. Hetzner CX11, DigitalOcean basic oder AWS t4g.nano funktionieren alle. Bandbreite ist in der Regel die Beschränkung bei Skalierung, nicht CPU.

Unterstützt selbst gehostetes RustDesk 2FA / SSO?
Der freie Open‑Source‑Server (hbbs/hbbr) unterstützt das nicht. Der RustDesk Pro‑Server (kostenpflichtig, separate Lizenz) fügt Web‑Konsole, OIDC und Audit‑Logs hinzu. Tenvos Pro‑Tier im Managed‑Angebot enthält 2FA standardmäßig.

Können Sie das Relay auf AWS Lightsail / Cloudflare / etc. hosten?
Jeder Provider mit einer öffentlichen IPv4 und der Möglichkeit, benutzerdefinierte UDP/TCP‑Ports zu öffnen, funktioniert. Cloudflares Standard‑Proxy terminiert TCP nur auf Port 443; Sie benötigen Cloudflare Spectrum (kostenpflichtig) oder einen dedizierten TCP‑Listener für die RustDesk‑Ports.

Wie wirkt sich Selbst‑Hosting auf GDPR aus?
Wenn Ihr Relay in der EU steht und Ihre Daten die EU nicht verlassen, greifen die GDPR‑Regeln zu grenzüberschreitenden Datenübermittlungen nicht. Das ist der wichtigste Grund, warum EU‑Öffentliche Hand und Gesundheits‑Deployments häufig Selbst‑Hosting wählen.