OSS provides the connection backend for RustDesk clients
RustDesk Server OSS includes hbbs for ID and rendezvous, and hbbr for relaying traffic when direct peer-to-peer connectivity isn't possible. That makes it relevant when you have already chosen RustDesk and want to operate its connection infrastructure. The server repository doesn't replace the desktop clients. Its build also produces rustdesk-utils, a set of CLI utilities, rather than a desktop-control interface for an administrator.
The official OSS overview directs readers needing a web console, API access, OIDC, LDAP, 2FA or centralized device management to compare Pro. Decide which of those requirements you have before treating the free server as your remote-support platform. A team comfortable distributing client settings can evaluate the core backend. A fleet administrator shopping for a management console has a different product decision to make.
What happened when we ran it
Our sandbox run at commit 08cd442 on November 4, 2026 recorded a successful 13-second installation step and a successful 277-second build. It recorded 482 dependencies. The checkout contained 142 files, approximately 17,383 source lines and 1.7 MB. The source tree's small disk footprint doesn't describe the compilation effort: building the Rust code was the longest recorded step, and no installed-environment size was supplied.
The cargo test step succeeded in 28 seconds, reporting 19 passed and zero failed out of 19. The scan found one CI workflow, a Compose file and a tests directory, with no Dockerfile detected. Those are concrete repository results. They do not establish that two clients connected, that a relayed session remained usable, or that the Compose deployment was exercised. No security-audit result accompanies the supplied record.
Our measurement setup specified 3 CPUs, 12 GB RAM and image lab-rust:1. That image name doesn't identify the compiler or operating-system version. The build duration applies to this checkout and sandbox, without a comparison against another machine or installation route. We have no measured remote-session latency, relay throughput or concurrent-client capacity, so none of those can support a sizing recommendation here.
Relay key validation needs a deliberate choice
The current configuration reference says hbbr defaults to an empty key, which disables relay key validation. It describes this as intentional, avoiding key-pair setup and mismatch failures. On an exposed relay, I would decide explicitly whether that behavior fits the deployment. The documented way to enable validation is to give the relay the same non-empty key as hbbs.
The two binaries have different defaults: hbbs loads or generates a key pair by default, while hbbr's empty default doesn't. The reference also distinguishes the supervisor container image from the classic image, which ignores the supervisor's convenience variables. Copying an example for the wrong image can therefore leave a setting ineffective. These are documented configuration boundaries. We did not observe network traffic or verify key rejection in our sandbox.
Network reachability and persistent state still need verification
The reference lists hbbs registration on TCP and UDP port 21116 and the relay on TCP port 21117, with additional ports for NAT testing and WebSocket routes. It says the WebSocket ports are only needed for the web client. Choose the deployment instructions for the clients you intend to use, then verify their network path. An open listener alone doesn't demonstrate that a remote device can reach the advertised server.
By default, hbbs creates its SQLite database in the working directory, and key material also lives in the working directory. Record and preserve that location when setting up service supervision or persistent storage. The reference separately marks the bind-address option as available since 1.1.17. That version qualification matters when reading current source documentation alongside an older binary. Our source checks don't verify that every documented option exists in every downloadable release.
Recent activity doesn't establish support coverage
GitHub's repository metadata reports the last push on November 4, 2026. Recent issue activity includes issue 740, a Docker hbbr debug-logging report opened October 28 and closed October 31. Together, those observations show activity beyond a release tag. They don't establish a support response guarantee, nor does that closed report prove that our chosen deployment will log or relay correctly.
Documentation scores 4/5 and maturity 3/5 on an editorial scale: 1 means missing foundations, 2 major unresolved gaps, 3 a usable evaluation path with caveats, 4 detailed supporting evidence, and 5 independently validated breadth. Setup and community remain unassessed. The passing Rust checks support evaluation, while the absence of a measured remote session prevents a broader operating recommendation.
Browser management points to different projects
MeshCentral documents web-based remote desktop, terminal and file management through agents installed on managed computers. Evaluate it when that management site is what your team needs. Apache Guacamole is an HTML5 desktop-access application using remote desktop protocols. It is a candidate when the browser should be the entry point. Neither is a drop-in replacement for RustDesk's connection backend, and we have no comparative performance results.
For a RustDesk trial, connect representative clients through your intended network, then verify both the direct path and a relayed session. Confirm where state persists and whether relay key validation behaves as configured. Those are the results an operator needs before trusting the server with recurring support work.