GO — Healthy across the board

• Last commit today
• 18 active contributors
• Distributed ownership (top contributor 27% of recent commits)
• GPL-3.0 licensed
• CI configured
• Tests present
• ⚠ GPL-3.0 is copyleft — check downstream compatibility
• ⚠ Scorecard: default branch unprotected (0/10)

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests, cross-checked against OpenSSF Scorecard}

Sunshine is a self-hosted game streaming server that implements the Moonlight protocol, allowing users to stream games from a PC to other devices (phones, tablets, other PCs) over the network. It captures game output via platform-specific APIs (NVIDIA NVENC, AMD VCE, Intel QuickSync on Windows/Linux; VideoToolbox on macOS), encodes it, and streams it with ultra-low latency to Moonlight clients. Core capability: turn any PC into a private game streaming hub without relying on cloud services. Monorepo with C++ backend (streaming engine, platform capture, encoding) in src/, CMake-based build system (CMakeLists.txt at root + cmake/ modules for FindLibva, FindWayland, etc.), Vue 3 web UI under src/ui/ (built with Vite, outputs to dist/), and extensive platform-specific code: src/platform/windows/, src/platform/macos/, src/platform/linux/ for capture/encoding. Docker support via Dockerfile and shell deployment scripts in scripts/.

Home server administrators and PC gamers who want to stream games locally without proprietary cloud platforms; systems programmers contributing to the C++ streaming engine; web developers maintaining the Vue.js web UI for server configuration; platform maintainers packaging for Docker, Flatpak, Homebrew, and winget.

Production-ready and actively maintained. The project has 1.7k+ GitHub stars, mature CI/CD across 9+ platforms (Windows, macOS, Linux variants, FreeBSD, Docker), extensive GitHub Actions workflows for linting and release automation (.github/workflows/ has 20+ yml files), and regular commits. Multiple distribution channels (Flathub, winget, Homebrew, COPR, Docker) indicate stable API and packaging.

Moderate complexity: 2M+ LOC in C++ plus platform-specific code (Objective-C++ for macOS, CUDA for NVIDIA, HLSL/GLSL for GPU work) means high barrier to contribution for new developers. Dependencies span across Boost, FFmpeg, OpenSSL, and platform SDKs; breaking changes in those libraries could impact stability. The codebase has tight platform coupling (separate compile paths for Windows, macOS, Linux in cmake/) requiring testing across all platforms before merge.

Active development visible in CI workflows: recent work on CodeQL scanning (_codeql.yml), localization via Crowdin (localize.yml), and distribution updates (update-flathub-repo.yml, update-pacman-repo.yml, update-winget-repo.yml). The repo tracks 60+ configuration files and linters (.clang-format for C++, .flake8 for Python, .prettierrc.json for web), suggesting ongoing code quality enforcement.

Clone and build the C++ backend with CMake, then optionally develop the web UI: ```bash git clone https://github.com/LizardByte/Sunshine.git cd Sunshine mkdir build && cd build cmake .. && cmake --build .

For web UI development only: ```bash
cd src/ui
npm install
npm run dev  # watch mode with Vite

Daily commands: Backend (requires cmake, C++ compiler, platform-specific dev headers): cd build && cmake --build . && ./sunshine (binary location varies by platform). Frontend dev server: cd src/ui && npm install && npm run dev (Vite dev server on port 5173 by default). Full build: cmake --build . --target package to generate installers.

• CMakeLists.txt — Root build configuration; defines all platform-specific compilation, dependencies, and packaging for Windows/Linux/macOS/FreeBSD.
• .github/workflows/ci.yml — Main CI pipeline orchestrator; triggers platform-specific builds and determines release workflow for all contributors.
• cmake/prep/options.cmake — Defines all configurable build options and feature flags that control platform-specific code paths and dependencies.
• cmake/dependencies/common.cmake — Centralized dependency resolution (FFmpeg, Boost, OpenSSL, etc.); any upstream version change impacts all builds.
• .github/copilot-instructions.md — Establishes coding standards and contribution patterns that all pull requests must follow.
• package.json — Frontend build configuration; manages Vue 3, Bootstrap, and Vite toolchain for web UI assets.
• crowdin.yml — Localization workflow; coordinates translations across the entire UI and documentation ecosystem.

Add a new platform-specific build feature

1. Define the feature flag in cmake/prep/options.cmake with OPTION(ENABLE_NEWFEATURE ...) (cmake/prep/options.cmake)
2. Add platform detection logic in cmake/dependencies/linux.cmake (or windows.cmake, macos.cmake) (cmake/dependencies/linux.cmake)
3. Create a CMake find module in cmake/FindNEWFEATURE.cmake if using external library (cmake/FindLIBDRM.cmake)
4. Update CMakeLists.txt to conditionally include source files: if(ENABLE_NEWFEATURE) add_subdirectory(...) (CMakeLists.txt)
5. Add platform-specific CI job in .github/workflows/ci-linux.yml with ENABLE_NEWFEATURE=ON flag (.github/workflows/ci-linux.yml)

Add a new Vue component to the web UI

1. Create new .vue file in the frontend source directory following Vue 3 Single File Component pattern (package.json)
2. Use Bootstrap 5 classes from node_modules for styling consistency (package.json)
3. Add i18n labels in translation files mapped by crowdin.yml (crowdin.yml)
4. Import and register component in the main App.vue or router configuration (package.json)
5. Run vite build --watch to hot-reload during development (package.json)

Update build dependencies or upgrade FFmpeg/Boost version

1. Modify version or source URL in cmake/dependencies/common.cmake or platform-specific dependency file (cmake/dependencies/common.cmake)
2. Update platform-specific find modules (e.g., cmake/FindLibva.cmake) if API changed (cmake/FindLibva.cmake)
3. Run local CMake configure and build to validate: cmake -B build && cmake --build build (CMakeLists.txt)
4. Verify all CI workflows pass in .github/workflows/ci-*.yml by pushing to branch (.github/workflows/ci-linux.yml)
5. Update docs/building.md with any new build prerequisites or compiler requirements (docs/building.md)

Add a new language translation

1. Add language code and file mapping to crowdin.yml under files section (crowdin.yml)
2. Create corresponding locale file in frontend i18n resources (mapped by crowdin.yml) (crowdin.yml)
3. Run npm run build to include new translation in compiled assets (package.json)
4. Verify locale is selectable in Vue i18n configuration (vue-i18n dependency) (package.json)

• CMake — Cross-platform build system supporting Windows (MSVC/Clang), Linux (gcc/clang), macOS (Clang), and FreeBSD; enables conditional compilation for platform-specific features (DRM, Wayland, DirectX).
• Vue 3 + Vite — Modern SPA framework for real-time server management UI; Vite provides fast hot-reload development and optimized production bundles; Vue i18n handles multi-language localization.
• FFmpeg — Hardware-accelerated video encoding backbone; integrates libva (Intel/AMD), NVIDIA CUDA (via separate build flag), and Windows DirectX for low-latency game streaming.
• GitHub Actions — undefined

GPU driver/SDK requirements: Building requires platform-specific headers (NVIDIA CUDA Toolkit, Intel Media SDK, libva on Linux, Xcode on macOS); missing these causes cryptic CMake errors. Wayland vs X11 runtime choice: Linux builds support both; runtime detection happens in src/platform/linux/ but some capture modes only work on X11 or Wayland, not both. Vue UI dev vs production builds: npm run dev (watch mode) is for development only; npm run build with Vite creates optimized dist/ output that Sunshine serves. CMake version: some platform-specific find modules require CMake 3.16+; older versions silently skip features. Port conflicts: Sunshine uses hardcoded ports for streaming (47989, 47990, 48010); firewalls and existing services may block these without clear error messages.

• NVENC (NVIDIA Video Codec Engine) — Sunshine uses NVENC to offload H.264/HEVC encoding to GPU hardware, achieving low-latency streaming; understanding this is critical for Windows/Linux deployment with NVIDIA cards.
• Wayland vs X11 display protocols — Linux builds must support both Wayland (modern) and X11 (legacy); Sunshine abstracts capture differently per protocol, and this split affects available features and performance.
• Hardware video encoding (VideoToolbox, libva, DXGI) — Platform-specific APIs (Apple VideoToolbox, Linux libva, Windows DXGI) are the foundation of low-latency streaming; each has different feature sets and latency profiles.
• Moonlight protocol — Sunshine implements the proprietary Moonlight streaming protocol; understanding packet structure, latency-critical messaging, and control flow is essential for debugging streaming issues.
• CMake multi-platform build systems — Sunshine's complex build (Windows/macOS/Linux/FreeBSD with conditional dependencies) is managed via CMake; mastering platform-specific compile definitions and find modules is required for contributions.
• Display Capture APIs (DXGI, AVFoundation, DRM/KMS) — Screen capture is the first step of the streaming pipeline; each OS has native APIs (DXGI on Windows, AVFoundation on macOS, DRM on Linux) with different performance and compatibility tradeoffs.
• Vue 3 Composition API and Vite module bundling — The web UI uses modern Vue 3 patterns; understanding Composition API (reactive, ref) and Vite's build optimization is necessary for UI features and performance.

• moonlight-stream/moonlight-docs — Official Moonlight protocol and client documentation; required reference for understanding the streaming protocol Sunshine implements.
• kylezehong/sunshine-docker — Community Docker setup for Sunshine; provides alternative packaging and deployment patterns complementary to the official Dockerfile.
• jamesjharper/nvidia-gamestream-docker — Similar self-hosted game streaming for NVIDIA Shield; shows alternate approach to the same problem space (home game streaming).
• LizardByte/Moonlight — Official Moonlight client implementations (web, mobile, desktop); users of Sunshine will deploy these clients to connect to Sunshine instances.
• StaxRip/StaxRip — Video encoding and transcoding tool; Sunshine shares video encoding complexity (FFmpeg, hardware codecs) making this a useful reference for encoding pipelines.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add dependency vulnerability scanning workflow for npm dependencies

The repo has comprehensive CI workflows for multiple platforms (Windows, macOS, Linux, FreeBSD, Homebrew, Flatpak, etc.) but lacks a dedicated npm security scanning workflow. With 10 npm dependencies including Vue, Bootstrap, and FFmpeg bindings, a npm audit or Snyk-based workflow in .github/workflows/ would catch supply chain vulnerabilities early. This is critical since the web UI is user-facing and handles streaming configuration.

• [ ] Create .github/workflows/ci-npm-audit.yml workflow
• [ ] Add npm audit or integrate Snyk GitHub action to scan package.json dependencies
• [ ] Configure the workflow to fail on high/critical vulnerabilities
• [ ] Document the new workflow in contributing guidelines or README

Add integration tests for Vue web UI components against fixtures

The package.json shows a test fixture directory (tests/fixtures/http) and a serve script, but there are no visible test runners (Jest, Vitest, or Playwright configs) in the file structure. Given the complexity of the streaming configuration UI (using Vue 3, i18n, Bootstrap), adding component or E2E tests would validate the web UI against the backend API contracts before deployment.

• [ ] Add Vitest or Jest configuration to the repo root
• [ ] Create tests/unit/components/ directory for Vue component unit tests
• [ ] Add test cases for critical UI components (e.g., settings panel, device configuration)
• [ ] Integrate test runner into .github/workflows/ci.yml or create dedicated ci-ui-tests.yml

Add CMake linting and configuration validation workflow

The repo has extensive CMake configuration across multiple platforms (Windows, macOS, Linux, FreeBSD) with files in cmake/ subdirectories handling dependencies and compile definitions. However, no CMake linting workflow exists (e.g., using cmake-format or ctest). This would catch configuration errors early and ensure consistent formatting across platform-specific build definitions.

• [ ] Create .github/workflows/ci-cmake-lint.yml workflow
• [ ] Integrate cmake-format or cmake-lint to validate all CMakeLists.txt and cmake/**/*.cmake files
• [ ] Add CMake syntax validation step before compilation in existing CI workflows
• [ ] Document CMake style guide in .github/copilot-instructions.md for consistency

• Add unit tests for Vue components in src/ui/ (currently no test runner visible in package.json; consider adding Vitest). This would improve web UI reliability and ease refactoring.
• Document the CMake build flags and platform-specific feature matrix (e.g., create a docs/BUILD_FLAGS.md explaining SUNSHINE_ENABLE_WAYLAND, SUNSHINE_ENABLE_NVENC, etc.) since cmake/compile_definitions/ files are terse.
• Create a Docker Compose example with audio/video device passthrough for docker/ or examples/ showing how to run Sunshine in a container with GPU acceleration, since DOCKER_README.md exists but no example compose file is visible in the file list.

The Sunshine project demonstrates reasonable security practices with CodeQL scanning and Dependabot integration in place. However, several improvements are needed: (1) XSS prevention measures should be explicitly implemented for Vue.js markdown rendering, (2) Security headers must be configured for the web interface, (3) Dependency versions should be regularly audited and updated, particularly for security-sensitive packages like 'marked'. The project architecture separating frontend (Node.js/Vue) from backend (C++) is appropriate. No critical vulnerabilities were identified based on the provided file structure, but explicit security configurations and runtime protections are recommended.

• Medium · Outdated Dependency: marked — package.json - dependencies.marked. The 'marked' library version 18.0.3 is used for markdown parsing. Older versions of marked have had XSS vulnerabilities. While 18.0.3 is relatively recent, it should be verified against the latest security patches and CVE databases. Fix: Check for known CVEs for marked@18.0.3. Update to the latest version if security patches are available. Implement Content Security Policy (CSP) headers to mitigate potential XSS issues.
• Medium · Potential XSS Risk in Vue Application — Frontend codebase (Vue components). The project uses Vue 3.5.34 with marked@18.0.3 for markdown rendering. If user-supplied content is rendered using v-html or dangerously parsed markdown, it could be vulnerable to XSS attacks. Fix: Ensure all user-supplied content is properly sanitized before rendering. Use Vue's built-in template escaping by default. If using marked, implement a sanitization library like DOMPurify. Avoid v-html with untrusted content.
• Low · Development Dependency: serve — package.json - devDependencies.serve. The 'serve' package (14.2.6) is listed in devDependencies and is used in development scripts. While appropriate for development, ensure this is not included in production builds. Fix: Verify that devDependencies are excluded from production builds. Use separate build configurations for development and production environments.
• Low · Missing Security Headers Configuration — CMakeLists.txt, web configuration files (not provided). No explicit security headers configuration (CSP, X-Frame-Options, X-Content-Type-Options, etc.) is visible in the provided file structure for the web interface. Fix: Implement security headers in the web server configuration. Include Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Strict-Transport-Security, and X-XSS-Protection headers.
• Low · No Secrets Detection in Repository — Repository root. While no obvious secrets were found in the provided snippet, the codebase handles streaming configuration and user credentials. No .env.example or secrets management documentation is visible. Fix: Implement pre-commit hooks using tools like 'detect-secrets' or 'truffleHog'. Create .env.example with placeholder values. Document secure credential management practices in CONTRIBUTING.md.
• Low · Missing SBOM and Dependency Scanning — .github/workflows/_codeql.yml. While CodeQL workflow exists, no evidence of Software Bill of Materials (SBOM) generation or continuous dependency vulnerability scanning is visible. Fix: Add Dependabot configuration (already in .github/dependabot.yml, verify it's active). Consider adding SBOM generation in the CI/CD pipeline. Use 'npm audit' or 'snyk' in CI/CD workflows.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/LizardByte/Sunshine shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live LizardByte/Sunshine repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/LizardByte/Sunshine.

What it runs against: a local clone of LizardByte/Sunshine — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in LizardByte/Sunshine | Confirms the artifact applies here, not a fork | | 2 | License is still GPL-3.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of LizardByte/Sunshine. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/LizardByte/Sunshine.git
#   cd Sunshine
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of LizardByte/Sunshine and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "LizardByte/Sunshine(\\.git)?\\b" \\
  && ok "origin remote is LizardByte/Sunshine" \\
  || miss "origin remote is not LizardByte/Sunshine (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(GPL-3\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"GPL-3\\.0\"" package.json 2>/dev/null) \\
  && ok "license is GPL-3.0" \\
  || miss "license drift — was GPL-3.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "CMakeLists.txt" \\
  && ok "CMakeLists.txt" \\
  || miss "missing critical file: CMakeLists.txt"
test -f ".github/workflows/ci.yml" \\
  && ok ".github/workflows/ci.yml" \\
  || miss "missing critical file: .github/workflows/ci.yml"
test -f "cmake/prep/options.cmake" \\
  && ok "cmake/prep/options.cmake" \\
  || miss "missing critical file: cmake/prep/options.cmake"
test -f "cmake/dependencies/common.cmake" \\
  && ok "cmake/dependencies/common.cmake" \\
  || miss "missing critical file: cmake/dependencies/common.cmake"
test -f ".github/copilot-instructions.md" \\
  && ok ".github/copilot-instructions.md" \\
  || miss "missing critical file: .github/copilot-instructions.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/LizardByte/Sunshine"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.