Secure Desk
Account sign inStart free
Documentation

Documentation

Everything needed to put Secure Desk into production — written for whoever will be on call for it.

Secure Desk has two halves. A Node.js server on a Linux host serves the technician portal, the public join page, the browser console and the WebSocket relay. A native Windows client runs on each supported machine. You install the first once; the second gets distributed to the machines you support.

Read this first: who is who

The naming is consistent across the product, the protocol and these docs, and getting it backwards will make everything else confusing.

  • Client — the computer receiving support. It shares its screen and receives input.
  • Agent — the support technician giving support. They view the screen and send mouse and keyboard.
  • Relay — your server. It pairs an Agent and a Client and forwards bytes between them.

So: the Agent connects to the Client.

The short version

  1. Provision a Linux VM with a public DNS name, download the release, extract it and run sudo bash install.sh.
  2. Read the one-time setup token out of the service log, open /setup and create the admin account and TLS settings.
  3. Get an activation code, read the Node ID from Settings → License, activate, and paste the key back in. Skip this and you run as free Starter.
  4. Create a support session in the portal and send the join link — or install the client as a service on the machines you want unattended access to.

Nothing is configured from a file. On first start the relay prints a one-time setup token and funnels all traffic to /setup. Secrets are generated and stored in the data directory, not committed to a config you might paste into a ticket.

The Secure Desk portal dashboard immediately after installation, showing counters all reading zero for devices online, installed devices, customers, pending requests and active sessions, one session waiting and one portal user, a licence tile reading 'Starter · unlicensed', a prompt to set up two-factor authentication, and quick action buttons for a new support session, viewing requests and connecting to a device.
The portal right after step 2 — a fresh install with nothing enrolled yet. The licence tile reads Starter · unlicensed until you complete step 3.

Requirements

  • Server: a Linux host with Node.js 18 or newer. Developed and tested on Debian with Node 22.
  • Database: PostgreSQL in production — the Debian installer provisions it for you. Without DATABASE_URL the relay falls back to an in-memory store that is wiped on restart; that is for local development only.
  • DNS + TLS: a public name pointing at the host, with ports 80 and 443 reachable so Let's Encrypt can issue. Browsers will not open a WebSocket to an untrusted certificate.
  • Endpoints: Windows on the supported machines. The technician console runs in any modern browser, or as a native Windows application.

Where to go next

Install the portal →

The Debian installer, the Docker path, TLS, and the setup wizard.

Windows clients →

Portable versus installed service, enrollment, backstage and elevation.

Licensing & updates →

Tiers, the two-step activation, offline verification and auto-update.

Architecture & sessions →

Pairing, capture and encoding, desktop versus backstage session ids.

Security model →

The encryption scheme, the three identity planes, and the known limits.