BilldDesk: a self-hosted remote desktop and game streaming stack built on WebRTC

What problem BilldDesk solves, and who it is aimed at

Commercial remote desktop tools meter the thing engineers care about most: session time. The README's own comparison table puts ToDesk's free tier at 80 hours per month, 200 sessions per month, 24 hours per session, with a 1080p and 30 fps ceiling, and it notes that Android as a controlled endpoint, privacy screen and virtual screen sit behind paid tiers. BilldDesk's pitch is that the open source edition has no connection, quality or frame rate limits, and that in the Pro edition Android being controlled is free.

The audience follows from that. This is for a small team or an individual who controls their own machines and is willing to run a server. The README lists private deployment and secondary development as supported in the open source edition, which is the real differentiator: you get the relay and the API under your control rather than a vendor's.

The README's feature list, which describes BilldDesk Pro, is broad: screen wall, batch group control, multi-screen, clipboard sync, file transfer in both directions, WOL wake-on-LAN, privacy screen with custom image and text, virtual screen, and driver-level keyboard and mouse input which the README frames as avoiding game anti-cheat detection.

The WebRTC data path and where each piece runs

The architecture splits into three layers. The README lists Flutter, Vue and Koa2 as frameworks, and endpoints are Windows, macOS and Android clients or a browser tab. The web client is Vue 3 with Vite, and the desktop client wraps the same frontend in Electron, which is why package.json sets main to electron-dist/index.cjs and why the build scripts run vite build before electron-builder. The media itself moves peer-to-peer over WebRTC, falling back to a relay when NAT traversal fails.

Two machines behind symmetric NAT or a restrictive corporate firewall will not establish a direct path, and without a TURN server configured the session simply fails. The README's support for a custom relay server is the escape hatch here: you point clients at your own relay rather than a shared one.

Input simulation is platform-specific rather than uniform. The technology list names Win32, Cocoa and Android's AccessibilityService among its APIs, and the README says Android 7 can be viewed but not operated. The dependency list includes both @nut-tree/nut-js and the @nut-tree-fork/nut-js fork, which suggests input handling has been through at least one upstream transition.

Encoding is where the project makes its strongest claims. The README reports tested configurations of 2K at 60 fps on an RTX 3060 Laptop, 2K at 120 fps on an RTX 5070, and 1080p at 60 fps on both an RTX 2070 Laptop and a GTX 1060 6G, all with Chrome or the BilldDesk client as the controlling side. Those are the author's measurements on named hardware, not a general benchmark, and the controlled machines were all Windows. Hardware acceleration covers H264, H265 and AV1 on NVIDIA with driver 570.0 or newer, H264, H265 and AV1 on AMD, and Intel integrated graphics. VP8 and VP9 are also listed among supported codecs.

Installing BilldDesk and starting a first session

The README does not give a server installation walkthrough. It points to the client download page at https://desk.hsslive.cn/#/download and to the hosted instance at https://desk.hsslive.cn for a quick trial, and the repository carries a doc/ directory and the deploy scripts reference a ./deploy/ path. Treat the hosted instance as the fastest way to see what the product does, and the repository as the starting point for a private deployment.

For local frontend work, the repository is a pnpm project (pnpm-lock.yaml is present) and package.json defines a dev script that clears the Electron output and the Vite output before starting the dev server:

pnpm install
pnpm dev

The dev script is `rimraf electron-dist dist && vite`, so expect the build directories to be deleted each time you run it. The README does not document the environment variables the frontend needs to reach a signaling server or a TURN server, so you will have to read the source under src/ to find them.

Building a desktop client is separate from running the web app. The Windows build wraps the Vite output in Electron:

pnpm build:win

The script runs standard-version first, then vite build, then electron-builder --win. There is a matching build:mac, build:linux, build:mw and a build:ele that targets all three platforms at once. Note that build:prod and build:beta set VITE_APP_RELEASE_PROJECT_ISWEB=true and only run Vite, which is how the web-only bundle is produced.

Once a controlled machine is running the client, the flow is the one the feature list describes: the controlling side opens the web page or the desktop client, enters the device code and connection password, and the session negotiates over WebRTC. The README states that both the device code and the connection password can be customized, which matters for private deployments where you do not want to depend on a vendor-assigned identifier. The README does not document what the client shows on a failed TURN negotiation, so budget time for diagnosing that case from logs.

The platform gaps that decide whether this fits

The support matrix is the most concrete limitation in the repository, and it is stated plainly. Linux is not supported. iOS is not supported. Windows 7 is explicitly unsupported, and the README says other Windows versions were not actually tested. On macOS only macOS 15 is listed as tested. On Android, versions 8 through 16 are supported, version 7 can be viewed but not controlled, and version 6 was dropped.

That means a mixed fleet is a problem. If your engineers run Linux workstations and your servers are Linux, BilldDesk cannot control them, and the controlling side is limited to Windows, macOS, Android or a browser. The browser route softens this considerably: Chrome, Edge, Firefox, Via and Safari are all listed as working controlling clients, so a Linux user can drive a Windows machine from a browser tab even though no Linux endpoint client exists.

A second limitation is deployment maturity. The feature list ends with an unchecked box for Docker one-click deployment. Everything else in that list is checked. If your adoption criterion is a single docker run command, this project does not offer one yet, and you will be assembling the Koa2 backend, the relay and the client builds yourself. Combined with version 0.0.1 in package.json and the absence of published releases, that is a project you should expect to debug rather than consume.

The hardware acceleration path has its own constraint. The README ties NVIDIA H264, H265 and AV1 encoding to driver version 570.0 or newer. The tested frame rates in the README were all measured on discrete NVIDIA GPUs. The README does not state what frame rate to expect on integrated graphics.

BilldDesk compared with RustDesk and ToDesk

RustDesk appears in the README's list of remote tools the author has used, so the comparison is invited. The difference is in the client architecture. RustDesk ships a native client built in Rust with its own relay server (hbbs and hbbr), and its protocol is custom. BilldDesk builds on WebRTC, which means the media path is a standard that browsers already implement, and the controlling side can be a plain web page. That is why the README can list web controlling computer, web controlling Android, and web controlling web as first-class combinations. A RustDesk-style native stack does not give you a browser as the controlling endpoint for free.

The trade-off runs the other way too. WebRTC brings browser codec negotiation and TURN behavior you do not control, and a relay is a separate service to operate. A custom protocol can be tuned for a single purpose. BilldDesk's custom relay server option lets you host the relay yourself.

Against ToDesk, the README's own table is the clearest statement: the open source edition has no connection, quality, frame rate or channel limit, and Pro adds free Android control, privacy screen and virtual screen, where ToDesk charges per tier. The counterweight is that ToDesk is a managed service with support and a tested installer, and BilldDesk asks you to run the backend. The table also shows BilldDesk Pro capping free use at 1080p and 30 fps while the open source edition has no such cap, with source access for Pro behind a subscription. If you want the uncapped path, the open source edition is the one to read.

Maintenance, licensing and what upgrading costs you

The repository is not archived and the last push was on 2026-10-29, so there is recent activity. The repository has no published GitHub releases, which means versioning is driven by standard-version and conventional commits from the local scripts rather than by tagged GitHub releases you can pin to. package.json declares version 0.0.1, and the release script is standard-version, so expect version numbers to move with commit history rather than a published support policy.

The licence is MIT, stated both in the repository metadata and in the LICENSE.txt file at the top level. MIT is permissive: you can use, modify and redistribute the code, including in commercial settings, provided the copyright notice and permission notice are preserved. That is a statement about the licence text, not legal advice, and it applies to the open source edition. The README separately describes BilldDesk Pro as requiring a source subscription, so do not assume the Pro code is covered by the same terms as what is in this repository.

Upgrade cost is where the platform matrix bites. The README lists remote client version update for Windows and online update of the controlled client from the controlling side for Windows. That means the upgrade story is asymmetric: Windows endpoints can be pushed forward, and macOS and Android endpoints have no documented remote update path. If you deploy across a mixed fleet, budget manual updates for the non-Windows machines. Because no releases are published, an upgrade means pulling main and rebuilding, and the build scripts run standard-version first, which will write a new version and changelog into your working tree.

Editorial conclusion

Adopt BilldDesk if you already run Node.js and want a web-initiated remote session with no monthly connection cap, or if you need Android as a controlled endpoint without buying a plugin. Skip it if your fleet is Linux or iOS, both of which the README lists as unsupported, or if you need a documented one-command Docker deployment, since Docker one-click deployment is still an unchecked item. Before you commit, verify that your NVIDIA driver is at 570.0 or newer if you want the H264, H265 and AV1 hardware encoding path, and confirm that the custom relay and wss/api endpoints you plan to point at are reachable from every client network you support.

Frequently asked questions

Official sources

1. galaxy-s10/billd-desk on GitHub
2. Issues
3. License: MIT
4. Project website
5. README