RustDesk Server — Running Your Own Relay for Remote Access
What it is
RustDesk Server is the part of the project that lets organizations stop depending on the public relay. It’s basically two small services — hbbs (the broker) and hbbr (the relay) — that together replace the cloud middleman used by most commercial remote desktop tools. With them, admins decide where the traffic goes, whether it stays inside the LAN or runs through a server in their own data center. For companies under compliance pressure, that control is often the main reason to pick RustDesk over alternatives.
How it works
The setup is fairly direct. Clients first check in with hbbs, which handles discovery and handshake. If the two endpoints can talk directly, they do. If not, data is pushed through hbbr as a relay. Both services can be dropped onto a Linux VM, run in Docker, or even built into a Kubernetes cluster if scale is needed. Security relies on keys: each server has its own, and clients must trust it before starting a session. That way, traffic is encrypted end to end and not readable by the relay itself.
Technical profile
| Area | Details |
| Purpose | Self-hosted backend for RustDesk connections |
| Components | hbbs (broker), hbbr (relay) |
| Platforms | Linux servers; Docker and K8s supported |
| Features | Peer discovery, relay traffic, session logging |
| Authentication | Public-key trust model |
| Security | End-to-end encryption, TLS |
| Licensing | AGPL (open source) |
| Deployment | Binary install, Docker container, Kubernetes cluster |
Why admins use it
Keeps remote traffic under corporate control instead of sending it to a vendor relay. Works well in industries where regulators don’t allow SaaS for remote support. Lightweight: the binaries are small, easy to deploy, and don’t demand heavy hardware. Scales if needed — one node can serve small offices, while clusters can support large environments. No subscription costs, only infrastructure the company already runs.
Usage scenarios
– A bank hosting hbbs/hbbr internally so support staff never rely on external servers.
– Universities giving students lab access through a self-run relay.
– MSPs hosting RustDesk servers for customer fleets.
– Enterprises replacing TeamViewer/AnyDesk cloud with a controlled in-house system.
Security notes
Running your own relay shifts responsibility. Keys must be distributed securely, otherwise rogue servers could pose a risk. Admins usually front these services with reverse proxies, enable logging, and tie monitoring into existing SIEM tools. Since RustDesk is still maturing, keeping up with releases is important — updates bring security fixes and better stability.
Limitations
Documentation can feel thin; community forums are often the best source. No polished admin dashboard, most configuration is still CLI. Scaling beyond a single relay takes planning — load balancing, redundancy, etc. Compared to commercial “on-prem” products, vendor-backed support is limited.
Comparison snapshot
| Tool | Strengths | Best fit |
| RustDesk Server | Free, open, self-hosting | Orgs needing full data control |
| AnyDesk On-Prem | Commercial, vendor support | Enterprises with budget for vendor SLA |
| TeamViewer Tensor | SaaS, enterprise integrations | Global support teams preferring managed cloud |
| MeshCentral | Open-source, Intel AMT support | Companies managing hardware-level access |
| Apache Guacamole | Browser-only, clientless | Mixed estates with preference for web access |
Minimal checklist
– Set up a Linux host or VM.
– Install hbbs (broker) and hbbr (relay).
– Generate keys and distribute them securely.
– Configure clients to trust the new server.
– Test P2P and relay connections.
– Add monitoring and keep packages updated.