Sunshine's encoder matrix decides your GPU before it decides your settings

The encoding table decides your GPU before any setting does

Sunshine is the host, Moonlight is the client, and the host is what you install. It runs on FreeBSD, Linux, macOS and Windows, and you reach it from any Moonlight client on a variety of devices. Configuration and client pairing happen in a web UI, and pairing works from the local server or from any mobile device.

The approach it takes is the inverse of vendor-run cloud gaming. Instead of the vendor running the encoder and you connecting to their machine, the encoder runs on hardware you own. What you take on is the whole compatibility surface, and the README spends most of its length on three tables: gamepad emulation, encoding API and screen capture.

Read the encoding table first. It names AMF for AMD, NVENC for NVIDIA, QuickSync for Intel, Media Foundation for Qualcomm, VAAPI, Video Toolbox, Vulkan Video and Software, crossed against the four platforms. That grid is where your hardware stops being an abstract question.

An AMD card on Linux is a VAAPI card, not an AMF card

The per-vendor rows are where people get surprised. AMF, the AMD encoder, is marked for Windows only. So is QuickSync for Intel, and so is Media Foundation for Qualcomm. NVENC is the one vendor API that reaches two platforms, Linux and Windows.

The open paths are VAAPI and Vulkan Video. VAAPI is marked for FreeBSD and Linux with AMD and Intel, and for Linux with NVIDIA. Video Toolbox is the macOS row, listed for both Apple and Intel. Software encoding is the one cell that is filled on every platform, which means a host always works and a host with a mismatched GPU quietly falls back to the CPU.

The practical consequence is that an AMD box on Linux is a VAAPI box, and an Intel box on Linux has no row of its own. Whether that matters depends on the encoder your distribution's drivers expose, and the table does not say.

FreeBSD has VAAPI and no vendor encoder, and every gamepad row is partial

Look down the FreeBSD column and the shape of the support changes. VAAPI carries it, with AMD and Intel. Vulkan Video is marked partial for AMD and for Intel and absent for NVIDIA. AMF, Media Foundation, NVENC and QuickSync are all blank, so hardware encoding on FreeBSD means VAAPI or a partial Vulkan path, with software encoding as the guaranteed floor.

The gamepad table is harsher on the same platform. Generic, DualShock / DS4, DualSense / DS5, Nintendo Switch Pro, Xbox 360, Xbox One and Xbox Series are all marked partial on FreeBSD, and the note attached to that marker names what is missing: motion, touchpad input, battery state, RGB LEDs, adaptive triggers, and raw HID output reports. A FreeBSD host can present a controller and lose half of what a controller can do.

Linux has the same seven rows marked fully supported, which makes the FreeBSD column the clearest example of what a partial marker costs in practice.

The partial marker is defined for gamepads and left undefined for encoders

Those tables use three symbols, and only one of them is explained. Under the gamepad table, footnote 1 attaches a specific list of missing features to the partial marker, footnote 2 says macOS requires the separately installed and licensed Virtual HID Broker, and footnote 3 says the same for Windows, adding that Xbox 360 and DualShock 4 can also use ViGEmBus.

The encoding table has no footnotes. Its partial marks sit on Vulkan Video for AMD on FreeBSD, for Intel on FreeBSD and Linux, and for NVIDIA on Linux, and nothing in the file says which capabilities are absent in those cells. Someone planning around a partial Vulkan Video path on Linux has to go to the documentation on Read the Docs to learn what the marker buys them.

The screen capture table is blunter. Windows.Graphics.Capture is partial on Windows, and its two sub rows split by mode: Portable is supported and Service is marked as not supported. NvFBC is marked Linux only and noted as X11 only.

The web UI is its own npm package with every dependency pinned exactly

The browser interface you configure Sunshine with is not part of the C++ binary. It is a separate package named @lizardbyte/sunshine, described as prebuilt web UI assets for the Sunshine game-stream host, licensed GPL-3.0-only, and its only published file is build/assets/web/.

Its dependencies are pinned to exact versions with no ranges: vue 3.5.43, vue-router 5.3.1, vue-i18n 11.4.12, bootstrap 5.3.8, marked 18.0.12, date-fns 4.4.0, @lucide/vue 1.48.0 and vue3-simple-icons 16.10.0. The build is Vite, the tests are Vitest run with coverage, and there is a script that builds in watch mode plus one that serves a fixture directory. The vue-i18n dependency and a crowdin.yml at the repository root are why the interface is translated.

For a user this means the UI has its own update schedule, separate from the host binary, and a mismatch between the two is the first thing to check when the web interface stops matching the options the host exposes.

The Python layer is packaging, and it resolves dependencies from inside the tree

There is a pyproject.toml in the root and it is easy to mistake for part of the server. It is not. The project is named Sunshine, version 0.0.0, and its description is Python tooling for Sunshine. It requires Python 3.14 or newer, and its single runtime dependency is lizardbyte-common with the c extra.

The rest lives in dependency groups: glad pulls in glad2 for the GL loader generator, and flatpak pulls in flatpak_node_generator and flatpak_pip_generator. None of those come from an index. The uv sources table points every one of them at a path inside this repository, including third-party/glad and third-party/lizardbyte-common, and uv.lock sits at the root beside it.

So a fresh clone cannot resolve the Python tooling on its own, and .gitmodules is present, which is the likely reason. This is packaging and code generation work for flatpak and OpenGL, and it has nothing to do with serving a stream. Read it that way and the 3.14 floor stops being surprising.

Release tags are timestamps while both manifests say version 0.0.0

The release names are not semantic versions. The three most recent are v2026.914.233613 from 2026-09-15, then v2026.929.34453 and v2026.929.125923, both from 2026-09-29, and the last push to master was on 2026-09-29. Meanwhile both the npm package and the Python project declare version 0.0.0 in their manifests, so the version you read in the source tree is a placeholder and the real one is stamped at release.

That rules out the usual upgrade questions. There is no minor version to read for breaking changes, and a rollback means choosing an earlier timestamp. The documentation has the same problem in a milder form: there is a stable channel built from the latest tag and a beta channel built from master, so the docs you are reading may describe a build you are not running.

Installation is not documented in the README either. The distribution channels are linked as badges: Docker Hub and GitHub container packages under lizardbyte/sunshine, the Flathub app dev.lizardbyte.app.Sunshine, and a winget manifest, with docker-bake.hcl and DOCKER_README.md in the tree for the container build. Everything else is in the Read the Docs site.

Editorial conclusion

Sunshine fits a self-hoster with a discrete AMD, Intel or NVIDIA GPU who wants Moonlight clients reaching hardware they own, and it does not fit a Linux or FreeBSD AMD user expecting AMF, or anyone who needs a gamepad profile on macOS or Windows without licensing the Virtual HID Broker. Verify first the encoding row for your GPU vendor and your operating system, because that one cell decides whether you get hardware or software encoding, then read the stable documentation channel rather than the beta channel built from master.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes