RustDesk

RustDesk is a remote desktop and remote support solution that allows you to remotely maintain devices over the internet or LAN – including your own server option (self-hosted).

Self-hosting gives you control over connection setup/relay, infrastructure location and operational processes (firewall, updates, monitoring). This is particularly interesting for companies with data protection, latency or control requirements.

Typically two server services: hbbs = ID/rendezvous server (clients find each other through it) and hbbr = relay server (if no direct P2P connection is possible).

In the client under Menu → Network, enter the ID Server (hbbs host/IP); the Relay Server refers to hbbr (typically port 21117).

For encrypted connections, clients need to know your server's public key. The key is generated on first start and is usually located as id_ed25519.pub in the working/data directory.

Yes. The RustDesk documentation describes several ways: manually, via import/export of server configuration, and automated deployment via scripts/config string.

The API server is only relevant for RustDesk Pro (e.g., web console/login). For classic open-source self-hosted setups, many teams leave it empty.

The official documentation mentions TCP 21115-21119 and UDP 21116 (depending on use/setup). Also plan DNS/domain/reverse proxy according to your environment.

Both work. For productive setups, a domain is practical (clients, certificates, failover scenarios). In LAN/closed network environments, a fixed IP can also make sense.

Yes – but there's a common issue: NAT loopback. If server and clients are on the same LAN, they either need to use the local server IP or enable NAT loopback on the network.

This is a classic NAT loopback problem. The documentation mentions three solutions: NAT loopback on router, local DNS (e.g., AdGuard/Pi-hole) or hosts file rules.

Not necessarily. RustDesk attempts direct connections depending on network situation; if that doesn't work (firewall/NAT), hbbr can step in as relay.

Yes – a reverse proxy for domain/certificates/ingress policies is common. It's important to correctly map port and protocol requirements (TCP/UDP).

With self-hosting, you control the infrastructure components (hbbs/hbbr). You should also define in your operations concept what you log (e.g., connection logs) and for how long.

For small environments, a lean VM/instance is often sufficient; bandwidth/latency (especially for relay usage) and clean firewall rules are decisive.

Best practice: Define maintenance windows, test versions in staging first, have a rollback plan (snapshots/VM backups), then deploy to production. With Docker: pin images instead of 'latest'.

Typical: minimal port openings, expose server only behind firewall/VPN (if possible), restrict admin access, enable logs/monitoring, regular updates & restore tests.

Yes, depending on organizational structure: separate servers per location/tenant or a central server with clear policy. It's important to document data flows and responsibilities clearly.

The bottleneck is usually relay traffic (bandwidth/CPU), not the ID server. Scaling is done through better uplink capacity, separate relay servers, location proximity and clean network rules.

Most common: incorrectly opened ports/protocols (TCP vs. UDP), NAT loopback in LAN, missing key in client, and reverse proxy setups that don't correctly map UDP.