Deskreen CE: turn any browser into a second screen

What Deskreen CE solves, and for whom

The problem is mundane and expensive: you want more screen area, and you do not want to buy a monitor. Deskreen turns any device with a web browser into a secondary screen for your computer. The viewing device needs no app, no account and no driver. A tablet, an old laptop, a phone, a TV with a browser: if it can open a URL, it can display a stream from the host machine.

The project is an electron.js application that uses WebRTC to make a live stream of your computer screen to a web browser on any device. It ships for MacOS, Windows and Linux. The README is explicit that the open-source Community Edition has limited features and points readers to a Pro version at deskreen.com/download for more features when it is released. So the honest framing is this: Deskreen CE is the free tier of a product whose paid tier is announced but not yet available. If you adopt CE today, you are adopting what exists, not what is promised.

Who is it for? People with a spare browser-capable device sitting in a drawer. People who want to share a single application window rather than the whole desktop, a capability the repository topics list as share-app-window. And people on a mixed fleet, since the platform badge covers Windows, MacOS and Linux and the viewer side is browser-agnostic.

How the WebRTC stream reaches the browser

The architecture visible in the repository is a two-part build. The Electron main process lives at ./out/main/index.js per package.json, and a separate client viewer application lives in src/client-viewer with its own package.json and its own Vite dev server on port 5174. The host app captures the screen or a window, negotiates a WebRTC connection, and the client viewer renders the incoming media in the browser.

The npm scripts tell you how the two halves are wired together during development: the dev script runs electron-vite dev and the client viewer side by side with concurrently. The build script runs typecheck, then buildClientViewer, then electron-vite build. That ordering matters because the viewer must be compiled before the Electron bundle that serves it.

The repository topics mention darkwire-io and end-to-end-encryption, and the licence section credits simple-peer and tweetnacl. That combination suggests the signalling and peer connection layer is built on simple-peer with tweetnacl for the cryptographic primitives, an arrangement inherited from darkwire.io. The README itself does not document the signalling protocol or the key exchange, so if you need to audit the security model, the source is the place to look, not the README.

Installing Deskreen CE from source

The README states the prerequisites plainly: node>=v23 and npm>=10. There is no published package manager command in the README, so cloning the repository is the documented path.

git clone https://github.com/pavlobu/deskreen.git
cd deskreen
npm i
cd ./src/client-viewer && npm i && cd ../..

The fourth step installs the viewer's dependencies separately, because src/client-viewer is its own package. Then the README gives a single command that cleans, builds and starts in production-like mode:

npm run clean && npm run build && npm run start

npm run build runs the typecheck suite across the client viewer, the node side and the web side before building, so a type error stops the build rather than producing a broken bundle. npm run start is electron-vite preview, which serves the built output. If you want the hot-reload loop instead, npm run dev starts electron-vite dev alongside the client viewer on port 5174.

One practical note: the clean script runs rm -rf on dist, out and src/client-viewer/dist, so it is a Unix-style command. On Windows you will need a shell that understands it, or you skip clean.

Pointing QR codes at the right network interface

The README documents a CLI flag that solves a real annoyance: when a machine has several network interfaces, the QR code and connection URL can point at an address the viewing device cannot reach. Deskreen CE accepts --local-ip or --ip to force a specific address.

On macOS the documented form uses open with --args:

open -a "Deskreen CE" --args --ip 192.168.1.100

On Linux, the README gives both the AppImage and the packaged-binary forms:

./Deskreen\ CE-*.AppImage --ip 192.168.1.100
deskreen-ce --ip 192.168.1.100

On Windows the README shows PowerShell's Start-Process with the argument list. The README also gives the commands to find your own address: ipconfig getifaddr en0 or ifconfig | grep "inet " on macOS and Linux, and ipconfig on Windows, looking for the IPv4 Address.

The README adds an important detail about how this flag behaves: the app uses the specified IP for QR codes and connection URLs, while still monitoring the actual network interface status for WiFi connection detection. In other words, the flag changes what you are told to connect to, not what the app believes about your link. If the two disagree, the app's WiFi detection wins for its own internal logic.

Where Deskreen CE is the wrong tool

Latency is the first constraint. WebRTC over a local network is good enough for a document, a terminal or a chat window. It is not a substitute for a physically attached display when you are scrubbing a timeline or playing a game. The README makes no latency claim, and none should be assumed.

The second constraint is the feature split. The README says the current open-source Community Edition version has limited features, and directs readers to the Pro version for more features when it is released. If a specific capability you need is not in the CE build you are running, the README does not promise it will arrive in CE later.

The third is licensing. AGPL-3.0 is a strong copyleft licence. If you plan to embed Deskreen CE in a product you distribute, or to offer it as a network service, the licence terms are yours to review with your own counsel. Nothing here is legal advice, but the choice of AGPL-3.0 rather than MIT is deliberate and it constrains commercial reuse in ways the permissive dependencies listed in the README do not.

Finally, the documentation gap. The README covers installation, the custom IP flag and the licence credits. It does not document rollback, a troubleshooting section, or the signalling protocol. When something fails to connect, you are reading source, not docs.

Deskreen CE compared with a virtual display driver

The obvious alternative approach is a virtual display driver paired with a viewer app, the model used by tools such as spacedesk. The difference is architectural, not cosmetic. A virtual display driver installs a display adapter on the host, so the operating system believes a real monitor is attached. That means the extra screen appears in your display settings, windows can be snapped to it, and the host treats it exactly like hardware.

Deskreen takes the opposite route. It does not add a display to the operating system. It captures what is already on screen and streams it over WebRTC to a browser. That is why the viewer device needs nothing installed, and it is also why the second screen may not appear in your OS display arrangement the way a driver-based solution would. The repository topics include share-app-window and share-screen, which reflects this capture-and-stream model rather than a virtual monitor.

The practical consequence: if you need the OS to treat the remote screen as a true extended desktop, a driver-based tool fits better. If you need zero installation on the viewing side and a browser is all you have, Deskreen's model is the one that works.

Maintenance, releases and the AGPL-3.0 boundary

The repository is not archived. The last push was on 2026-07-08, and the most recent release, v3.2.16, was tagged the same day. Before that, v3.2.15 landed on 2026-05-05 and v3.2.14 on 2026-02-08. That is a cadence of roughly one release every two to three months across 2026, with the package.json version matching the latest tag at 3.2.16.

Upgrade cost is low if you build from source: git pull, then npm i when dependencies change, then the same clean, build and start sequence. There is no migration step documented, because there is no database or persistent state described in the README. The build is stateless, which is the good news. The bad news is that the README does not document a rollback procedure, so if a new release misbehaves you are pinning a git tag yourself.

On licensing: Deskreen CE is AGPL-3.0, copyright Pavlo (Paul) Buidenkov. Its dependencies are permissively licensed (MIT for Electron-Vite, React, Vite, electron-builder and simple-peer; Apache 2.0 for blueprintjs; ISC for tweetnacl; MIT for darkwire.io). The AGPL-3.0 obligation attaches to Deskreen itself, not to those libraries. If you modify and distribute it, or expose a modified version over a network, the AGPL-3.0 terms apply. Consult your own legal counsel about your specific use.

Editorial conclusion

Deskreen CE suits people who already own a spare laptop, tablet or phone and want a second screen without buying hardware or installing an agent on the viewing device. It is the wrong tool if you need low latency for gaming or video editing, or if you cannot accept an AGPL-3.0 licence in your workflow. Before adopting it, verify that your Node version is 23 or newer, that the viewer device and the host are on the same WiFi network, and that the --ip flag points at the interface you actually want the QR code and connection URL to use.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. pavlobu/deskreen on GitHub
3. Project website
4. README
5. Releases