Self-Hosted Remote Access: RustDesk Server, MeshCentral, Guacamole and VPN Options

This page is for sysadmins, MSP technicians and home-lab owners who want remote access without routing every session through a vendor’s cloud. Self-hosting means you own the broker, gateway or VPN, the keys and the logs. It also means you own the patching, backups and uptime.

The short answer: run RustDesk Server if your technicians like an AnyDesk-style client, MeshCentral if you want a browser console with agents for a whole fleet, and Apache Guacamole if your targets already speak RDP, VNC or SSH. Put a VPN such as WireGuard in front of anything that does not need to face the internet.

The short list

Pick the right kind of self-hosted access

“Self-hosted remote access” covers four different designs:

• Broker and relay. Your server introduces two clients and relays traffic when they cannot connect directly. RustDesk Server works this way. Good for supporting PCs.
• Agent plus web console. Every managed machine runs an agent that dials home to your server. MeshCentral is the free reference here. Good for unattended fleets.
• Protocol gateway. A server inside your network turns existing RDP, VNC or SSH into a browser session. Guacamole, Thinfinity and Teleport fit here. Good for servers and contractors.
• Network access. A VPN or mesh puts the user on the network; they then use whatever client they like. WireGuard, OpenVPN, Headscale and NetBird fit here.

Most setups combine a VPN for admins with a gateway or broker for help-desk work.

Run your own RustDesk ID and relay server

RustDesk Server is two daemons: hbbs handles IDs and hole punching, hbbr relays traffic when a direct connection fails. A small VM is enough; relayed sessions cost bandwidth, not CPU. The documented route is Docker with host networking, so hbbs sees real client IPs:

services:
  hbbs:
    image: rustdesk/rustdesk-server:latest
    command: hbbs
    volumes: ["./data:/root"]
    network_mode: host
    restart: unless-stopped
  hbbr:
    image: rustdesk/rustdesk-server:latest
    command: hbbr
    volumes: ["./data:/root"]
    network_mode: host
    restart: unless-stopped

Open TCP 21115–21117 and UDP 21116; add TCP 21118–21119 only for the web client. On first start the server creates an Ed25519 key pair in ./data. Give each RustDesk client your DNS name as ID Server plus the public key from id_ed25519.pub, then export that configuration string and push it with rustdesk.exe --config <string> during deployment.

That key is what makes the setup an encrypted remote control setup rather than just a private relay: clients that know it get encrypted connections to your server. Back up both key files; lose them and every client needs reconfiguring. If policy says all traffic must cross your infrastructure, set ALWAYS_USE_RELAY=Y and size your bandwidth for it.

The OSS server has no web console, accounts or audit trail; the commercial Server Pro adds them, plus LDAP/OIDC sign-in.

Manage a fleet from the browser with MeshCentral

MeshCentral gives you remote desktop, terminal, file manager and power control from a web page, with agents on Windows, Linux, macOS and FreeBSD. It needs Node.js 20 or newer:

mkdir -p /opt/meshcentral && cd /opt/meshcentral
npm install meshcentral
node node_modules/meshcentral          # first run, create the admin account now
node node_modules/meshcentral --install   # then register it as a service

There is no default login: the first account created becomes the administrator, so create it before the server is reachable from outside. For internet use, set "cert" to the server’s DNS name, enable the letsencrypt block in meshcentral-data/config.json, and set "newAccounts": false so strangers cannot register. Then rebuild agent installers, which carry the server address. Ports: 443 for UI and agents, 80 for redirects and certificates, 4433 only for Intel AMT CIRA.

The default NeDB database is fine for small installs; MongoDB, PostgreSQL or MySQL/MariaDB suit larger ones and are required if you run under a low-privilege user, as the hardening docs recommend. MeshCentral Router tunnels a port such as 3389 or 22 through the agent, which lets you use a native RDP or SSH client without opening anything at the remote site.

Give browser access to RDP, VNC and SSH hosts

Guacamole is the free choice when the targets already run RDP, VNC or SSH. It has two parts: guacd, which speaks the protocols, and a Java web app that handles logins and streams the display. Run both as the official guacamole/guacd and guacamole/guacamole images with PostgreSQL or MySQL; generate the schema with initdb.sh from the image, because tables are not created automatically.

Four things to do before the login page faces the internet:

1. Change or remove the guacadmin / guacadmin account the schema creates.
2. Keep guacd (TCP 4822) and the app (8080) on localhost; publish only HTTPS through a reverse proxy.
3. Enable the TOTP or Duo extension, or sign in through SAML or OpenID Connect.
4. Turn on session recording for privileged connections; guacenc converts recordings to video.

Behind Nginx, Guacamole needs proxy_buffering off, proxy_http_version 1.1 and the WebSocket Upgrade and Connection headers, or sessions freeze.

If you need vendor support on a Windows server, Thinfinity Workspace (the successor to ThinRDP) does the same job commercially, with outbound-only reverse connections so internal hosts need no inbound ports. Retire any old ThinRDP install still facing the internet. Teleport offers certificate-based, identity-aware access to SSH, Kubernetes, databases and Windows hosts over RDP, with audit built in. Its Community Edition limits passwordless access to local (non-Active Directory) Windows users to five desktops.

Put a VPN in front instead of opening ports

A VPN does not replace remote desktop software; it decides who can reach it, so 3389, 22 and 5900 stay closed at the edge.

WireGuard is the quickest to stand up: one short config per peer, UDP only, no user database. Add and revoke peers live:

wg set wg0 peer <public key> allowed-ips 10.20.0.3/32
wg-quick save wg0
wg set wg0 peer <public key> remove
wg show    # check "latest handshake" per peer

Use split tunnelling (AllowedIPs limited to your internal ranges) for support staff, and PersistentKeepalive = 25 for peers behind NAT.

OpenVPN takes longer to set up but runs over TCP 443 where guest networks block UDP, supports certificate revocation (./easyrsa revoke alice, ./easyrsa gen-crl, then crl-verify in the server config) and can check passwords against LDAP or RADIUS. Protect the control channel with tls-crypt. Old configs using static keys or comp-lzo need rework on 2.7.

Mesh options. Tailscale wraps WireGuard with identity sign-in and NAT traversal, but the coordination service is theirs; its free Personal plan covers up to six users. Headscale is an open-source, self-hosted implementation of that control server, built for a single tailnet, which makes it a good fit for a home lab or small team using the Tailscale clients. NetBird is a WireGuard-based mesh with its own management, signal and relay servers; the self-hosted quickstart wants a Linux VM with a public domain, TCP 80 and 443, and UDP 3478.

Host Linux and Windows desktops for many users

• X2Go needs only SSH (port 22), compresses X11 well on slow links and keeps sessions running after disconnect. Use Xfce or MATE, not modern GNOME or Wayland. No release since 2023.
• ThinLinc adds clustering, load balancing and an HTML5 client on TCP 300. It allows 3 concurrent users out of the box and 10 with the free community licence file in /opt/thinlinc/etc/licenses/. Keep the admin interface on port 1010 internal.
• xrdp lets standard RDP clients, including Windows Remote Desktop and Remmina, log in to Linux on 3389/tcp, with TLS by default. Do not publish it directly; put it behind a VPN or Guacamole.
• TSplus Remote Access turns one Windows machine into a multi-user application server with a web portal and RemoteApp clients. Forward only 443, keep 3389 closed, enable two-factor authentication, and remember that Microsoft licensing remains your job.

Know when not to self-host

If nobody will patch the server, a self-hosted gateway becomes a liability. DWService is the honest alternative: the open-source agent connects outbound to the vendor’s relays, so you open no ports and run no server, and every feature is free with a 6 Mbps cap per session. The trade-off is that all sessions cross DWService infrastructure. Hosted tools are compared in our best free remote desktop software guide.

Troubleshoot and tune a self-hosted setup

Most failures are network problems:

• RustDesk clients stuck on “connecting”. UDP 21116 is closed, or the server sits behind NAT without all ports forwarded. Key mismatch errors mean a client holds the key from a different server.
• Relay saturation. If many sessions fall back to hbbr, your upload bandwidth becomes the bottleneck. Fix NAT and firewalls first so more sessions connect directly.
• WireGuard “active” but no traffic. If “latest handshake” never updates, the key, endpoint or firewall is wrong. Overlapping AllowedIPs between two peers silently steals traffic.
• Guacamole RDP fails. Match the security mode to the target (NLA in most domains) and replace self-signed certificates instead of ticking “ignore”.
• Slow Linux desktops. Pick the right X2Go speed preset, drop compositing desktops, and read /var/log/vsmserver.log or journalctl --user on ThinLinc 4.21.

Your server now holds keys worth stealing. Our remote access security checklist covers hardening, MFA, session recording and a back-up-and-restore routine for RustDesk keys, MeshCentral data and Guacamole databases.

How to choose

1. Write down who connects to what: technicians to PCs, admins to servers, staff to a desktop, contractors to a few hosts. Each points to a different design above.
2. Check what the targets already run. RDP, VNC or SSH everywhere points to Guacamole or a VPN. Mixed laptops with no listening services point to agents: MeshCentral or RustDesk.
3. Decide on client or browser. Browser-only users get Guacamole, MeshCentral, ThinLinc Web Access or a commercial gateway.
4. Count users and support needs. Over 10 concurrent Linux desktop users means a paid ThinLinc licence; a requirement for vendor support rules out most of the free stack.
5. Be honest about operations. If no one owns updates, TLS and backups, choose a hosted tool and keep the VPN for admins only.
6. Pilot with a handful of machines, including a test restore of the server, before rolling out.

FAQ

What is the best self-hosted alternative to TeamViewer or AnyDesk?

RustDesk with your own RustDesk Server is closest in feel: ID-based sessions from a desktop client. MeshCentral is the better fit when you manage a fixed fleet and prefer a browser console.

Can RustDesk be completely self-hosted?

Yes. Point clients at your own hbbs and hbbr with your public key, and set ALWAYS_USE_RELAY=Y if all traffic must pass through your server. User accounts and audit logs need Server Pro.

Do I still need a VPN if I run Guacamole or MeshCentral?

Not strictly: both are built to sit behind HTTPS on 443. A VPN still makes sense for admin consoles and anything that cannot take MFA.

Is MeshCentral or RustDesk Server easier to run?

RustDesk Server: two small daemons and a few ports. MeshCentral does more but brings a Node.js stack and frequent releases.

Headscale or Tailscale: which should I use?

Tailscale runs the coordination service for you. Headscale replaces it with your own server for a single tailnet, which suits home labs and small teams.

Is there a free self-hosted remote desktop for Linux servers?

Yes: X2Go over SSH, xrdp for standard RDP clients, and ThinLinc free for up to 10 concurrent users.

Last updated: 1 October 2026 · CtrlRemote editorial team. Licence, version and platform details are checked against each developer's official documentation.