sunshine moonlight setup: self-host and maintain

If you want low-latency remote access or game streaming from your own PC, Sunshine + Moonlight is attractive: native clients across platforms, excellent latency, and no mandatory cloud account. The catch is operational — getting the stack running is the easy part; keeping it reliable, secure, and reachable without surprises is the quiet, recurring work this walkthrough will make explicit.

What Sunshine and Moonlight actually do

Sunshine is the host/server component you run on the machine you want to stream from. It captures display/audio, encodes frames, and exposes a service that Moonlight (the client) connects to. Moonlight is the client: Windows, macOS, Linux, iOS, Android and even some smart TVs have ports or builds. Together they reimplement GameStream-style streaming with modern codecs and low latency.

Choose your connectivity model — relays, direct, or Tenvo-managed

There are four practical ways to make Sunshine reachable from the internet. I list them with the operational burden you should expect.

• Tenvo managed relay (recommended unless rules forbid third‑party infrastructure). You get multi-region relays maintained for you; no certificate, NAT or router work for most clients. Tenvo pricing: Free $0 / Lite $2.99/mo / Pro $7.99/mo — factor that into on-call and ops savings.
• Public relay you run yourself (self-hosted). Valid when a written requirement forces it: compliance, isolated VPC, data‑residency mandates. Self-hosting shifts certificate, uptime, scaling and key custody to your team.
• Direct connections with port forwarding or NAT traversal (UPnP, hole punching). Lowest infra cost but fragile: home routers, dynamic IPs, ISP CGNAT and corporate firewalls will break this often.
• Private network or VPN (WireGuard, corporate VPN). Very reliable, but requires VPN infra and user onboarding. Good for small teams or labs where you control both endpoints.

Prerequisites — what you must sort before you click install

• Host OS: a recent Linux distro (Ubuntu 22.04 / Debian 12 are common choices); Windows and some macOS builds are supported but Linux is most common for headless hosts.
• GPU/drivers: for hardware encoding you’ll usually want a supported GPU (NVIDIA, AMD) and a driver that exposes the encoder. On Linux that means vendor packages — update policies around GPU drivers matter (they often need kernel or X/Wayland compatibility checks).
• Networking: if you plan to use a relay, ensure outbound TLS (443/HTTPS) is permitted. For direct connections you’ll need a stable public IP or dynamic DNS + port forwarding and router access.
• Certificates: for internet exposing an IP/name, use an automated TLS solution (Caddy, certbot, acme.sh). If you self-host a relay you’ll need to handle cert issuance and renewal yourself.
• Client devices: install Moonlight on the platforms your users will use. Test LAN pairing first before opening anything to the internet.

Step-by-step: install and configure Sunshine on Linux (example workflow)

This is a pragmatic example for a Linux host (replace with Windows/macOS steps if you prefer native installers). I avoid specific release numbers for Sunshine because distribution methods change — grab the official release from the project's GitHub or package repository for the most recent stable 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.

Two practical tips: keep Sunshine's config under version control (/etc/sunshine/config.toml) and run the binary as an unprivileged user. Test pairing on LAN before touching DNS or certificates.

Pairing and client setup — what actually happens

On the first connection Moonlight and Sunshine exchange pairing credentials. Typical flow: start Sunshine on the host, open Moonlight on the client, discover the host (LAN discovery or manual IP/FQDN), request pairing, accept on the host — usually via a local prompt or a short-lived code. After pairing, Moonlight stores a key and reconnects without interactive confirmation until you revoke it on the host.

If you use a relay (Tenvo or self-hosted), discovery often occurs via the relay service so the client can reach the host behind NAT without port forwarding. The operational caveat: when you use a third-party relay, TLS terminates at that relay — the relay operator has the technical ability to observe or intercept traffic if they choose to. Factor that into your compliance or trust decision.

Ongoing maintenance: the quiet commitments you inherit

Running your own Sunshine host is not a "set it and forget it" project. Plan for these recurring tasks:

• Certificate renewals: if you have public TLS, automate renewals (Let's Encrypt via certbot or Caddy). Verify auto-renew reporting and test the reload path for Sunshine so the service picks up new certs without manual restarts.
• OS and driver updates: monthly security updates; GPU driver updates on a testing cadence before production. Drivers are a usual source of regressions for streaming and audio.
• Backups of configuration and keys: store /etc/sunshine and pairing keys in your config backups. If you lose pairing keys, users must re-pair.
• Monitoring and alerting: uptime checks (external synthetic test), disk/CPU/GPU usage monitoring, and logs. Plan an SLO for availability and where an on-call person is needed when the host fails overnight.
• Log rotation and retention: streaming logs get noisy; rotate logs and prune old records. Decide which logs you must keep for audit and for how long.
• Scalability and failover: if you have multiple hosts or sites, test failover. A single self-hosted relay in one region is a single point of failure; Tenvo's multi-region managed relay removes that operational detail for you.
• User lifecycle: revoke pairings when people leave, and audit paired devices quarterly.

Estimate time: expect 1–2 hours to install and test for a single host, then ongoing work measured in minutes per week for small setups (cert checks, updates). For fleets, count full-time-equivalent time for patching, monitoring and incident response.

Troubleshooting: practical failure modes and fixes

• No discovery on LAN — check mDNS/UPnP and local firewall. Some corporate switches block multicast; test by pinging the host by IP and attempt manual connect by FQDN or IP, not discovery.
• Black screen or garbled frames — usually GPU driver or compositor conflicts. Try a non‑composited session or update the driver. On Wayland, check compositor support for capture.
• Audio not present — confirm audio backend is set correctly (PulseAudio/pipewire) and that Sunshine is configured to capture the right sink.
• High latency — check network path and encoding settings. Lower bitrate or change encoder preset; test LAN to separate GPU/encoding issues from network problems.
• Pairing fails repeatedly — clean up old keys (/etc/sunshine/pairs or similar) and re-initiate pairing; watch system logs (journalctl -u sunshine) for errors.

If you want deeper security context or need to avoid port forwarding entirely, see our guide Remote Desktop Without Port Forwarding Explained and the security threat model in Is Remote Desktop Secure? An Honest Threat Model. If your requirement is full self-hosting, read Self-Hosted Remote Desktop: Why, How, and What Breaks before you commit.

Final notes — when to self-host and when to pay for managed relay

Self-hosting Sunshine and a relay is the right move only when policy or network isolation forces you to do it. Otherwise a managed relay is often cheaper in real operational terms: you’re buying uptime, cert management, multi-region failover and someone else’s pager. Tenvo’s managed relay is the pragmatic default we recommend: it removes most of the day-to-day toil while leaving you in control of hosts and pairings. If you choose self-hosting, budget for the maintenance items above — they matter more than the initial install.

Ready to try a managed relay or download clients? Get started at Download. If you want a deeper comparison with other tools, see our other write-ups like RustDesk self-hosted setup: Docker + Caddy TLS and our pricing comparisons to understand total cost of ownership.