# sunshine-control-panel: a Tauri 2 desktop manager wrapped around Sunshine

> A Windows desktop panel for Sunshine game streaming, written in Rust with a Vue 3 renderer, covering the game library, memory monitoring, virtual display drivers and Steam cover search. Two facts shape everything else: the whole build script chain is PowerShell, and the documented WebUI development mode only works from a specific directory depth inside a Sunshine checkout.

**qiin2333/sunshine-control-panel** — 🎮 Sunshine Foundation 大屏桌面管理器 | Tauri + Vue 3，游戏库管理、米塔AI助手、内存监控、Steam封面搜索、启动助手

- Repository: https://github.com/qiin2333/sunshine-control-panel
- Website: https://www.alkaidlab.com/
- Stars: 444 · Forks: 16
- Language: Rust
- License: MIT
- Published: 2026-09-15 · Updated: 2026-09-15 · Language: en
- Canonical page: https://hysenlabs.com/projects/qiin2333-sunshine-control-panel

## A Vue renderer, a Rust core, and three fixed ports

The architecture diagram splits the application into three boxes. The client is a WebView2 window running Vue 3 with Vite, fronted by composables named `useApps`, `useTauri` and `useTheme`. The core is Tauri 2 in Rust, containing an IPC bridge built on invoke and events, an Axum proxy, Windows system access through WMI COM and `winreg`, and an AI proxy using `reqwest`. External services sit on the other side of the boundary.

Three ports appear across the documentation and they are worth writing down, because two of them are the same number you will find in Sunshine's own configuration. The Axum proxy listens on 48081, the Sunshine service is reached over HTTPS on 47990, and the WebUI development server used in the joint debug mode runs on `https://localhost:3000`.

A panel that talks to a local service over a port it also proxies is a common shape and a common source of confusion, so if 47990 looks familiar and you are wondering where it comes from, that is Sunshine itself and not this project.

## Every script shells out to PowerShell, and one path is a literal Windows executable

Prerequisites are Node.js with npm, Rust with Cargo, and the Windows SDK. The parenthetical on the SDK is the only hint that another operating system is contemplated, and the `package.json` scripts are where that hope ends. Three commands cover the loop:

```bash
# 安装依赖
npm install

# 启动开发服务器（代理到 Sunshine 服务）
npm run dev

# 仅启动前端开发服务器
npm run dev:renderer
```

`dev` runs a PowerShell script to build native plugins and then `tauri dev`. `build` does the same before `tauri build`. `build:win` calls a component installer script, and `build:beta` sets `BETA=true` and builds with the `beta` feature.

The clearest signal is `dev:toolbar`, which builds the renderer, runs `cargo build` against the Tauri manifest, and then executes `src-tauri\target\debug\sunshine-gui.exe --toolbar` with backslashes in the path. There is no cross-platform equivalent of that line, so the development loop is Windows in practice even though the prerequisite list is worded loosely.

For an end user this is all hidden. You are not building from source; you are taking a compiled `sunshine-gui.exe` and dropping it where Sunshine expects it.

## The WebUI debug mode only works four levels inside a Sunshine checkout

The joint WebUI and Tauri development mode is the most interesting workflow in the README and the most fragile, because of a detail in its first line. You are told to start the WebUI development server from the project root and then `cd ../../../..` to get back to the Sunshine root before running `npm run dev-server`. That relative path only lands in the right place if this repository sits at a fixed depth inside a Sunshine tree.

The `package.json` repository field explains why: it points at `qiin2333/sunshine`, not at this repository. This is a component of a larger Sunshine checkout, and the four-level climb is written on the assumption of that layout.

Once running, the arrangement is genuinely useful. The Tauri proxy forwards requests to the WebUI server on port 3000, hot module replacement works, so editing WebUI code takes effect immediately, and API requests are still proxied by the WebUI server through to Sunshine on 47990. If you cloned this repository standalone, the flow does not apply and you would need to place it inside the Sunshine tree first.

## An injected script is how the panel gets into Sunshine's own web interface

One file in the Rust side is `inject-script.js`, described as a script injected into the Sunshine Web UI. That single line explains the rest of the design. The panel does not replace Sunshine's interface, it attaches to it, and the Axum proxy in `proxy_server.rs` exists to serve Sunshine, the Steam API and CORS from one local origin so the injected script can talk to them.

The other half of the arrangement is the install target. A compiled GUI is placed automatically into Sunshine's own directory, at `Sunshine/assets/gui/sunshine-gui.exe`, which is the same directory structure Sunshine uses to find optional components.

And the project is careful about its own status. The Tauri GUI is described as an optional component that does not affect Sunshine core functionality, and a separate note says you need the Rust toolchain to build it and that the first build downloads and compiles Rust dependencies, which takes a while. In other words, nothing here is load-bearing for streaming.

## The game library is file system work plus the Steam Store API

Look at what the library features actually require and none of them need a game engine. Applications are listed in grid or list views with search, filtering, favourites pinned to the top, recently used ordering and sorting. A right-click action searches the Steam Store API for cover candidates and uploads the one you pick. Another right-click action launches the game or application, and that path supports administrator privileges and a working directory, which is what you need for the launchers that insist on both.

The launch assistant is the part with the most specific value. It configures per-application scripts that run before and after the game starts, and the named examples are a virtual display and a resolution switch, which are the two things you would otherwise do by hand every time a title needs a specific display state.

In the Rust side this all lands in `fs_utils.rs`, which handles the file system, game scanning and Steam cover search and upload, and in `commands.rs`, which holds the HTTP client and app launch. Scanning is automatic for Steam and Epic titles rather than a manual list you maintain.

## Driver installation and EDID management are system-level, not configuration

Streaming to a virtual display is a common reason people run Sunshine on a headless Windows box, and the panel treats it as a first-class feature. There is VDD driver management covering install, configuration and EDID management, a separate virtual mouse driver with install and status management, and an HDR automatic switch in the stream configuration alongside encoder choice between H.264, H.265 and AV1, plus bitrate adjustment.

The difference from a configuration panel is the word install. Editing a bitrate is a value in a file; installing a virtual display driver is a system operation, and the presence of an EDID editor means the panel will write display identity data as well. That is a category of risk worth naming plainly, since the README does not discuss elevation, signing or what a failed install leaves behind.

Two smaller items sit in the same area. Moonlight Web browser streaming is managed here, and an anti-sleep feature keeps the screen and the system awake during a stream, which is the setting people forget until a two-hour session has put their machine to sleep.

## The manifest says 0.0.0-dev while the releases are v0.5.2, and there are two Vite configs

Package metadata is a small source of confusion here. The name is `sunshine-gui`, the description is a GUI for sunshine, and the version field is `0.0.0-dev`, while the release tags are v0.5.0, v0.5.1 and v0.5.2, all shipped between 2026-09-30 and 2026-10-01. The published version is the tag; the manifest carries a placeholder.

There are also two Vite configurations where you would expect one. `vite.config.js` drives the main renderer with `dev:renderer`, `build:renderer` and the default build, while `vite.home.config.js` drives a separate set of scripts named `build:home`, `dev:home` and `preview:home`. The README does not explain what the second front end is, which is the kind of gap that costs an afternoon when you are trying to change the wrong bundle.

Other root files point the same way. `vercel.json` suggests something is deployed as a web front end, `.coderabbit.yaml` configures a code review bot, and `TOOL_DEVELOPMENT_GUIDE.md` and `docs/` hold material the README does not summarise. Licensing is MIT, the last push was 2026-10-01, and the beta channel is a Cargo feature rather than a branch, switched with `--features beta` and a `BETA=true` environment variable.

## Conclusion

Adopt this panel if you already run Sunshine on Windows and want a desktop surface for the game library, memory graphs and virtual display driver management rather than editing configuration files, since the features listed are the ones a streaming host actually touches. Do not adopt it as a Sunshine replacement, because the README is explicit that the GUI is optional and does not affect core functionality, and do not expect a cross-platform build path, since every script in `package.json` shells out to PowerShell. Verify three things first: that the built `sunshine-gui.exe` lands in `Sunshine/assets/gui/`, that the local Axum proxy on 48081 is not already occupied, and that the version you are testing is a release tag rather than the `0.0.0-dev` placeholder in the manifest. Licence is MIT, v0.5.0 through v0.5.2 all shipped between 2026-09-30 and 2026-10-01, and the last push was 2026-10-01.

## FAQ

### What is sunshine-control-panel?

It is a Sunshine Foundation desktop manager built with Tauri 2 and Vue 3. It covers game library management, memory monitoring, streaming configuration, virtual display and virtual mouse drivers, Steam cover search, a launch assistant, an AI assistant and log viewing, with light and dark themes and instant Chinese and English switching.

### What do I need to build sunshine-control-panel from source?

Node.js with npm, Rust with Cargo for Tauri, and the Windows SDK. Every script in `package.json` invokes PowerShell, so the build path is Windows in practice, and the README warns that the first build downloads and compiles Rust dependencies and takes a while.

### How does sunshine-control-panel connect to Sunshine?

A compiled GUI installs into Sunshine's own directory at `Sunshine/assets/gui/sunshine-gui.exe`, an injected script runs inside the Sunshine Web UI, and a local Axum proxy on port 48081 serves Sunshine, the Steam API and CORS from one origin. Sunshine itself is reached over HTTPS on port 47990.

### Is the Tauri GUI required for Sunshine to work?

No. The README states that the Tauri GUI is an optional component and does not affect Sunshine core functionality. It is a management surface, not a dependency of streaming.

### What is the dev-webui mode in sunshine-control-panel?

A mode where the Tauri proxy forwards to the Sunshine WebUI development server on `https://localhost:3000` with hot module replacement, while API requests are still proxied to Sunshine on 47990. Starting it requires a `cd ../../../..` back to the Sunshine root, so this repository has to sit inside a Sunshine checkout.

## Sources

- [License: MIT](https://github.com/qiin2333/sunshine-control-panel/blob/main/LICENSE)
- [Project website](https://www.alkaidlab.com/)
- [qiin2333/sunshine-control-panel on GitHub](https://github.com/qiin2333/sunshine-control-panel)
- [README](https://github.com/qiin2333/sunshine-control-panel/blob/main/README.md)
- [Releases](https://github.com/qiin2333/sunshine-control-panel/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/qiin2333-sunshine-control-panel