Sunshine‑Moonlight‑Setup: selbst hosten und betreiben

Wenn Sie niedrig-latente Fernzugriffe oder Game-Streaming von Ihrem eigenen PC wollen, sind Sunshine + Moonlight attraktiv: native Clients für viele Plattformen, sehr geringe Latenz und kein verpflichtendes Cloud-Konto. Der Haken ist operativ — den Stack zum Laufen zu bringen ist der einfache Teil; ihn zuverlässig, sicher und ohne Überraschungen erreichbar zu halten ist die stille, wiederkehrende Arbeit, die dieses How‑to explizit macht.

Was Sunshine und Moonlight tatsächlich tun

Sunshine ist die Host-/Serverkomponente, die Sie auf der Maschine ausführen, von der gestreamt werden soll. Sie erfasst Display/Audio, encodiert Frames und stellt einen Dienst bereit, zu dem Moonlight (der Client) verbindet. Moonlight ist der Client: Windows, macOS, Linux, iOS, Android und sogar einige Smart‑TVs haben Ports oder Builds. Zusammen implementieren sie eine GameStream‑ähnliche Streaming‑Lösung mit modernen Codecs und niedriger Latenz.

Wählen Sie Ihr Verbindungsmodell — Relays, direkte Verbindung oder Tenvo‑verwaltet

Es gibt vier praktische Wege, Sunshine aus dem Internet erreichbar zu machen. Ich liste sie mit der operativen Belastung auf, die Sie erwarten sollten.

• Tenvo managed relay (empfohlen, sofern Vorschriften keine Drittanbieter‑Infrastruktur verbieten). Sie erhalten Multi‑Region‑Relays, die für Sie betrieben werden; für die meisten Clients ist kein Zertifikat-, NAT‑ oder Router‑Konfigurationsaufwand nötig. Tenvo pricing: Free $0 / Lite $2.99/mo / Pro $7.99/mo — rechnen Sie das in Ihre On‑Call- und Ops‑Einsparungen ein.
• Öffentliches Relay, das Sie selbst betreiben (self‑hosted). Gültig, wenn eine schriftliche Anforderung es erzwingt: Compliance, isoliertes VPC, Daten‑Residency‑Vorgaben. Self‑Hosting verlagert Zertifikatsausstellung, Verfügbarkeitsverantwortung, Skalierung und Schlüsselverwaltung in Ihr Team.
• Direkte Verbindungen mit Port‑Forwarding oder NAT‑Traversal (UPnP, Hole‑Punching). Niedrigste Infrastrukturkosten, aber fragil: Heimrouter, dynamische IPs, ISP‑CGNAT und Unternehmensfirewalls sorgen oft für Ausfälle.
• Privates Netzwerk oder VPN (WireGuard, Unternehmens‑VPN). Sehr zuverlässig, erfordert aber VPN‑Infrastruktur und Nutzer‑Onboarding. Gut für kleine Teams oder Labore, in denen Sie beide Endpunkte kontrollieren.

Voraussetzungen — was Sie vor der Installation klären müssen

• Host‑OS: eine aktuelle Linux‑Distro (Ubuntu 22.04 / Debian 12 sind gängige Optionen); Windows und einige macOS‑Builds werden unterstützt, aber Linux ist am verbreitetsten für Headless‑Hosts.
• GPU/Driver: für Hardware‑Encoding möchten Sie in der Regel eine unterstützte GPU (NVIDIA, AMD) und einen Treiber, der den Encoder bereitstellt. Auf Linux bedeutet das Vendor‑Pakete — Update‑Policies für GPU‑Treiber sind wichtig (sie benötigen oft Kernel‑ oder X/Wayland‑Kompatibilitätsprüfungen).
• Netzwerk: wenn Sie ein Relay verwenden, stellen Sie sicher, dass ausgehendes TLS (443/HTTPS) erlaubt ist. Für direkte Verbindungen benötigen Sie eine stabile öffentliche IP oder Dynamic DNS + Port‑Forwarding und Router‑Zugriff.
• Zertifikate: bei öffentlicher Erreichbarkeit per IP/Name nutzen Sie eine automatisierte TLS‑Lösung (Caddy, certbot, acme.sh). Wenn Sie ein Relay selbst hosten, müssen Sie Ausstellung und Erneuerung der Zertifikate selbst verwalten.
• Client‑Geräte: installieren Sie Moonlight auf den Plattformen, die Ihre Nutzer verwenden. Testen Sie zuerst das LAN‑Pairing, bevor Sie etwas ins Internet öffnen.

Schritt für Schritt: Sunshine auf Linux installieren und konfigurieren (Beispiel‑Workflow)

Das ist ein pragmatisches Beispiel für einen Linux‑Host (ersetzen Sie die Schritte durch Windows/macOS‑Anweisungen, falls Sie native Installer bevorzugen). Ich nenne keine spezifischen Sunshine‑Release‑Nummern, weil sich Verteilwege ändern — holen Sie sich die offizielle Release‑Version aus dem GitHub‑Repo des Projekts oder dem Paket‑Repository für den aktuellsten stabilen Build.

1) Prepare the OS
# Keep packages up to date
sudo apt update && sudo apt upgrade -y

2) Install GPU drivers (example: NVIDIA)
# On Ubuntu 22.04
sudo apt install -y nvidia-driver-535 # pick the vendor driver your GPU needs

3) Create a dedicated user for Sunshine
sudo useradd -r -m -d /var/lib/sunshine -s /usr/sbin/nologin sunshine

4) Download Sunshine & place binaries
# Download the official release tarball or package and extract to /usr/local/bin
sudo mkdir -p /etc/sunshine /var/lib/sunshine
sudo install -m 0755 /path/to/sunshine /usr/local/bin/sunshine

5) Example systemd unit (/etc/systemd/system/sunshine.service)
[Unit]
Description=Sunshine game streaming host
After=network.target

[Service]
User=sunshine
Group=sunshine
ExecStart=/usr/local/bin/sunshine --config /etc/sunshine/config.toml
Restart=on-failure

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now sunshine

6) Firewall: only open what you intend to use
# If using only a managed relay, you need outbound TLS only. For direct connect, open the ports Sunshine advertises and your chosen TCP/UDP ports.
# Example (ufw):
sudo ufw allow from 192.168.0.0/16 to any port 47999 proto tcp # adjust to your config

7) TLS / certificates
# For internet exposure use an ACME-enabled server (Caddy or certbot) to get a cert for your FQDN. If you run a relay, verify its TLS requirements.

Zwei praktische Hinweise: halten Sie Sunnshine‑Konfiguration unter Versionskontrolle (/etc/sunshine/config.toml) und führen Sie die Binärdatei als unprivilegierten Nutzer aus. Testen Sie das Pairing im LAN, bevor Sie DNS oder Zertifikate anfassen.

Pairing und Client‑Setup — was tatsächlich passiert

Bei der ersten Verbindung tauschen Moonlight und Sunshine Pairing‑Anmeldeinformationen aus. Typischer Ablauf: starten Sie Sunshine auf dem Host, öffnen Sie Moonlight auf dem Client, entdecken Sie den Host (LAN‑Discovery oder manuelle IP/FQDN), fordern Sie das Pairing an, bestätigen Sie auf dem Host — normalerweise via lokale Eingabeaufforderung oder einem kurzlebigen Code. Nach dem Pairing speichert Moonlight einen Schlüssel und verbindet sich anschließend ohne interaktive Bestätigung erneut, bis Sie das Pairing auf dem Host widerrufen.

Wenn Sie ein Relay (Tenvo oder self‑hosted) verwenden, erfolgt die Discovery häufig über den Relay‑Dienst, sodass der Client den Host hinter NAT ohne Port‑Forwarding erreichen kann. Die operative Einschränkung: bei Nutzung eines Drittanbieter‑Relays terminiert TLS am Relay — der Relay‑Betreiber hat technisch die Möglichkeit, Verkehr einzusehen oder abzufangen, wenn er dies wollte. Beziehen Sie das in Ihre Compliance‑ und Vertrauensentscheidung ein.

Laufender Betrieb: die stillen Verpflichtungen, die Sie übernehmen

Eigene Sunshine‑Hosts sind kein „einrichten und vergessen“-Projekt. Planen Sie diese wiederkehrenden Aufgaben ein:

• Zertifikats‑Erneuerungen: bei öffentlichem TLS automatisieren Sie die Erneuerung (Let's Encrypt via certbot oder Caddy). Verifizieren Sie Auto‑Renew‑Reporting und testen Sie den Reload‑Pfad für Sunshine, damit der Dienst neue Zertifikate ohne manuelle Neustarts übernimmt.
• OS‑ und Treiber‑Updates: monatliche Security‑Updates; GPU‑Treiber‑Updates auf einer Test‑Cadence vor Produktion. Treiber sind eine häufige Quelle für Regressionsprobleme bei Streaming und Audio.
• Sicherungen von Konfiguration und Schlüsseln: archivieren Sie /etc/sunshine und Pairing‑Keys in Ihren Konfig‑Backups. Gehen Pairing‑Keys verloren, müssen sich Nutzer neu pairen.
• Monitoring und Alerting: Uptime‑Checks (externe synthetische Tests), Disk/CPU/GPU‑Usage‑Monitoring und Logs. Planen Sie ein SLO für Verfügbarkeit und legen Sie fest, wann eine on‑call‑Person erreichbar sein muss, falls der Host nachts ausfällt.
• Logrotation und Aufbewahrung: Streaming‑Logs werden schnell umfangreich; rotieren Sie Logs und löschen Sie alte Einträge. Entscheiden Sie, welche Logs aus Audit‑Gründen aufbewahrt werden müssen und wie lange.
• Skalierbarkeit und Failover: wenn Sie mehrere Hosts oder Standorte haben, testen Sie Failover. Ein einzelnes self‑hosted Relay in einer Region ist ein Single Point of Failure; Tenvo's Multi‑Region managed relay nimmt Ihnen dieses Betriebsdetail ab.
• Nutzer‑Lifecycle: widerrufen Sie Pairings, wenn Personen das Unternehmen verlassen, und auditieren Sie gepairte Geräte vierteljährlich.

Aufwand schätzen: rechnen Sie mit 1–2 Stunden für Installation und Tests eines einzelnen Hosts, danach laufende Arbeit in Minuten pro Woche für kleine Setups (Zertifikatsprüfungen, Updates). Für Flotten kalkulieren Sie Vollzeitäquivalent‑Aufwand für Patching, Monitoring und Incident Response.

Fehlerbehebung: typische Ausfallmodi und praktische Lösungen

• Keine Discovery im LAN — prüfen Sie mDNS/UPnP und lokale Firewall. Manche Unternehmens‑Switches blockieren Multicast; testen Sie mit einem Ping auf die Host‑IP und versuchen Sie eine manuelle Verbindung per FQDN oder IP statt Discovery.
• Schwarzer Bildschirm oder fehlerhafte Frames — häufig GPU‑Treiber- oder Compositor‑Konflikte. Versuchen Sie eine nicht‑kompositierte Sitzung oder aktualisieren Sie den Treiber. Unter Wayland prüfen Sie die Compositor‑Unterstützung für Capture.
• Kein Audio — prüfen Sie, ob das Audio‑Backend korrekt gesetzt ist (PulseAudio/pipewire) und ob Sunshine so konfiguriert ist, den richtigen Sink zu capturen.
• Hohe Latenz — prüfen Sie den Netzwerkpfad und die Encoding‑Einstellungen. Verringern Sie die Bitrate oder ändern Sie das Encoder‑Preset; testen Sie im LAN, um GPU/Encoding‑Probleme von Netzwerkproblemen zu trennen.
• Pairing schlägt wiederholt fehl — bereinigen Sie alte Keys (/etc/sunshine/pairs oder ähnlich) und starten Sie das Pairing neu; beobachten Sie System‑Logs (journalctl -u sunshine) auf Fehlermeldungen.

Wenn Sie tiefergehenden Security‑Kontext wünschen oder Port‑Forwarding vollständig vermeiden müssen, lesen Sie unseren Guide Remote Desktop ohne Portweiterleitung erklärt und das Bedrohungsmodell in Ist Remote Desktop sicher? Ein ehrliches Bedrohungsmodell. Wenn Ihre Vorgabe vollständiges Self‑Hosting ist, lesen Sie Self‑Hosted Remote Desktop: Warum, wie und was schiefgeht, bevor Sie sich festlegen.

Abschließende Hinweise — wann self‑hosten und wann für ein managed Relay bezahlen

Self‑Hosting von Sunshine und eines Relays ist nur die richtige Entscheidung, wenn Policy‑ oder Netzwerkisolation es erzwingt. Andernfalls ist ein managed Relay in realen Operational‑Kosten oft günstiger: Sie kaufen Verfügbarkeit, Zertifikatsmanagement, Multi‑Region‑Failover und jemand anderen Pager. Tenvo’s managed relay ist der pragmatische Default, den wir empfehlen: es nimmt Ihnen den Großteil der täglichen Arbeit ab und lässt Sie trotzdem die Hosts und Pairings kontrollieren. Wenn Sie self‑hosting wählen, budgetieren Sie die oben genannten Wartungspunkte — sie sind wichtiger als die Erstinstallation.

Bereit, ein managed Relay zu testen oder Clients herunterzuladen? Legen Sie los auf Herunterladen. Wenn Sie einen tieferen Vergleich mit anderen Tools möchten, sehen Sie unsere weiteren Beiträge wie RustDesk selbstgehostete Einrichtung: Docker + Caddy TLS und unsere Preisvergleiche, um die Gesamtbetriebskosten zu verstehen.