RustDesk is an open-source remote control tool, which means you’re not locked into its public relay servers the way you are with closed-source tools — you can run your own signaling and relay server instead. Self-hosting keeps all connection traffic inside infrastructure you control rather than a third party’s, but it also means you’re now responsible for keeping that server running around the clock. Before committing to it, it helps to understand exactly what self-hosting involves and where the real tradeoffs land.
Why RustDesk Supports Self-Hosting
Because RustDesk’s source code is public, its two server components — hbbs (the ID and rendezvous server) and hbbr (the relay server) — can be installed on any Linux machine you control. Once they’re running, your clients connect through your own server instead of RustDesk’s public infrastructure, giving you full ownership of connection logs and the network path your sessions travel.
Basic Self-Hosting Setup
- Provision a Linux VPS with a public IP address (1 vCPU / 1GB RAM is enough to get started).
- Download the official hbbs and hbbr binaries from rustdesk.com or GitHub (rustdesk/rustdesk-server), or pull the official Docker image.
- Open ports 21115–21119 (TCP) and 21116 (UDP) in your firewall.
- Run hbbs and hbbr as background services on the server.
- Note the public key that’s generated the first time the server starts.
- In each RustDesk client’s network settings, enter your server’s ID server address, relay server address, and public key.
Once configured, test the connection between two of your own devices before rolling it out to anyone else, so you can confirm the ports are actually reachable from outside your network.
The Upside of Self-Hosting
No connection metadata or session traffic passes through a third-party server — everything stays on infrastructure you manage end to end. That matters for organizations with strict data residency or compliance requirements, and for anyone who simply doesn’t want session data leaving their own network. You also avoid any rate limits, session caps, or usage restrictions that a shared public server might impose during heavy use.
The Downside of Self-Hosting
Running the server is entirely on you. That means applying OS security patches, managing firewall rules and exposed ports, and handling downtime yourself, with no official support line to fall back on when something breaks. If you don’t have prior experience running a Linux server, the initial setup can be a real obstacle, and as usage grows — more users, more simultaneous sessions — you’ll need to scale the server’s resources yourself and keep an eye on it.
If you’re relying on a self-hosted RustDesk server for daily remote work or accessing a home or office PC, plan to actively monitor its uptime. If the operational overhead becomes too much for your team to carry, pairing it with a managed remote control service for your most critical machines is a reasonable middle ground.
If you’re supporting remote work or IT at scale, take a look at Y-Remote, a browser-based remote access service.