Self-hosted TeamViewer Alternative: RustDesk Explained

Run remote support on your own terms, without a third-party cloud? WZ-IT builds remote-management platforms with self-hosted components such as RustDesk. See our remote-management platforms

RustDesk is an open-source, self-hostable remote support and remote desktop tool, an alternative to TeamViewer and AnyDesk. Instead of running through a vendor cloud, the connection goes through your own ID and relay server (hbbs/hbbr) that you operate yourself. As a result, screen content, keystrokes and metadata never leave your house: the session is end-to-end encrypted, and the entire brokering infrastructure stays under your control. As of mid-2026 the RustDesk client is at version 1.4.8 and RustDesk Server OSS at 1.1.15, both under AGPL-3.0 (github.com/rustdesk/rustdesk).

Table of Contents

• How RustDesk works
• Current version and license
• Setup at a glance: Docker
• Security, GDPR and sovereignty
• RustDesk vs. TeamViewer vs. AnyDesk
• RustDesk Server OSS vs. Server Pro
• Other self-hosted options
• Use cases and how WZ-IT uses RustDesk
• Further guides

---

How RustDesk works

RustDesk has two parts: the client and the self-hosted server. The client runs on Windows, macOS, Linux, Android, iOS and in the web. Each installation gets a unique RustDesk ID; connections are made via this ID, not via IP addresses.

The server splits into two components (rustdesk.com/docs):

• hbbs (ID/rendezvous server): registers clients by their ID and brokers the connection setup. It tries to punch a direct peer-to-peer hole through NAT (hole punching). hbbs listens on TCP 21115 and 21116 and UDP 21116 (plus TCP 21118 for web clients).
• hbbr (relay server): takes over when no direct path can be established and forwards the data stream. hbbr listens on TCP 21117 (plus TCP 21119 for web/WebSocket clients).

Crucially, the session is end-to-end encrypted. RustDesk uses the NaCl crypto library - Curve25519 for key exchange, xSalsa20-Poly1305 for session data and Ed25519 for signatures. The symmetric session key is negotiated directly between the two clients. Even when the stream goes through hbbr, the relay only sees encrypted packets and cannot decrypt them. The server is deliberately kept "dumb": it brokers and forwards, but it never knows the contents.

Current version and license

The RustDesk client is licensed under AGPL-3.0; the current version is 1.4.8 (June 2026), with improvements including Windows ARM64 and multi-monitor handling. The RustDesk Server OSS (rustdesk-server, containing hbbs and hbbr) is also AGPL-3.0 and available in version 1.1.15 (January 2026) (github.com/rustdesk/rustdesk-server). Both are free and fully self-hostable.

There is also RustDesk Server Pro, a commercial extension with central management. The license is tied to the hbbs server and scales with the number of users and devices. The OSS relay (hbbr) stays identical and license-free in both cases.

Setup at a glance: Docker

The simplest path is Docker or Docker Compose. You start two containers - one for hbbs, one for hbbr - from the official rustdesk/rustdesk-server image. On first start, hbbs generates a key pair in the data directory (id_ed25519 and id_ed25519.pub).

The rough sequence:

1. Provision a server: a small VM or root server with a public IP or DNS name, with the ports above opened.
2. Start hbbs and hbbr: via Docker Compose, with a persistent volume for the keys and the ID database.
3. Distribute the public key: clients need the content of id_ed25519.pub to enforce an encrypted connection.
4. Configure clients: in the RustDesk settings, enter the ID server (hbbs address), relay server (optional) and public key - by hand or pre-configured through the client configuration.

For fleets, the client can be rolled out with an embedded server configuration so endpoints point straight at your own server. Resource needs are small; a single small VM is enough for many endpoints.

Security, GDPR and sovereignty

The biggest advantage over the cloud services is data sovereignty. When self-hosted, connection brokering and - where needed - relaying run exclusively through your infrastructure. There is no vendor collecting connection metadata and no external cloud sitting in the path. The server and (with Server Pro) the audit data can be operated specifically in the EU - a solid basis for GDPR-compliant remote maintenance. This is also relevant in the context of requirements such as the NIS2 directive.

A few hardening points: keep the relay host minimal and up to date, enforce the public key to block unencrypted or foreign connections, and protect unattended access with a strong password and - via Server Pro - 2FA. Anyone who needs traceable, role-based access typically combines RustDesk with an overarching access layer. Note: this section is general information, not legal advice.

RustDesk vs. TeamViewer vs. AnyDesk

The core point: TeamViewer and AnyDesk are mature, convenient cloud services - but the brokering always runs through the vendors, and costs scale with users and devices. RustDesk moves exactly that brokering onto your own servers and makes the source code auditable. More on operations and use on our RustDesk expertise page.

RustDesk Server OSS vs. Server Pro

The OSS server is a pure ID and relay service: no central dashboard, no user accounts, no address book sync, no device groups, no audit log. For plain remote support with a manageable number of devices, that is often enough.

Server Pro adds a web console with user management, a synchronised address book, device groups, 2FA, OIDC/SSO integration and an audit log. The license is stored in the hbbs and sized by user/device count. Teams running RustDesk with compliance requirements usually land on Pro - or combine OSS with their own access and audit layer.

Other self-hosted options

RustDesk is not the only sovereign variant. Depending on the use case, other building blocks fit:

• MeshCentral: a web-based, agent-based remote management platform. Strong when, beyond remote control, you also need inventory, power management and unattended fleet management.
• Apache Guacamole: a clientless gateway that delivers RDP, VNC and SSH directly in the browser - with no software on the technician's device. Ideal as an auditable access layer in front of existing systems. Details in What is Apache Guacamole?.

These tools often complement each other: RustDesk for interactive desktop support, a browser gateway like Guacamole for RDP/VNC/SSH access to servers and plants - both without a VPN client on the far side. How that works without a VPN client is shown in Remote maintenance without a VPN client.

Use cases and how WZ-IT uses RustDesk

Typical use cases are support (helping employees or customers at the desktop), admin access (unattended access to servers and workstations) and infrastructure access (maintaining distributed endpoints over your own brokering servers).

At WZ-IT we rely on self-hosted building blocks such as RustDesk when data sovereignty and cost control matter - embedded in a platform with an encrypted network backend and an auditable access layer. The ABCO Water Systems case study shows how we remote-maintain distributed plants in production. On request we handle selection, build and operation end to end as part of our remote-management platforms.

Further guides

• RustDesk expertise - usage and operations
• Remote maintenance without a VPN client
• What is Apache Guacamole? - RDP/VNC/SSH in the browser

Want to set up remote support sovereign and without a third-party cloud? Get to know us or take a look at our remote-management platforms.