· RustDesk Team · Anleitungen · 4 Min. Lesezeit
Warum Sie Ihre Remote-Desktop-Software selbst hosten sollten
Warum Teams, die TeamViewer und AnyDesk den Rücken kehren, sich für selbst gehostetes Remote-Desktop entscheiden: Datenkontrolle, planbare Kosten und keine Cloud dazwischen.
Die meisten Remote-Desktop-Tools werden auf eine bestimmte Weise verkauft: als Cloud-Abonnement, bei dem die Server des Anbieters jede Sitzung vermitteln – und oft auch weiterleiten. Es gibt einen anderen Weg, Remotezugriff zu betreiben, und der ist nicht neu – er wird nur weniger beworben, weil kein wiederkehrendes Cloud-Abonnement daran hängt. Es ist die Entscheidung, Ihre Remote-Desktop-Software selbst zu hosten: den Server, der Verbindungen koordiniert und Datenverkehr weiterleitet, wenn eine direkte Verbindung fehlschlägt, auf einer Infrastruktur zu betreiben, die Sie selbst kontrollieren. Dieser Artikel plädiert für dieses Modell und verwendet RustDesk als konkretes Beispiel.
Was „Remote-Desktop selbst hosten“ tatsächlich bedeutet
Der Preis der reinen Cloud-Bequemlichkeit ist, dass Ihre Geräteliste, Ihre Verbindungsmetadaten und manchmal auch Ihr Sitzungsverkehr über einen Dritten laufen, abhängig von dessen Verfügbarkeit, dessen Preisgestaltung und dessen Sicherheitsniveau.
Selbst-Hosting kehrt dieses Verhältnis um. Mit RustDesk Server Pro laufen der ID-/Rendezvous-Server, das Relay, die Konsole und die gespeicherten Deployment-Daten auf Ihrer eigenen Infrastruktur. Direkte Sitzungen fließen weiterhin zwischen den Endpunkten; weitergeleitete Sitzungen nutzen Ihr konfiguriertes Relay. RustDesk ist Open Source (AGPL), und der kostenlose Community-Server läuft zeitlich unbegrenzt.
Nur-Cloud vs. selbst gehostet im Überblick
| Typisches Nur-Cloud-Tool | Selbst gehostet (RustDesk Server Pro) | |
|---|---|---|
| Wo Sitzungen vermittelt werden | Cloud des Anbieters | Ihre eigene On-Premise-Box oder VPS |
| Datenstandort | Vom Anbieter kontrolliert | Serverseitige Dienste laufen auf Infrastruktur, die Sie kontrollieren; Endpunkt-Routen spielen weiterhin eine Rolle |
| Limits für gleichzeitige Verbindungen | Oft pro Kanal/Lizenzplatz | Standard-Pläne unbegrenzt; Customized V2 nutzungsbasiert abgerechnet |
| Preismodell | Cloud-Abo pro Lizenzplatz/Kanal | Pro Login-Benutzer + pro verwaltetem Gerät (Preise) |
| Quellcode | Geschlossen | Open Source (AGPL), auditierbar |
| Abhängigkeit von Ausfällen | Verfügbarkeit des Anbieters | Ihr eigener Betrieb |
| Wer betreibt den Server | Anbieter | Sie |
Selbst-Hosting bedeutet nicht, auf Skalierbarkeit oder Funktionsumfang zu verzichten. RustDesk veröffentlicht Planungshinweise für große Geräteflotten für Teams, die größere Bestände unterstützen müssen. Für MSPs und die interne IT gibt es eine selbst gehostete Web-Konsole, einen Generator für individuell gebrandete Clients sowie Gerätegruppen plus ein gemeinsames Adressbuch für benutzerbasierte Zugriffskontrolle. LDAP/SSO (OIDC) ist ab dem Basic-Plan verfügbar.
Was der Betrieb des Servers tatsächlich bedeutet
Diese Kontrolle geht mit etwas operativem Aufwand einher – weniger, als die meisten Teams erwarten, und größtenteils einmalig. Hier die konkrete Realität:
- Einen Host bereitstellen. Die Hardwareanforderungen von RustDesk sind gering, sodass eine bescheidene Linux-VM – vor Ort oder ein preiswerter VPS – die ID-/Rendezvous- und Relay-Dienste betreiben kann. Dimensionieren Sie sie nach Ihrer Geräteanzahl und danach, wie viel Datenverkehr am Ende weitergeleitet statt Peer-to-Peer übertragen wird.
- Öffnen Sie nur die Ports, die Sie tatsächlich nutzen. Native RustDesk-Clients benötigen TCP 21115-21117 und UDP 21116 für NAT-Tests, Verbindungsdienste, Registrierung, Heartbeat und Relay. Geben Sie nicht den gesamten Bereich 21114-21119 frei. TCP 21118-21119 sind WebSocket-Backends, und TCP 21114 ist das Backend der Pro-HTTP-API/Konsole. Wenn ein HTTPS/WSS-Reverse-Proxy der Pro-API und den WebSocket-Diensten vorgeschaltet ist, geben Sie für diesen Datenverkehr öffentlich nur TCP 443 frei und halten Sie 21114 sowie 21118-21119 intern. Öffentliches 443 ersetzt nicht die Kern-Ports der nativen Clients, wenn sich auch native Clients verbinden. Siehe die offizielle Port-Referenz.
- TLS einrichten. Terminieren Sie HTTPS und WSS am Reverse-Proxy, sodass Zugangsdaten, API-Aufrufe und der Datenverkehr des Browser-Clients über das öffentliche TCP 443 laufen, anstatt die Konsole/API im Klartext-HTTP oder die rohen WebSocket-Backends offenzulegen.
- Sichern Sie Ihre Daten. Der Server enthält Ihr Geräteinventar, Benutzerkonten, das Adressbuch und die Zugriffsregeln. Planen Sie regelmäßige Backups – und testen Sie tatsächlich, dass Sie daraus wiederherstellen können.
- Halten Sie einen Patch-Rhythmus ein. Im Laufe der Zeit erscheinen neue Server-Builds, und das darunterliegende Betriebssystem liegt in Ihrer Verantwortung. Legen Sie fest, wer Updates einspielt und wie oft.
- Überwachen Sie ihn. Der koordinierende Dienst gehört jetzt Ihnen, also überwachen Sie Verfügbarkeit, Speicherplatz und Relay-Durchsatz und verantworten Alarmierung und Wiederherstellung selbst.
Nichts davon ist exotisch, und das meiste davon ist einmalige Einrichtung. Sollte irgendwann eine Frage aufkommen, hilft Ihnen der RustDesk-Support weiter.
So bewerten Sie Selbst-Hosting
- Beginnen Sie mit dem Community-Server. Der Kern steht unter AGPL – setzen Sie den kostenlosen Open-Source-Server noch heute Nachmittag auf, prüfen Sie ihn und betreiben Sie ihn so lange Sie möchten, kostenlos.
- Brauchen Sie den Funktionsumfang von Pro? Die aktuellen Tarife finden Sie unter rustdesk.com/pricing, und [email protected] teilt Ihnen mit, welche Testoptionen derzeit verfügbar sind.
- Lieber erst zuschauen statt installieren? Es gibt eine vollständige Video-Demo auf dem RustDesk-YouTube-Kanal.
Wenn Preiserhöhungen, geschlossener Code oder eine Cloud, die Sie nicht kontrollieren, der Grund dafür waren, dass Sie sich umzusehen begannen, ist Selbst-Hosting die strukturelle Lösung, kein bloßer Rabatt. Für ein Team, das bereits Infrastruktur betreibt, ist das ein nächster Schritt, kein Sprung: Betreiben Sie den Server, besitzen Sie die Daten, kontrollieren Sie die Kosten.
Frequently asked questions
Was bedeutet es, Remote-Desktop-Software selbst zu hosten?
Es bedeutet, den Server, der Verbindungen koordiniert und Datenverkehr weiterleitet, wenn eine direkte Verbindung fehlschlägt, auf einer Infrastruktur zu betreiben, die Sie selbst kontrollieren, anstatt Sitzungen über die Cloud eines Anbieters zu leiten. Mit RustDesk Server Pro laufen der ID-/Rendezvous-Server, das Relay, die Konsole und die gespeicherten Deployment-Daten auf Ihrer eigenen Infrastruktur.
Was bedeutet der Betrieb eines selbst gehosteten RustDesk-Servers konkret?
Die Hardwareanforderungen sind gering, und der Großteil der Arbeit fällt nur einmalig an: Sie stellen einen kleinen Linux-Host bereit, öffnen nur die Ports, die Sie tatsächlich nutzen (native Clients benötigen TCP 21115-21117 und UDP 21116), richten TLS an einem Reverse-Proxy ein und planen Backups; danach handelt es sich um routinemäßiges Patchen und Monitoring, wobei der RustDesk-Support zur Verfügung steht, falls Sie auf ein Problem stoßen.
Hilft Selbst-Hosting bei Datenstandort und DSGVO-Konformität?
Ja – es gibt Ihnen hier echte Kontrolle: Sie entscheiden, wo Rendezvous, Relay, Konsole und Gerätedaten laufen. Es ist jedoch eher eine Grundlage als eine absolute Garantie, da direkte Verbindungen weiterhin zwischen den Endpunkten fließen – ob der Datenverkehr im eigenen Land bleibt und die DSGVO-Pflichten erfüllt werden, hängt also auch davon ab, wie Sie das Deployment routen und betreiben.
Ist Selbst-Hosting für jedes Team die richtige Wahl?
Selbst-Hosting eignet sich für Teams, die Kontrolle über ihre Daten und Infrastruktur haben möchten. Es erfordert den Betrieb eines Servers – überschaubar und größtenteils einmalig einzurichten –, sodass ein verwalteter SaaS-Dienst das alternative Modell ist, falls Sie lieber überhaupt keinen Server betreiben möchten. RustDesk Server Pro ist jedoch bewusst als selbst gehostete Lösung konzipiert, damit Ihre Daten auf Ihrer eigenen Infrastruktur bleiben, ohne Cloud eines Anbieters dazwischen – und für Teams, die bereits Infrastruktur betreiben, ist genau diese Eigenverantwortung der springende Punkt.
