RustDesk: The Open-Source Remote Desktop That Lets You Own the Relay Server

"The reason your remote desktop session is slow and your screen data is somewhere else's server is the same reason: you don't own the relay. RustDesk fixes that part first."

If you have ever watched TeamViewer slap a "commercial use detected" banner on your free session, or felt the lag of a support call routed through a vendor's crowded relay, you have already met the problem RustDesk solves. RustDesk (GitHub: rustdesk/rustdesk) is an open-source remote desktop written in Rust, and its defining move is simple: you can run the ID server and the relay server on your own hardware, so your screen, keystrokes, and transferred files never transit a third party's infrastructure. As of August 2026 it carries 113,000+ stars (top-100-open-source territory), is licensed AGPL-3.0 for the community core, and is developed by Purslane Ltd (Singapore / Cayman Islands). For a blog about software you control, it is the cleanest possible answer to "how do I remote into my stuff without renting it." This is the honest breakdown: how the connection actually works, what the paid Pro tier really gates, where your pixels land, and the AGPL clause that bites if you try to embed it in a proprietary product.

1. What RustDesk Is (and Isn't)

RustDesk is not a VPN and not a "access your files" app. It is a remote desktop — you see a remote machine's screen and drive its mouse and keyboard, exactly like TeamViewer or AnyDesk. The difference is ownership. The client is free and open; the server half (called RustDesk Server) is also free and open, and you are explicitly invited to host it yourself. There are two pieces to understand:

• The client — native apps for Windows, macOS, Linux, Android, and iOS (viewer), plus a web client you can host on your own domain.
• The server — two tiny Rust binaries: hbbs (the ID / rendezvous server: device registration, presence, NAT-traversal negotiation) and hbbr (the relay: it only carries traffic when a direct peer-to-peer connection fails).

Crucially, hbbs never sees your screen. It is the introducer. hbbr only carries pixels when P2P can't be established (symmetric NAT, strict firewalls). When P2P works — which is most of the time on reasonable networks — the relay is bypassed entirely and your session is direct.

2. The Connection: P2P When Possible, Your Relay When Not

The flow is worth tracing because it is where the privacy claim lives: 1. The controlled machine starts, gets a random ID and a temporary password, and registers its reachability with hbbs. 2. The controlling machine types that ID; hbbs introduces the two endpoints. 3. They attempt a UDP hole-punch for a direct P2P connection. 4. If P2P succeeds, screen/keyboard/file traffic flows directly between the two machines. The server was just the matchmaker. 5. If P2P fails, traffic routes through your hbbr relay — not RustDesk's, not a vendor's. This is the structural advantage over any cloud-only vendor. With TeamViewer or AnyDesk, every session is potentially observable and is absolutely dependent on their infrastructure. With self-hosted RustDesk, even the relay is yours, and the connection is end-to-end encrypted with NaCl — the same crypto library Signal uses. Session data does not leave your control, and a vendor outage can't take your access down. The encryption point deserves emphasis: even when traffic goes through hbbr, it is E2E-encrypted such that the relay cannot read it. A relay that can't read what it relays is the whole point.

3. Self-Hosting: Owning hbbs and hbbr

The headline feature is one Docker Compose file. The official OSS deployment is documented as three steps: install Docker, download oss.yml, and docker compose up -d. Ports 21115–21119 need to be open (rendezvous, relay, API, and the NAT-traversal range). You generate an encrypted key pair during setup; clients are configured with that key so only your relay accepts them. Why bother self-hosting at all? Three reasons:

• Data sovereignty. Screen, keystrokes, and transferred files never transit a third party. For regulated or privacy-sensitive work this is the entire ballgame.
• No noisy neighbors. You are not sharing a crowded commercial relay; your sessions get your bandwidth.
• No per-seat pricing. TeamViewer bills per technician per month. Self-hosted RustDesk bills $0 for the core, forever.

The honest cost of self-hosting is operational: you run two small binaries, you keep them updated (security patches matter — see limitations), you back up the key and database, and you ensure the host stays up. For an IT team this is trivial; for a home user helping a relative, it is a Saturday project.

4. The Pro Tier: What AGPL-3.0 Does and Doesn't Cover

This is the section the README under-states, and it is the most important for a business reader. The community core is AGPL-3.0 and free. But a set of centralized-management features are gated behind the proprietary Pro tier:

• Web console (manage everything from a browser) — Pro.
• LDAP / OIDC SSO — Pro.
• 2FA (TOTP) at the server level — Pro (the client has its own, but centralized 2FA is Pro).
• Session auditing / logging — Pro. This is the one regulated industries care about most.
• Device management (centralized, multi-user) — Pro.

Pro pricing runs roughly $9.90/month for 1 user / 20 devices up to $19.90/month for 10 users / 100 devices on annual billing (figures from 2026 community sources; confirm current pricing before committing). None of this touches the core remote-desktop capability — unattended access, permanent passwords, E2E encryption, and your own relay are all in the free core. But the moment you are managing more than a handful of machines or need an audit trail for compliance, Pro becomes a practical necessity. For a homelabber or a solo IT person, the free core is everything. For an MSP or a compliance-bound team, budget Pro.

5. The Cost, Honestly

Software: $0 for the AGPL-3.0 core, indefinitely. No per-seat, no metering. Relay infrastructure: a lightweight VPS — the rendezvous server handles thousands of concurrent sessions on modest hardware. Call it $3–$10/month for a small VPS, or $0 if you run it on existing hardware. This replaces TeamViewer's ~$50+/month per technician. Your time: Low for a basic Docker deploy, intermediate for production hardening (key management, firewall, backups, HA relay). The community edition supports high-availability multi-relay configs; centralized management of that needs Pro. The hidden cost everyone forgets: you now own the uptime of your own remote-access layer. If your relay host dies, you can't reach your machines — exactly when you need to. Run the relay on resilient hardware, monitor it (see the Uptime Kuma piece), and back up the key. Same "watch the watcher" chore as every self-hosted service. Against TeamViewer's recurring per-seat bill, the self-hosted RustDesk core is not just cheaper, it is a different ownership model: the relay is yours, the data never leaves your infra, and a vendor can't flip a switch on your access.

6. Honest Limitations

• The AGPL trap. AGPL-3.0 is strong copyleft. Internal, unmodified use is free. But if you modify the code and offer it as a network service, you must publish your modifications. If you are building a proprietary SaaS that embeds remote desktop, RustDesk's license can force your hand. Apache-licensed alternatives (Apache Guacamole, MeshCentral) avoid this — pick them if embedding in closed software.
• Pro gates real enterprise features. Audit logs, SSO, web console, and centralized 2FA are paid. Community edition is great for individuals, thin for compliance.
• You run the relay. Unlike a pure SaaS, the availability of your access layer is your responsibility.
• Jurisdiction nuance. Purslane Ltd is Singapore-incorporated (outside US CLOUD Act reach) with Cayman governing law for Pro. That is generally a privacy plus, but read it if you operate under a specific regime.
• Patch discipline matters. Historical CVEs (e.g. the 1.4.6-era fixes for config-import crypto weaknesses) show that running an old relay is a real risk. Keep hbbs/hbbr current.
• No official managed SaaS. There is no "just sign up" hosted tier from the vendor; self-hosting (or Pro on your infra) is the model.

None of these are reasons not to use it — they are the reasons to use it knowingly.

7. Getting Started (Self-Hosted)

The official OSS path: ``bash

1. Install Docker (if needed)

bash <(wget -qO- https://get.docker.com)

2. Fetch the community compose file

wget rustdesk.com/oss.yml -O compose.yml

3. Launch

docker compose up -d ` Then open the ports 21115–21119, generate your relay key, and set that key in each client's network settings. From there, typed IDs connect directly or via your relay. For production, harden the host, enable 2FA (Pro) if you need it centrally, and monitor the relay's health. If you would rather not self-host the server at all, the free clients still work against RustDesk's public relay — but then you have traded away the data-sovereignty advantage that makes this worth writing about. For this blog's readers, self-hosting the relay is the point.

8. RustDesk vs the Alternatives

| | RustDesk (self-hosted) | TeamViewer / AnyDesk | Apache Guacamole | |---|---|---|---| | License | AGPL-3.0 (core) | proprietary | Apache-2.0 | | Self-host relay | ✅ | ❌ | ✅ | | E2E encryption | ✅ (NaCl) | ✅ (vendor) | ✅ (your infra) | | Cost | $0 core | $50+/mo per seat | free | | Audit/SSO | Pro only | enterprise tier | via config | | Embeds in proprietary SaaS | ⚠️ AGPL trap | ❌ | ✅ safe | | Setup | low→medium | zero | medium | The short version: for privacy-critical IT teams and individuals who will self-host, RustDesk is a strong buy — sovereign core, E2E encryption, your own relay. For embedding inside a closed product, the AGPL clause pushes you to Guacamole. For zero-maintenance users who don't care where pixels go, a cloud vendor is less work. Most readers of this blog are in the first bucket.

9. Who Should Run It

Run it if: you resented a "commercial use detected" banner, you want remote access with session data never leaving your network, you already run a server, or you are an IT/Support team that wants TeamViewer capability without per-seat billing. Skip it if: you need a zero-config managed SaaS, you must embed remote desktop in a proprietary product (AGPL trap — use Guacamole), or you lack the discipline to keep a relay patched and monitored. Also skip self-hosting the relay if a dead relay would strand you with no other access path — run it on resilient hardware. For this blog's audience — people already self-hosting Immich, Vaultwarden, Home Assistant, and a Docker host — RustDesk is the remote-access layer that completes the "everything I rely on, I own" picture. Your screens, your keys, your files: on your relay, encrypted end to end, no vendor in the middle.

10. Hardening Your Self-Hosted Relay

Self-hosting the relay means you own its security. The basics that matter:

• Firewall the ports. Open only 21115–21119 to the addresses that need them; don't expose the relay to the whole internet if you can restrict by source.
• Protect the key. The relay key proves a client belongs to your server. Leaking it lets strangers register against your relay. Store it like a password; rotate if exposed.
• Patch relentlessly. Relay CVEs have shipped in point releases. Subscribe to releases and update hbbs/hbbr promptly — an unpatched relay is the weak link in an otherwise E2E-encrypted chain.
• Back up the database + key. If the rendezvous DB is lost, clients must re-register. Keep the key and DB in your normal backup routine.
• Run relay on resilient hardware. Since the relay is now your access path, put it somewhere with uptime — and monitor it (see the Uptime Kuma piece) from a different host.
• Consider Pro for 2FA/SSO. If multiple technicians share access, the client-only password model gets fragile; centralized 2FA and LDAP (Pro) are the enterprise-grade answer.

11. Troubleshooting Connections

The failures that actually happen, and the fix:

• "Connecting" forever, then fails. Classic NAT-traversal miss with no relay fallback configured — or the relay ports are blocked. Verify 21117/21119 are open and the client has your relay key.
• Direct connect works at home, fails on cellular. Carrier-grade NAT on mobile blocks UDP hole-punching; traffic should fall back to hbbr. If it doesn't, the relay isn't reachable from outside — check the firewall.
• Black screen, no control. Usually a permission or a display-server issue on the controlled Linux box (Wayland vs X11). Use the X11 session or the proper service config.
• Laggy via relay. Expected if P2P failed and you are crossing continents through one small VPS. Co-locate the relay nearer the clients, or fix the P2P path.
• "Relay not secure" warning. The relay is serving without TLS termination in front; put Nginx/Caddy with a cert in front of hbbr for production.

The throughline: most RustDesk pain is network plumbing, not the app. Get the relay reachable and the key right, and the experience is genuinely TeamViewer-class — without the banner, the bill, or the vendor in the middle.

12. A Minimal Hardened Relay: Compose + Reverse Proxy

For production, don't expose hbbr bare. Here is a realistic shape: the two RustDesk binaries on an internal Docker network, fronted by Caddy terminating TLS, with the key injected as a secret. `yaml services: hbbs: image: rustdesk/rustdesk-server:latest command: hbbs volumes: - ./data:/root networks: [rd] restart: always hbbr: image: rustdesk/rustdesk-server:latest command: hbbr volumes: - ./data:/root networks: [rd] restart: always caddy: image: caddy:latest ports: ["21115-21119:21115-21119"] volumes: - ./Caddyfile:/etc/caddy/Caddyfile - ./data:/root networks: [rd] restart: always networks: rd: ` The Caddyfile fronts hbbr with a Let's Encrypt cert so the relay shows "secure" and the session is TLS-wrapped in addition to E2E encryption. Clients are configured with your relay key (from ./data) so only your instances accept them. This is the "done properly" version of the three-line quick start — same free software, real hardening.

13. Reading the Connection When P2P Fails

When a session won't connect directly, the client log tells you which path it took. "Direct" means UDP hole-punch succeeded and pixels flow peer-to-peer. "Relay" means P2P failed and hbbr is carrying it — expected across strict mobile carriers, fixable by confirming 21117/21119 reachability. "Failed" with no relay attempt means the client lacks your relay key or can't reach hbbs at all. Learning to read that one word — direct vs relay vs failed — turns most support calls from guessing into a five-second diagnosis. It is the difference between RustDesk feeling flaky and feeling like infrastructure you understand.

14. The Family Tech-Support Use Case (Why Most People Start Here)

Strip away the enterprise framing and the most common RustDesk story is humble: someone sets it up to support a parent's computer from another city. The commercial tools make this miserable — surprise banners, session limits, a bill. Self-hosted RustDesk makes it a non-event. The setup that works: install the client on the family machine, enable unattended access with a strong permanent password (Settings → Security), point it at your self-hosted relay, and save the ID in your password manager. Next time the printer "won't connect," you type the ID, connect directly (or via your relay), and drive their desktop as if you were there — no phone call walking them through a menu, no data passing through a vendor. The screen, the keystrokes, the files you might copy off to diagnose: all on your encrypted relay, end to end. For a privacy-conscious person this is the killer feature precisely because it is ordinary. You are not running a compliance program; you are helping your mom, without shipping her desktop session to a SaaS you don't control. It is the "own it, don't rent it" principle at the scale of a family, and it is the reason RustDesk's star count keeps climbing past 113,000 — millions of these quiet, local, free support sessions, none of them billing anyone.

15. Why It Feels Fast: Rust and the Codec

The "feels like TeamViewer" claim isn't marketing — it is two engineering choices. First, the core is written in Rust, so the client and relay are small, fast, and memory-safe, with none of the Electron bloat that makes some remote tools sluggish on modest hardware. Second, RustDesk uses hardware-accelerated video codecs (H.264, H.265, VP8, VP9) and lets you pick the one your client and controlled machine both accelerate. On a modern GPU, that means sub-100ms-per-frame perceived latency on a LAN; over a relay, it is bounded mainly by bandwidth, not by the app. The practical tuning: on a controlled machine with Intel/AMD/NVIDIA graphics, enable hardware encoding and choose H.265 for quality-per-bitrate or H.264 for maximum compatibility. Over a constrained link, drop the resolution and frame rate in the client — RustDesk exposes both — rather than fighting a codec that the network can't feed. The takeaway for a self-hoster is that performance is mostly a settings exercise, not a limitation of the open code. When P2P connects, you are essentially streaming peer-to-peer video with E2E encryption; when it relays, you are streaming through your own hbbr instead of a vendor's crowded server. Either way, the speed is yours to tune, on hardware you own.

Related

• Home Assistant: The Open-Source Smart-Home Hub That Keeps Your Data on Your Own Hardware — same ownership thesis, for your home; RustDesk is how you reach it when you're away.
• Uptime Kuma: The Self-Hosted Status Page and Monitor That Kills Your SaaS Subscription — point it at your hbbr` relay URL so you know the remote-access layer is up before you need it.
• Immich: The Self-Hosted Google Photos Alternative That Keeps Your Memories on Your Own Disk — another service in the "I own it" stack that RustDesk lets you reach from anywhere, privately.