rustdesk
9.0 KiB
publishDate, lang, translationKey, draft, title, excerpt, image, category, tags, author, metadata
| publishDate | lang | translationKey | draft | title | excerpt | image | category | tags | author | metadata | ||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2026-07-06T00:00:00Z | en | why-self-host-remote-desktop-software | false | Why Self-Host Your Remote Desktop Software | Why teams leaving TeamViewer and AnyDesk are choosing to self-host remote desktop: data control, predictable cost, and no cloud in the middle. | ~/assets/images/blog/why-self-host-remote-desktop-software-og.png | Guides |
|
RustDesk Team |
|
Self-hosting is often evaluated when organizations want more control over price, features, and infrastructure. This article focuses on those structural trade-offs.
There is another way to run remote access, and it is not new — it is just less marketed, because it doesn't come with a recurring cloud subscription attached. It's the decision to self-host your remote desktop software: run the server that coordinates connections and relays traffic when direct connectivity fails on infrastructure you control. This article makes the case for that model and uses RustDesk as the concrete example.
What "self-host remote desktop" actually means
Most mainstream remote-support tools are cloud-only. When your technician connects to a client's PC, the session is coordinated — and often relayed — through the vendor's servers. That's convenient. It also means your device list, your connection metadata, and sometimes your session traffic pass through a third party, on their uptime, under their pricing, subject to their security posture.
Self-hosting flips that. With RustDesk Server Pro, the ID/rendezvous server, relay, console, and stored deployment data run on your infrastructure. Direct sessions still flow between endpoints; relayed sessions use your configured relay. The core client is open source (AGPL) and the free community server runs indefinitely—the auditability argument for that is its own topic; this piece stays on the self-hosting decision itself.
Four reasons the self-hosted model wins
1. You control the server-side infrastructure
Self-hosting lets you choose where rendezvous, relay, console, and device data run. Direct connections still travel between endpoints, so self-hosting alone does not guarantee in-country traffic or GDPR compliance. Document the full data flow and obligations.
2. Predictable cost, not an annual surprise
A common pattern is that one renewal hike pushes a team off a cloud tool, and the next vendor increase makes them re-evaluate the model itself rather than just the brand.
RustDesk licensing is per login-user plus per managed-device. Standard plans include unlimited concurrent connections; Customized V2 limits and prices them separately. For current numbers, see rustdesk.com/pricing.
3. No vendor lock-in, no cloud outage dependency
Self-hosting moves the coordinating-service failure domain into your own operations, where you can design redundancy and recovery. Open source also reduces dependence on a single vendor's roadmap.
4. It scales, and it's built for IT teams
Self-hosting doesn't mean settling for a toy. RustDesk publishes large-fleet planning guidance for teams that need to support bigger estates. For MSPs and internal IT, there's a self-hosted web console, a custom-branded client generator, and device groups plus a shared address book for per-user access control. LDAP/SSO (OIDC) is available from the Basic plan and up.
Cloud-only vs. self-hosted, at a glance
| Typical cloud-only tool | Self-hosted (RustDesk Server Pro) | |
|---|---|---|
| Where sessions are brokered | Vendor's cloud | Your on-prem box or VPS |
| Data residency | Vendor-controlled | Server-side services run on infrastructure you control; endpoint routes still matter |
| Concurrent-connection limits | Often per-channel/seat | Standard plans unlimited; Customized V2 metered |
| Pricing model | Per-seat/per-channel cloud subscription | Per login-user + per managed-device (pricing) |
| Source code | Closed | Open source (AGPL), auditable |
| Outage dependency | Vendor uptime | Your own ops |
| Who runs the server | Vendor | You |
The honest caveat
Self-hosting is a trade, not a free lunch. Someone on your side has to run the server: provision a host, open the right ports, set up TLS, and keep it patched. That's real, ongoing work. If what you actually want is a zero-maintenance managed SaaS with no server to run, be clear-eyed — RustDesk Server Pro is self-hosted by design, and it is not that. The upside of doing the ops is exactly the control described above; if your team can't own a server, this model isn't for you, and that's fine.
The good news is the bar to find out is low. You don't need a sales call to evaluate.
What running the server actually involves
The control described above is inseparable from the operational work that buys it. Before you commit, here's the concrete reality — not a feature list:
- Provision a host. A modest Linux VM — on-prem or a VPS you rent — runs the ID/rendezvous and relay services. Size it for your device count and how much traffic ends up relayed rather than peer-to-peer.
- Open only the ports you use. Native RustDesk clients require TCP 21115-21117 and UDP 21116 for NAT testing, connection services, registration, heartbeat, and relay. Do not expose the whole 21114-21119 range. TCP 21118-21119 are WebSocket backends, and TCP 21114 is the Pro HTTP API/console backend. When an HTTPS/WSS reverse proxy fronts the Pro API and WebSocket services, expose only TCP 443 publicly for that traffic and keep 21114 and 21118-21119 internal. Public 443 does not replace the native-client core ports when native clients also connect. See the official port reference.
- Set up TLS. Terminate HTTPS and WSS at the reverse proxy so credentials, API calls, and browser-client traffic use public TCP 443 rather than exposing the plain-HTTP console/API or raw WebSocket backends.
- Back up. The server holds your device inventory, user accounts, address book, and access rules. Schedule backups — and actually test that you can restore from them.
- Keep a patch cadence. New server builds ship over time, and you own the OS underneath. Decide who applies updates and how often.
- Monitor it. The coordinating service is now yours, so you watch uptime, disk, and relay throughput. When it goes down, nobody else is paged.
How to evaluate self-hosting
- Self-host the free open-source community server today. The core is AGPL — deploy it, audit it, and run it indefinitely at no cost.
- Want to try the Pro features? Email sales@rustdesk.com to ask about current evaluation terms, or check rustdesk.com/pricing for standard plan rates.
- Prefer to see it first? Watch a full video demo on the RustDesk YouTube channel — no booking required.
If price hikes, closed code, or a cloud you don't control are what pushed you to start shopping, self-hosting is the structural fix, not a discount. Own the server, own the data, own the cost.