RD-API-Server v1.6.1

Four fixes to the browser remote desktop, three of them reported from live deployments, plus the documentation that would have prevented one of them.

You can see your pointer again

"I don't see a mouse at all while trying to control, but the mouse does work if I click."

The viewer hid the local pointer unconditionally, assuming the peer's cursor would replace it. Two things were wrong with that.

The peer suppresses cursor-position updates toward whoever is sending input — deliberately, so a native client's own pointer does not fight an echoed one. A browser viewer that has also hidden its local pointer is left with a remote pointer that lags or stops, and nothing to aim with.

And the peer sends no cursor at all unless asked, because a native client draws its own.

Mode	Local pointer	Why
Controlling	Always visible	It is the one that tracks your hand
Watching, remote cursor present	Hidden	The remote pointer is the interesting one; two are noise
Watching, no remote cursor	Visible	Better than none

The viewer now also requests the peer's cursor at login, so there is a remote pointer to show.

A connection in progress can be cancelled

Connecting to a machine that asks its user to accept left the viewer waiting with no way out — Disconnect lives in the toolbar, and the toolbar only exists once a session is established.

Cancel now appears for the duration of the negotiation. A deliberate cancel is not retried: closing the socket surfaces as a transport failure, which the reconnect policy would otherwise treat as a transient drop, turning Cancel into a pause.

A configured WebSocket endpoint is validated

The browser refused the URL: Failed to construct 'WebSocket':
The URL's scheme must be either 'http', 'https', 'ws', or 'wss'.
'rustdesk-hbbs' is not allowed.

RUSTDESK_WS_ID_URL=rustdesk-hbbs:21118 is an upstream pasted into the browser-facing setting. The browser is on someone's laptop; it cannot resolve a container name, and without a scheme it will not construct the socket at all.

Worse, the diagnostics page reported a healthy deployment, because it only checked the value was non-empty. It now names the mistake and the setting to use instead, and an unusable endpoint is no longer handed to the browser — so a deployment whose upstreams are correct keeps working despite a leftover variable.

A monitor change no longer blanks the session header

peer_info is re-delivered when the peer's displays change — docking a laptop, waking a monitor — and that copy carries the display list without the identity fields. Writing it straight to the header turned a working session into peer@undefined · undefined minutes in, which reads as a fault rather than a monitor being plugged in.

Documentation

The two variable pairs are the most common setup mistake, so they are now explained wherever an operator meets them — a table in the README, two labelled options in .env.example, and inline comments in the examples:

	Who dials it	What goes in it
RUSTDESK_WS_*_UPSTREAM	This container, over the Docker network	rustdesk-hbbs:21118
RUSTDESK_WS_*_URL	The operator's browser, over the internet	wss://host/ws/id

examples/simple.docker-compose.yml is new: the whole stack in one file, no .env, nothing optional — change four passwords and two hostnames. The full-stack example keeps the pinned digests and hardening notes; .env.example remains the complete reference.

Upgrading

docker compose pull && docker compose up -d

Nothing else.

Image

ghcr.io/gigaionllc/rustdesk-api-server:1.6.1

Multi-architecture (AMD64/ARM64), digest sha256:9dac880e4e441d480dcc13f23e9bd82b06467f43e14849d8d57cebe4af092ea7. The latest, 1 and 1.6 tags point at the same manifest.

Verification

699 PHP tests, 254 web-client unit tests, 17 browser tests, Pint and PHPStan.

Confirmed against a live peer through the published image: connected and encrypted, the peer's identity retained, the local pointer visible while controlling, a remote cursor decoded and drawn alongside it, and Cancel present throughout the negotiation.

Stated plainly: the peer used for that check was sending a cursor but no video frames. The previous release, run against the same peer minutes apart, behaved identically — so this is that machine's state rather than a change here. Video was verified end to end in v1.4.4 and is unchanged in this release, but it was not re-confirmed today.

---

Full notes: docs/releases/v1.6.1.md

RD-API-Server is an independent, third-party, open-source project. It is not affiliated with, endorsed by, or sponsored by RustDesk or Purslane Ltd.