# CrossDesk: a GPL-3.0 remote desktop with a browser client and a C++ RTC core

> CrossDesk connects Windows, macOS and Linux desktops to each other, to a WebRTC browser client and to a native iOS client. It is built on MiniRTC, licenses itself under GPL-3.0, and asks you to grant screen recording and accessibility permissions before the first session.

**kunkundi/crossdesk** — A lightweight, cross-platform remote desktop software with support for Web Client access | 一款支持 Web 客户端访问的轻量级跨平台远程桌面软件。

- Repository: https://github.com/kunkundi/crossdesk
- Website: https://www.crossdesk.cn
- Stars: 4,327 · Forks: 410
- Language: C++
- License: GPL-3.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/kunkundi-crossdesk

## What CrossDesk is for, and who it fits

CrossDesk is a remote desktop program written in C++ and built on MiniRTC, the same project's real-time communication library. The README states the goal plainly: connect computers, browsers and iPhone or iPad to the same desktop. That sentence is the whole product scope. A Windows, macOS or Linux machine can be controlled from another desktop, from a browser tab, or from a native iOS client.

The people this fits are the ones who keep hitting the same wall: a colleague on a laptop without admin rights, a tablet on a different network, or a machine where you do not want to install a full desktop client just to look at something. The browser path removes that install step. The README says the Web client needs a WebRTC-capable browser and nothing else on the controlling side.

It fits less well if you want a managed fleet product. CrossDesk is a client and a protocol, plus a separately published server and web client. There is no mention of an admin console, an inventory of machines, or role-based access in the README. Pairing is by ID and password, and the ID and password are shown on the controlled machine's main window.

## How CrossDesk moves pixels and input: MiniRTC, P2P and TURN

The transport is the interesting part. CrossDesk does not proxy your desktop through a central server by default. The README lists P2P direct connection and TURN relay as separate modes, and the session control bar exposes a network status panel showing traffic, packet loss, frame rate, resolution, and whether the session is direct or relayed. That panel is the honest part of the design: you can see which path you got.

Signalling is separate from media. The client shows a "connected to server" state at the bottom of the window, and the self-hosted settings ask for a server address, a signalling port and a relay port. So the flow is: both ends register with the signalling service by ID, the service brokers the session, and media then tries to go peer to peer. When that fails, the TURN relay carries it, provided "enable relay service" is on. The README explicitly says to check that setting first when a P2P connection fails.

Media itself is H.264 or AV1, at 30 or 60 fps, with hardware encode and decode options. The README is careful here: actual capability depends on the device and the build configuration. It also lists SRTP as an encryption option for media transport, with the note that both ends must be configured compatibly. That phrasing matters. SRTP is a switch, not a guarantee, and a mismatch between two ends is a plausible source of a session that connects but carries nothing useful.

Input, clipboard text and file transfer ride along the same session. On Windows, the Ctrl+Alt+Del combination and the lock screen depend on a separate service, described below.

## Installing CrossDesk and making a first connection

There is no package repository step and no build required for normal use. The README points at GitHub Releases and at the official site, and the platform table gives the baselines: Windows 10 or newer on x64, macOS 14.0 or newer on Intel or Apple Silicon, Ubuntu 20.04 or newer on amd64 or arm64 with a glibc 2.31 baseline. On Linux the documented install is a .deb, after replacing the filename with the one you actually downloaded.

```bash
sudo apt install "./crossdesk-linux-amd64-<version>.deb"
```

On macOS the README is specific about the first launch: grant screen recording (which newer systems may label as screen and system audio recording) and accessibility in System Settings, then reopen the app. Screen recording is what lets it capture the desktop; accessibility is what lets it inject keyboard and mouse events. Skip either and you get a session that either shows nothing or cannot be driven.

The connection flow is three steps. Both machines run CrossDesk and wait until the window shows the server as connected. The controlled machine shows its local ID and password on the left. On the controlling machine you type the peer ID into the remote desktop field and confirm with the arrow button. After that, the device appears under recent connections, where you can rename it or delete the entry. Passwords are six digits or letters, and the README warns that after changing one you should wait for the client to reconnect before copying the new value, because a controlling machine holding the old password has to re-enter it. For the browser route, keep SRTP enabled on the controlled machine, open the web client, and enter the remote device ID and password there.

## The Windows service, and where control stops working

Windows has a second moving part. CrossDesk Service, registered under the service name CrossDeskService, handles the lock screen, the login screen, credential entry and the secure desktop. It reports state, sends Ctrl+Alt+Del, and forwards keyboard and mouse input to those protected surfaces. The installer registers it as an on-demand service that the client tries to start, and it exits once no CrossDesk client process remains. The portable build can install it from a prompt or from settings, and that needs administrator rights.

The failure mode is documented rather than hidden. If the remote Windows service is unavailable, ordinary desktop sessions still work, but control of protected screens is limited. That is the correct trade-off for a service that must run with elevated rights, but it does mean a machine that looks connected can still refuse to accept input at the login prompt.

For manual deployments the README keeps the whole install directory together. CrossDesk.exe, crossdesk_service.exe, crossdesk_session_helper.exe and all the DLLs from the same build must sit in one folder, and the service commands run from an administrator PowerShell in that folder.

```powershell
.\CrossDesk.exe --service-install
.\CrossDesk.exe --service-start
.\CrossDesk.exe --service-status
.\CrossDesk.exe --service-ping
```

A detail worth knowing before you deploy: closing the main window hides it and leaves the program running. Full exit is through the system tray or the menu bar. On a machine you are controlling remotely, that is usually what you want, and it is also why the process may still be there after a user thinks they quit.

## Self-hosting: signalling, TURN and the pieces you must run

CrossDesk can be pointed at your own infrastructure. The desktop client has a self-hosted section under settings where you enter the server address, the signalling port and the relay port, and enable the configuration. Both the controlling and the controlled side must use the same configuration; the README says this twice, once for desktop and once for the browser path.

The server work is split across two other repositories. CrossDesk Server holds the server source and release configuration. CrossDesk Web Client holds the browser client source and its self-hosting instructions. The repository also ships a docs/SELF_HOSTING.md covering the current Compose deployment entry point, client settings, certificate trust and troubleshooting. There is a docker directory in the repository root, which is consistent with a Compose-based deployment, though the README does not spell out the compose file contents.

The honest limitation is certificate trust. A self-hosted signalling and relay setup means your own TLS material, and the documentation treats certificate trust as its own troubleshooting topic. If you have never run a TURN server, budget time for that rather than for the client, which is the easy half. Note also that self-hosting does not remove the need for the relay setting on the client: P2P failure still falls back to TURN, and if you have not deployed one, sessions between difficult networks simply fail.

## iOS client, Web client, and the gaps between them

The native iOS client lives under apps/ios and speaks the same MiniRTC protocol as the desktop client. It is a controller, not a controlled endpoint: the README states it can control a remote computer and that turning an iPhone or iPad into a controlled desktop is not currently offered. If your use case is reaching into an iPad from a desktop, this is the wrong tool, and no setting changes that.

Building it means Xcode, signing, and an iOS 16 or newer physical device. CI artifacts are unsigned, so a developer account is part of the setup. Once running, the gesture model is defined: single-finger tap, two-finger right click, long press to drag, pinch to zoom, two-finger pan to move the zoomed view. Mouse mode is a real choice, with relative position acting like a trackpad and absolute position mapping the touch point straight onto the remote picture. Received files land in the app's Documents/Received folder and can be exported with the share button next to the transfer status.

Two asymmetries are documented and worth repeating. Clipboard support on iOS is receive-only: remote text can arrive in the iOS clipboard, but the interface has no button to send the local clipboard the other way. And the native and browser clients are maintained separately, so entry points and gestures may differ between them. That second point is a maintenance signal as much as a feature note.

## Alternatives, and the licence question

The obvious comparisons are RustDesk, AnyDesk and ToDesk, and the related searches around this project include all three. The difference that matters here is architectural rather than cosmetic. CrossDesk treats the browser as a control surface with no install on the controlling side, and it publishes its server and web client as separate repositories so you can host the signalling and relay yourself. RustDesk is also open source with a self-hostable relay, and it is the closest comparison; the practical distinction is that CrossDesk's browser client is a documented first-class path in the README rather than an add-on, and its desktop UI is built with Slint according to the project's own notes. AnyDesk and ToDesk are commercial products with their own account and licensing models, and the README does not compare itself to either.

Licensing is GPL-3.0. That is a strong copyleft licence, and it governs the client source in this repository. If you plan to embed CrossDesk in a product you distribute, the licence obligations follow the code, and that is a question for your own legal review rather than something this article can settle. The README also notes that the Windows installer bundles a third-party virtual display driver from Amyuni Technologies, which is a separate component with its own terms, and it links a privacy policy at PRIVACY.md. Neither the licence text nor the privacy policy is summarised in the README beyond those pointers.

On maintenance, the repository is not archived and the last push was on 2026-09-23. The release list shows v1.5.1-1-20260917 dated 2026-09-17. There is no published roadmap or support commitment in the README, so treat the release cadence as the only signal you have.

## Conclusion

Adopt CrossDesk if you want a GPL-3.0 remote desktop where the browser is a first-class control surface, you are willing to grant screen recording and accessibility permissions, and you can either trust the hosted signalling or stand up the self-hosted server and TURN relay yourself. Do not adopt it if you need to control an iPhone or iPad from a desktop (the native client is a controller only), if you depend on protected Windows screens without deploying CrossDeskService, or if you want to ship it inside a closed product, since the licence is GPL-3.0. Before rolling it out, verify the release notes for the exact build you download, confirm that both ends point at the same server when you self-host, and check that the password you set is six digits or letters.

## FAQ

### How do I connect to another computer with CrossDesk?

Run CrossDesk on both machines and wait until the window shows the server as connected, then read the local ID and password from the controlled machine. On the controlling machine, enter the peer ID in the remote desktop field, click the arrow, and type the password in the dialog that appears.

### Can I use CrossDesk without the hosted server?

Yes. The README documents self-hosting signalling and TURN relay, configured under settings with a server address, signalling port and relay port, and both the controlling and controlled ends must use the same configuration. The server and web client sources are published as separate repositories.

### Why does CrossDesk not work on the Windows lock screen?

Lock screen, login and secure desktop input depend on CrossDesk Service, registered as CrossDeskService. If it is not installed or not running, the README says ordinary desktop connections still work but control of protected screens is limited.

## Sources

- [kunkundi/crossdesk on GitHub](https://github.com/kunkundi/crossdesk)
- [License: GPL-3.0](https://github.com/kunkundi/crossdesk/blob/p2p-enhancement/LICENSE)
- [Project website](https://www.crossdesk.cn)
- [README](https://github.com/kunkundi/crossdesk/blob/p2p-enhancement/README.md)
- [Releases](https://github.com/kunkundi/crossdesk/releases)

---

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