Apollo (ClassicOldSong): a Sunshine fork that gives each Moonlight client its own virtual display

The problem Apollo addresses: a headless host that still needs a monitor

Streaming a desktop from a machine with no monitor attached has always required a workaround. The host needs a display to render into, and the client wants that display to be its own size. The usual answers are a dummy HDMI plug, a persistent virtual monitor, or a script that rewrites the resolution before each session. Apollo takes a different route: it creates a virtual display when the stream starts and removes it when the app quits, using SudoVDA. The README describes the target as the native resolution of the client device, and the feature list calls it a built-in virtual display with HDR support that matches the resolution and framerate config of the client automatically.

The audience is narrow and specific. You need a host machine with an AMD, Intel or Nvidia GPU for hardware encoding, though software encoding is also available. You need an Artemis (Moonlight Noir) or Moonlight client. You need to be willing to run a self-hosted host rather than a commercial game streaming service. If you already run Sunshine and your only complaint is resolution handling, Apollo is aimed directly at you. If you run a Linux host, the README is explicit that virtual display support is Windows only at present and that Linux support is planned for the future.

The feature list also includes permission management for clients, clipboard sync, commands fired on client connection and disconnection, and an input only mode. Those are the parts that make Apollo more than a resolution patch on top of Sunshine, and they are the parts most likely to change how you operate a shared host.

How the virtual display works, and why the fixed identity matters

The mechanism is SudoVDA plus a per-client identity. The README states that Apollo assigns a fixed identity for each Artemis or Moonlight client, so Windows remembers and manages the display configuration natively. That is the part worth understanding. Other approaches either reuse one identity for every session or generate a random one each time, which means the operating system treats each session as a new monitor and forgets where your windows were. With a stable identity, the display behaves like a monitor that is occasionally unplugged and replugged, and Windows remembers its arrangement.

The README's summary is blunt: treat your Artemis or Moonlight client like a dedicated PnP monitor. The virtual display is created when the stream starts and removed when the app quits. If you do not see a display appear or disappear at those moments, the README points at two causes: a driver misconfiguration, or another persistent virtual display still active on the system. It also warns that removing other virtual display solutions from the system and from the Apollo or Sunshine config is highly recommended, to reduce confusion and compatibility issues.

The permission system is the second mechanism. The first client paired with Apollo gets full permissions. Every client paired afterwards gets only View Streams and List Apps. If launching an app returns Permission Denied, you grant Launch Apps to that device. The same applies to input: a newly paired client cannot move the mouse or type until you grant Mouse Input and Keyboard Input. That default is safe and annoying in equal measure, and it is the first thing most people will hit. On a host shared by several people, it also means the first person to pair has a different experience from everyone who follows, which is a policy decision the software makes for you unless you go into the permission list and change it.

Installing Apollo and pairing a first client

The README does not carry its own installation steps. It says to refer to LizardByte's documentation for now, and links to the Sunshine documentation on Read the Docs. So the install path is the Sunshine path, and the repository layout (CMakeLists.txt, packaging/, docker/, docs/, third-party/) matches that heritage. The README does not document a rollback procedure for a failed install or a driver problem, which is worth noting before you start replacing a working setup.

Once the host is running, the web UI is where you configure and pair. The README states that a web UI is provided to allow configuration and client pairing from a browser, and that you can pair from the local server or from any mobile device. The pairing step is the point where the permission defaults take effect, so watch which client goes first.

After the first successful pairing, check what that client was granted. The README's note is that the first client gets full permissions and later clients get View Streams and List Apps only. If a second client cannot start anything, this is why.

# No install commands are given in the README.
# It points to LizardByte's Sunshine documentation:
# https://docs.lizardbyte.dev/projects/sunshine

For a dual GPU laptop, the README gives a concrete configuration path rather than a command: set Adapter Name to your discrete GPU and enable Headless mode in the Audio/Video tab, save, and restart the computer. No dummy plug is needed, and the README says the image is rendered and encoded directly from the dGPU. Note that this is a UI setting, not a config file key, so there is nothing to paste into a terminal. The restart is part of the instruction, not a suggestion, which makes this a slower loop to iterate on than a config file you can reload.

HDR support is real, and the README spends a page telling you not to rely on it

This is the most unusual part of the documentation. HDR starts being supported from Windows 11 23H2 and is generally supported on 24H2. Some 23H2 systems lack the HDR toggle, and the README's advice is to upgrade to 24H2. Anything below 23H2, including Windows 10, has no HDR option at all.

Then the README argues against using it. It says enabling HDR is generally not recommended with any streaming solution at this moment, probably in the long term, because HDR itself has loads of semi-incompatible standards and massive variance between device configurations. It notes that SDR provides more stable color accuracy and is widely supported. It also says that whether HDR looks good depends completely on the client, and that ICC color correction is useless while streaming HDR because it is the client's job to display HDR content correctly. The README points to issue 164 for the full explanation of why HDR can appear dark or yellow.

That is an honest position, and it is a limitation rather than a feature. If HDR streaming is your reason for choosing a host, Apollo's own documentation tells you the outcome depends on your client device, and that Apple products with HDR capability are the ones usually worth trusting. Everything else is described as a matter of luck. The practical consequence is that you should test HDR on your actual client before you build a setup around it, because the host side is not where the problem lives.

Where Apollo is the wrong tool

The clearest case is a Linux host where the virtual display is the feature you want. The README states that virtual display support is currently Windows only and that Linux support is planned. A Linux user gets the rest of the fork, including the permission system and the web UI, but not the resolution matching that gives the project its tagline.

A second case is a host that already has a working virtual display setup you are happy with. Apollo's README explicitly asks you to remove other virtual display solutions from the system and from the Apollo or Sunshine config to avoid confusion and compatibility issues. If your current arrangement works, moving to Apollo means dismantling it first, and the README does not promise that a mixed setup will behave.

A third case is a client that cannot request the resolution you want. The README's device-specific notes include Pixel devices, which might not be able to use native resolution, with a workaround of changing the device resolution to Max in issue 700. That is a client-side limitation, not something the host can fix.

The system requirements table carries its own warning: it is a work in progress, and the README says not to purchase hardware based on it. If you are choosing a GPU for this, the table is a starting point at best. The GPU rows list AMD VCE 1.0 or higher, Intel VAAPI-compatible hardware, and NVENC-enabled Nvidia cards, each with a link to the vendor's own support matrix rather than a list maintained in the repository.

Apollo against Sunshine, and against the dummy plug

Apollo is a fork of Sunshine, and the README says to use LizardByte's Sunshine documentation for now. That tells you the two share configuration, packaging and documentation for the parts Apollo has not rewritten. The difference is what Apollo adds on top: the SudoVDA-based virtual display with per-client fixed identity, permission management for clients, clipboard sync, connection and disconnection commands, and an input only mode.

Against a dummy HDMI plug, the difference is not subtle. A dummy plug presents one fixed resolution forever. Apollo creates a display per session at the client's resolution and framerate, then removes it. The dummy plug costs a few dollars and never needs a driver; Apollo needs SudoVDA installed and configured correctly, and the README's troubleshooting advice for a missing display is to suspect the driver or a leftover virtual display.

Against a persistent virtual monitor, the difference is the identity. A persistent monitor stays in the display list whether or not you are streaming, which can confuse window placement and GPU selection. Apollo's display only exists during a session, and the fixed per-client identity means Windows still remembers the arrangement between sessions. That is the design decision the README is proudest of, and it is the one worth evaluating against your own setup. The trade is that you now depend on a kernel-level display driver for a streaming feature, so a driver problem becomes a streaming outage rather than a cosmetic issue.

Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-05-21. The most recent release listed is v0.4.7-alpha.1 from 2025-08-12, preceded by v0.4.6 from 2025-07-13 and v0.3.7-hotfix.1 from 2025-06-05. The release history shows both stable tags and alpha tags, and the newest tag is an alpha, so anyone tracking releases should decide deliberately whether to run alpha builds or stay on stable tags. The gap between the last release and the last push suggests work continues on the default branch between releases.

The licence is GPL-3.0. The repository also contains a NOTICE file, which is typical for projects that incorporate third-party components. If you redistribute Apollo or ship it inside a product, GPL-3.0 obligations apply to the combined work, and the NOTICE file is where the third-party attributions live. That is a description of the files, not legal advice; read the LICENSE and NOTICE yourself before redistributing.

Upgrade cost is dominated by the virtual display driver rather than the application. Because the display depends on SudoVDA and on the absence of competing virtual display solutions, an upgrade that changes driver expectations is riskier than an upgrade that only changes the streaming code. The README does not document a downgrade or rollback path, so keeping the previous version available is your own responsibility. The web UI is built with Vite and Vue according to package.json, and the build scripts there (build, build-clean, dev, serve) are the frontend toolchain, not the host installer, so do not confuse the two when you read the repository.

What to check before you commit

Pair one client and confirm it receives full permissions, then pair a second and confirm it receives only View Streams and List Apps. That single test exercises the permission system and tells you whether the default will surprise your users.

Start a stream and watch the display list. A new display should appear at the client's resolution and framerate, and it should disappear when the app quits. If it does not, the README's first suspects are the driver configuration and a leftover persistent virtual display, so check both before opening an issue.

If you are on a dual GPU laptop, confirm the Adapter Name and Headless mode settings in the Audio/Video tab, save, and restart the computer as the README instructs. If HDR matters to you, confirm your client device is one that handles it, because the README puts the outcome on the client rather than the host.

Finally, decide which release channel you are on. The newest listed tag is an alpha, and the README does not describe a rollback procedure, so the version you install is the version you will be debugging.

Multiple instances and the wiki

The README does not explain how to run several Apollo instances for several virtual displays in the README itself. It points to a wiki page titled How to start multiple instances of Apollo. The same applies to the FAQ, which the README says has moved to the wiki, and to the Stuttering Clinic, which is also a wiki page. The auto pause and resume commands for client connection and disconnection are documented in a wiki page as well.

That is a documentation split worth knowing about before you start. The README covers features, requirements, HDR and the permission default. The wiki covers operation: multiple instances, stuttering causes, the FAQ and the connection hooks. If you are evaluating Apollo for a multi-user or multi-display setup, the wiki is not optional reading, and it is not in this repository's README. A reader who only skims the README will conclude the project is a resolution feature with a permissions quirk; the operational material that answers the harder questions lives elsewhere.

Editorial conclusion

Adopt Apollo if you run a Windows host with an AMD, Intel or Nvidia GPU, stream to Artemis or Moonlight, and want the display to match the client instead of a dummy plug or a manually managed virtual monitor. Do not adopt it if your host is Linux and the virtual display is the reason you are interested: the README states that support is planned but not implemented. Before committing, verify that SudoVDA installs and that a display appears and disappears when a stream starts and stops, check the permission list of the first paired client, and confirm your client can reach the resolution you want. The README also warns that other virtual display solutions should be removed from the system and from the Apollo or Sunshine config first, because they cause conflicts.

Frequently asked questions

Official sources

1. ClassicOldSong/Apollo on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases