Self-Hosted Remote Desktop: Why, How, and What Breaks

"Self-hosted remote desktop" usually means one of two things: hosting your own relay/rendezvous infrastructure for a tool like RustDesk, or hosting an entire web-based remote-access platform like Apache Guacamole or MeshCentral. Both are legitimate approaches; they have different tradeoffs. This article walks through why you might self-host, the three serious tools in this space, what the operational overhead actually looks like, and when self-hosting is genuinely better than using a managed service.

TL;DR: Self-host if you have hard data-sovereignty requirements (GDPR, regulated industries, internal-only deployments), if you want zero ongoing licensing cost at scale, or if you genuinely prefer running your own infrastructure. Skip self-hosting if you are a small team without dedicated DevOps, if you need procurement-ready certifications, or if you would rather pay $7.99/mo to make the problem go away.

Why self-host?

Data sovereignty

The number-one reason organizations self-host. If you are subject to GDPR, HIPAA, or sector-specific regulations (German banking, French government, defense contractors), routing remote desktop sessions through a third-party SaaS, even one with strong encryption, may not satisfy your auditors. Self-hosting on infrastructure you own (or rent in a region you control) removes the third-party dependency entirely. Even though our managed relay only sees ciphertext, "the relay sees nothing because we run the relay" is a stronger compliance position.

Internal-only deployments

If your remote desktop traffic should never leave your network, say, an industrial control system air-gapped from the internet, or a hospital LAN with strict egress filtering, a managed cloud service is structurally the wrong shape. You want a relay that lives on your LAN, accessible only to your authorized devices.

Cost at scale

For very large deployments (1000+ endpoints), per-seat managed pricing adds up. A self-hosted relay running on a $40/month VPS can serve thousands of simultaneous sessions if your bandwidth allows. The break-even versus managed pricing depends on the tool, but at MSP and enterprise scale, self-hosting wins on raw cost.

Customization and control

Self-hosting lets you modify the source (under the AGPL-3.0 obligations), customize branding without paying for the white-label tier, and tune relay behavior to your specific network topology.

The tradeoffs you accept

Self-hosting is not free. The bill comes in DevOps overhead, not in dollars per month. Concretely:

• Server provisioning and maintenance: You need a Linux server with a public IP (for relay reachability), monitoring, log rotation, OS patching, and probably backup infrastructure. Plan on 2-4 hours/month of upkeep at steady state, more during incidents.
• NAT and firewall configuration: The relay needs to be reachable from the internet on specific ports (21115-21119 for RustDesk's default config). If you are running on a NATed network, you need port forwarding from your edge to the relay host.
• Certificate management: If you want TLS on the management interface (you should), you need Let's Encrypt certbot or similar. Renewals every 60-90 days, automated via cron.
• Capacity planning: A single relay can handle a lot of traffic, but at some point you need a second, then load balancing. You are now an infrastructure team.
• No vendor support: When something breaks at 2 AM, there is no support line. You debug it yourself or wait for the community to wake up.

The three serious tools

RustDesk (and forks like GoDesk)

The architecturally simplest of the three. Two binaries: hbbs (rendezvous server, ~30 MB RAM) and hbbr (relay, ~50 MB RAM). Both are static Rust binaries with no external dependencies. Setup is roughly:

# On a Linux VPS with a public IP
wget https://github.com/rustdesk/rustdesk-server/releases/latest/download/rustdesk-server-linux-amd64.zip
unzip rustdesk-server-linux-amd64.zip

# Start hbbs (rendezvous) and hbbr (relay) as services
sudo ./hbbs -r your.public.ip
sudo ./hbbr

# Open ports 21115/tcp, 21116/tcp+udp, 21117/tcp, 21118/tcp, 21119/tcp
sudo ufw allow 21115:21119/tcp
sudo ufw allow 21116/udp

# Point clients at your server: in client settings,
# ID Server = your.public.ip, Relay Server = your.public.ip,
# Public Key = (printed by hbbs on first start, or check id_ed25519.pub)

Resource footprint is tiny, a $5/month DigitalOcean droplet handles dozens of simultaneous sessions. The official RustDesk Pro server (paid) adds a web admin console, audit logs, LDAP/OIDC, and broker-style features for larger deployments.

Apache Guacamole

Different architecture: Guacamole is a clientless HTML5 web application. Users connect via a browser; Guacamole's backend (guacd) translates RDP, VNC, and SSH into HTML5 canvas/WebSocket streams. There is no native client to install on the user side, which is genuinely useful for support workflows where you cannot install software on the controlling machine.

Operational complexity is higher than RustDesk: Guacamole runs as Java + Tomcat with a database (MySQL or Postgres) for user/connection management, plus the guacd daemon. The Docker Compose setup smooths this over considerably, but you are running 3-4 containers instead of 2 binaries.

Guacamole is the right pick if you specifically want browser-based access without client software. It is the wrong pick if you want a tool that handles NAT traversal between two endpoints out of the box, Guacamole assumes you can already reach the target machine via RDP/VNC/SSH from the Guacamole server.

MeshCentral

MeshCentral is a Node.js-based remote management platform from Ylian Saint-Hilaire (formerly at Intel). It supports remote desktop, file transfer, terminal, web console, and a fleet management UI. Architecturally it is a single Node app + database (NeDB by default, Postgres optional), reachable on HTTPS.

MeshCentral is more of a fleet-management tool than a pure remote desktop relay, think of it as RustDesk + a device inventory + a web admin UI. Setup is straightforward (a single npm install + config file), and it has been deployed in production by some sizeable organizations including Intel.

Where MeshCentral falls short: the UI is dense and not particularly polished, mobile clients are weaker than RustDesk's, and the codec/performance for desktop streaming is not as optimized as either RustDesk or AnyDesk. It is best when you want a unified web admin console for a fleet, less ideal as a single-purpose remote desktop tool.

What a self-hosted RustDesk relay actually looks like

Step-by-step on a Hetzner CX11 ($4/month) Ubuntu 24.04 VPS:

1. Provision the VPS with a public IPv4. Set a strong root password and enable SSH key auth.
2. Open the firewall:

   sudo ufw allow OpenSSH
   sudo ufw allow 21115:21119/tcp
   sudo ufw allow 21116/udp
   sudo ufw enable

3. Install the RustDesk server binaries from the GitHub releases page. Place them under /opt/rustdesk-server/.
4. Create systemd unit files for hbbs and hbbr so they restart on reboot. The RustDesk wiki has reference units; we maintain a known-good copy at our help center.
5. Get the public key printed by hbbs on first boot. Distribute it to your clients along with the server hostname.
6. Configure clients: in GoDesk client settings, set ID Server, Relay Server, and Public Key. The client now uses your relay instead of ours.
7. Optional: TLS termination via Caddy if you want to serve a web admin console (RustDesk Pro) on 443 with auto-renewing Let's Encrypt certificates.

Total time on a fresh VPS: about 30 minutes the first time, 10 minutes if you have done it before. Ongoing maintenance: apt update && apt upgrade weekly, watch the relay logs, restart if memory leaks (rare). For Linux deployment specifics see our Linux platform page.

GoDesk's position on self-hosting

We let you self-host the relay even on the paid tiers, if you want to. The Pro tier client is configured to talk to our managed relay by default, but you can flip it to your own relay in the settings any time. There is no "enterprise on-prem add-on" gate. This is intentional: the AGPL-3.0 license gives you the right to self-host, and we want to keep that real.

Most users do not bother. Our managed relay just works, has global PoPs, and is included in the base subscription. If your data-sovereignty story requires "no third-party relay anywhere in the path", self-host. Otherwise, save the DevOps time and use the managed relay, that is what the subscription buys you. For the full security architecture that runs underneath either deployment, see our security page.

When self-hosting is the wrong call

• You are a small team without DevOps capacity. The maintenance overhead is real. If you do not have someone whose job description includes "patches Linux servers", self-hosting is a recurring tax.
• You need vendor-paper procurement. Auditors asking for SOC 2 reports will not accept "we run our own server" as an answer. Managed services with formal certifications are easier here.
• You only have 5-20 endpoints. The break-even on self-hosting versus a $7.99/mo managed plan is hundreds of dollars/year of saved DevOps time. At 20 endpoints, managed is unambiguously cheaper.
• You are doing this for the cost savings on a single seat. A $5/mo VPS plus 2 hours/month of admin time at any reasonable hourly rate already costs more than a single seat of managed.

Conclusion

Self-hosted remote desktop is a real option, and for some organizations it is the right one. RustDesk (and forks like GoDesk) is the easiest serious self-host story; Guacamole is the right pick for browser-based access; MeshCentral is the fleet-management generalist. The tradeoff is always DevOps time versus dollars. If you have data-sovereignty requirements, self-host. If you have $7.99/month and would rather build product than ops, use the managed relay. See pricing or download GoDesk and try the managed flow first, you can always migrate to self-hosted later by changing one config line.

FAQ

Can I self-host the relay and still use GoDesk's client UI / accounts?
Yes. Point the client at your relay in settings. Account features that depend on the GoDesk control plane (billing, team management) still work; only the session traffic moves to your relay.

What hardware do I need for a self-hosted RustDesk relay?
A small VPS: 1 vCPU, 1 GB RAM, 1 TB/month bandwidth handles dozens of simultaneous sessions. Hetzner CX11, DigitalOcean basic, or AWS t4g.nano all work. Bandwidth is usually the constraint at scale, not CPU.

Does self-hosted RustDesk support 2FA / SSO?
The free open-source server (hbbs/hbbr) does not. The RustDesk Pro server (paid, separate license) adds web console, OIDC, and audit logs. GoDesk's Pro tier on managed includes 2FA out of the box.

Can I host the relay on AWS Lightsail / Cloudflare / etc.?
Any provider with a public IPv4 and the ability to open custom UDP/TCP ports works. Cloudflare's standard proxy terminates TCP at port 443 only; you would need Cloudflare Spectrum (paid) or a dedicated TCP listener for the RustDesk ports.

How does self-hosting interact with GDPR?
If your relay is in the EU and your data never leaves it, GDPR cross-border transfer rules do not apply. This is the single biggest reason EU public-sector and healthcare deployments choose self-hosting.