Fork lineage
All five projects share a common ancestor in Sunshine. They diverged in two branches: one through Apollo, one through Vibeshine.
Sunshine — LizardByte (base, ~37k stars) │ │——————————————————————————————————— │ │ ├—— Apollo ├—— Vibeshine — Nonary (~261 stars) │ — ClassicOldSong (~9.5k) │ fork of Sunshine │ fork of Sunshine │ │ │ └—— LuminalShine — NortheBridge Foundation │ │ fork of Vibeshine │ └—— Vibepollo — Nonary (~435 stars) │ fork of Apollo │ └—— (other downstream forks not covered here)
Publishers at a glance
NortheBridge Foundation. A Public Mutual Benefit Foundation that does a wide variety of work, including supporting open-source software. LuminalShine is one of the open-source projects the Foundation develops, maintains, and underwrites — alongside the Twilight Moonlight client for LG webOS.
LizardByte. An established open-source organization with multiple maintained projects and a long-running release cadence. The de facto upstream for this entire family.
ClassicOldSong. Individual maintainer. Companion to the Artemis (Moonlight Noir) client. Focuses on virtual display + resolution-matching features.
Nonary. Individual maintainer. The project openly describes itself as “an AI-enhanced version of Sunshine” with “approximately 99% of Vibeshine’s code is AI-generated.”
Nonary. Individual maintainer; same author as Vibeshine. Self-describes as “an AI-enhanced version of Apollo” with the same “approximately 99%…AI-generated” description.
At a glance
A summary matrix. Cells link to the longer per-axis sections below.
| LuminalShine | Sunshine | Apollo | Vibeshine | Vibepollo | |
|---|---|---|---|---|---|
| Publisher | NortheBridge Foundation | LizardByte | ClassicOldSong | Nonary | Nonary |
| License | GPL-v3 | GPL-v3 | GPL-v3 | GPL-v3 | GPL-v3 |
| Forked from | Vibeshine | — (base) | Sunshine | Sunshine | Apollo |
| Platforms | Windows 11 onlyBy design — non-Windows code is removed. | Win, Linux, macOS, FreeBSDBroadest platform support. | Win 10+, macOS 12+, Linux | Largely WindowsInherits Sunshine’s cross-platform code but features target Windows. | Largely WindowsInherits Apollo’s code; features target Windows. |
| WinGet package | AvailableSearch NortheBridge.Luminalshine. |
AvailableSearch LizardByte.Sunshine. |
Not Available | Not Available | Not Available |
| Microsoft Store | Coming Soon | Not Available | Not Available | Not Available | Not Available |
| Win 11 Insider Preview (Canary/Dev) | YesPrimary target. Works around recent dxgi.dll quirks. |
Not targeted | Not targeted | Not SupportedMaintainer statement on vibeshine#189: “Insider builds are unsupported as they often contain driver bugs…” | Not SupportedSame maintainer position as Vibeshine; see vibeshine#189. |
| WGC capture in service mode | Yes | LimitedDXGI capture in service; WGC handling differs. | Limited | YesInherited / parallel work. | YesInherited / parallel work. |
| Bundled virtual display driver | SudoVDA default, MTT VDD opt-in, LuminalVGD planned | None bundled | Built-in virtual display (SudoVDA-based) | Bundled VDD options | Bundled VDD options |
| WebRTC browser streaming | Yes First-party /webrtc endpoint. |
No | No | Yes | Yes |
| TPM-bound credential sealing | Yes | No | No | No | No |
| Local-admin single-file credential hijack † | Not affectedCredentials in Windows Credential Manager under SYSTEM scope (DPAPI / TPM 2.0–bound master key). No on-disk file to delete. | AffectedPlaintext-path JSON credentials file; first-run bootstrap route accepts unauthenticated POST when no username is set. | AffectedInherits Sunshine credentials path. | AffectedInherits Sunshine credentials path. | AffectedInherits Apollo / Sunshine credentials path. |
| Scoped API tokens | Method-level | API exists | API exists | Yes | Yes |
| Formal SECURITY.md † | Yes Private advisory, 72h response target. | Yes Private reporting via GitHub Security tab. | None No Security Policy. | None No Security Policy. | None No Security Policy. |
| Self-described AI-generated code | AI-EnhancedAI used as a development aid alongside human review; code is not generated wholesale. | AI Contributions AllowedPublished AI Usage policy: bounded AI assistance permitted (brainstorming, syntax help, docs, tests, refactor review); wholesale generation, unreviewed submissions, and AI-written PR descriptions are explicitly disallowed. | Not claimed | Full AI Generated“~99% AI-generated” per maintainer’s own README. | Full AI Generated“~99% AI-generated” per maintainer’s own README. |
| Approx. GitHub stars (at time of writing) | —Newest project; community building. | ~37,200 | ~9,500 | ~261 | ~435 |
Platform focus
The single biggest axis of difference.
Sunshine: the broad option
Sunshine remains the only project in this family that actively supports Windows, Linux (multiple distributions), macOS, and FreeBSD as first-class targets. If you need to stream from a non-Windows host, or you want a single project that runs on the broadest matrix of hardware, Sunshine is the right pick.
LuminalShine: Windows-only by design
LuminalShine has removed Linux and macOS code paths so the team can focus on the Windows 11 platform — including the Insider Preview Canary and Dev channels, which other projects do not target. This is an intentional tradeoff: less platform coverage, deeper investment per platform. If you need cross-platform support, use Sunshine.
Apollo & Vibe* projects: Windows-centric, multi-platform code retained
Apollo, Vibeshine, and Vibepollo all inherit Sunshine’s cross-platform code, but their headline features (virtual display, capture changes, WebUI work) are developed against Windows. Linux and macOS builds may still produce binaries, but new feature work is not driven by those platforms.
Windows Insider Preview support
Only LuminalShine claims active support for the Windows 11 Insider Preview Canary and Dev channels. Recent Insider builds have shipped breaking changes to dxgi.dll that affect capture pipelines; LuminalShine ships workarounds for those. Sunshine, Apollo, and the Vibe* projects target stable Windows 11 release channels.
Security & disclosure
Game stream hosts run with elevated privileges, capture the desktop, accept paired clients over the network, and (in some cases) load virtual display drivers into the kernel. A documented disclosure process matters.
Projects with a published SECURITY.md
Sunshine and LuminalShine both publish a security policy and accept vulnerability reports privately via GitHub Security Advisories. LuminalShine commits to a 72-hour initial-response target (excluding weekends) and explicitly enumerates supported versions and scope.
Projects with no SECURITY.md
As of the date this page was written, Apollo, Vibeshine, and Vibepollo do not publish a security policy. GitHub displays the standard notice: “No security policy detected. This project has not set up a SECURITY.md file yet.”
That doesn’t mean the projects are insecure — it means there is no documented private channel for reporting a vulnerability, no stated response time, and no defined supported-version window. Users who discover an issue have to choose between filing a public GitHub issue (which discloses the bug before any fix lands) or attempting to reach the maintainer through informal channels.
Why this matters more than usual here
Game streaming hosts in this family run as a privileged Windows service, hold long-lived paired-client credentials, expose an HTTP(S) management UI, and on some forks bundle kernel-level virtual display drivers. The blast radius of a vulnerability is the entire desktop session. A documented private disclosure process and a defined supported-version window are baseline expectations for software in that role; their absence is a real operational concern, not a paperwork nit.
Development model
How the code is produced. Two of these projects have made a notable, explicit declaration about their authoring process.
These statements come from the maintainer’s own README and reflect a deliberate development model that prioritises velocity over hand-review of every change. Vibeshine’s own README puts it plainly: “I’m trading minor, manageable debt for massive development velocity — and that trade is almost always worth it.” The same README also says AI-generated code “works on the first try around 90% of the time”.
Whether that tradeoff is right for you depends on how you weigh feature velocity against the value of a human reviewer having read every line of code that runs as a privileged Windows service in your home network. There is no “correct” answer here — but you should know what you’re installing.
LuminalShine, Sunshine, and Apollo do not make any equivalent claim about AI-generated code in their READMEs.
Community & maintenance
Sunshine
By far the largest community in this family (~37,000 stars). Multiple maintainers under the LizardByte org. Consistent release cadence going back years. The natural choice if “many eyes” matters to you.
Apollo
Active single-maintainer project (~9,500 stars). Companion to the Artemis client. Recent releases continue; no formal SECURITY.md as of writing.
Vibeshine / Vibepollo
Both maintained by the same individual (Nonary). Active commit history and frequent releases. Small communities (a few hundred stars each). No formal SECURITY.md as of writing.
LuminalShine
Newest project of the five. Maintained by the NortheBridge Foundation. Smaller community than Sunshine or Apollo — balanced against an opinionated, narrow Windows-11-only scope and a documented security disclosure process. Contributors welcome.
When to pick what
Pick Sunshine if…
You stream from Linux, macOS, or FreeBSD. You want the project with the largest community, the most maintainers, and the longest track record. You don’t need Insider Preview support or in-tree virtual display drivers.
Pick Apollo if…
You’re an Artemis (Moonlight Noir) user, you want bundled virtual display with automatic resolution matching, and the lack of a documented security disclosure process is acceptable for your threat model.
Pick LuminalShine if…
You’re on modern Windows 11 (especially Insider Preview Canary/Dev). You want TPM-bound credential sealing, WGC capture in service mode, a built-in WebRTC browser endpoint, and a host with a documented private security disclosure process. You’re comfortable with a Windows-only project.
Pick Vibeshine or Vibepollo if…
You actively want to track a fast-moving, largely-AI-authored fork and you accept the tradeoffs (no documented security disclosure process, small community, the maintainer’s own description of the codebase’s authorship). Most users who want similar features but a different development model are better served by Sunshine, Apollo, or LuminalShine.
Methodology & sources
This comparison was assembled from each project’s own public materials: README files on GitHub, repository metadata (license, fork lineage, star count), and the project’s GitHub Security Policy page. Where a project is quoted, the quote is taken verbatim from the maintainer’s own README and cited inline. Where a project lacks a security policy, the statement reflects GitHub’s standard “No security policy detected” notice on the project’s /security/policy page at the time of writing.
Software changes. Star counts move, features ship, security policies are added, README disclosures get edited. If you spot a fact on this page that’s gone stale or that you believe is unfair to the project being described, please open an issue with the corrected text and a source — we’ll update it.
† Last verified for accuracy: Thursday, 21 May 2026 — the initial post-publication re-check of the comparison, including the Formal SECURITY.md row for all five projects. Subsequent re-check dates will be appended here as the page is re-audited.
† About the credential-hijack row
Vulnerability
The credentials file (typically sunshine_state.json or the configured credentials_file path) holds the admin username, password hash, and salt in a path readable and writable by anyone running with local Administrator privileges. The first-run bootstrap path (/api/password in confighttp.cpp) skips authentication when no username is configured — the conditional reads if (!config::sunshine.username.empty() && !authenticate(...)) return;. These two behaviours are individually intentional — credentials must live somewhere, and first-run setup must accept the initial credential without prior auth — but in combination they form an exploit chain:
- Attacker obtains local Administrator on the host (any vector: resident malware, social engineering, supply chain, etc.).
- Attacker deletes the credentials file.
- On the next config reload / service restart, the in-memory credential state is empty.
- Any network caller — including the attacker from a different machine on the same LAN, or back through a proxied connection — POSTs new credentials to
/api/passwordand is granted admin access to the host without further authentication.
This converts a transient local-admin compromise into persistent remote ownership of the streaming service. Beyond credential takeover, the streaming service controls desktop capture and virtual input injection, so the attacker who completes step 4 controls the interactive session of any user who logs in to the host.
Affected versions
All current versions of Sunshine, Apollo, Vibeshine, and Vibepollo. Apollo and Vibeshine inherit the code path directly from Sunshine; Vibepollo inherits it through Apollo.
Severity
Approximate CVSS 3.1 base score: ~7.3 (High). Vector: local attack vector, low complexity, high privileges required (local Administrator), no user interaction, scope change (local admin to full service ownership including remote streaming and input injection), high impact on confidentiality, integrity, and availability. This is an estimate; canonical scoring is a function of the assigning CNA. Note that the chain converts a local-admin precondition into persistent remote service ownership, which is the property driving the score above “just” a local-admin-required issue.
Disclosure status
This issue has been raised with the upstream maintainers. The maintainers have made a deliberate decision to retain the current credential-storage and first-run bootstrap behaviour. The underlying code is publicly visible in each upstream repository.
Why LuminalShine is not affected
LuminalShine does not persist the admin credential blob to a path-on-disk file an Administrator can delete. Step 2 of the exploit chain has nothing to act on, and the bootstrap-mode reset that depends on it cannot be triggered. The specific implementation is intentionally not documented here.
Threat-model note: this is a local-admin precondition issue, not a remote unauthenticated exploit. An attacker without Administrator on the host cannot trigger it on its own. It is documented here as a security-model difference that motivated LuminalShine’s credential-store rework. The underlying upstream code is publicly visible in each upstream repository and the maintainers have chosen to retain it.