Self-Host RustDesk 2026: the Sovereign TeamViewer Alternative Done Right

RustDesk fully operated - as a managed service - WZ-IT sets up your own ID and relay server, hardens it, and handles updates and monitoring. Sovereign remote support without cloud lock-in, on your infrastructure in the EU. Book a free initial consultation · More on RustDesk · Remote management platforms

RustDesk has made unflattering headlines repeatedly in the first half of 2026: a botnet abusing the public server, a forced login on the demo server, a Malwarebytes report on fake installers, and the continued absence from Google Play. At first glance that reads like an argument against RustDesk. On closer inspection it is the opposite: almost every one of these incidents targets the public RustDesk server and foreign download sources - not the software itself. And that is exactly where the right conclusion starts: self-host RustDesk before you trust it.

This article puts the incidents into perspective, factually and dated, explains the architecture of ID server (hbbs) and relay server (hbbr), and shows why your own RustDesk server is the sovereign, GDPR-compliant alternative to TeamViewer and AnyDesk - when operated correctly.

Table of contents

• What happened with RustDesk in mid-2026
• The root cause: the public RustDesk server
• Why self-hosting is the right answer
• How a self-hosted RustDesk server works
• RustDesk vs. TeamViewer and AnyDesk
• GDPR and NIS2: what self-hosting means for compliance
• Checklist: self-host RustDesk securely
• How we work at WZ-IT
• Further reading

What happened with RustDesk in mid-2026

Four events belong in the picture together, each placed in context individually:

The "Go Client" botnet surge (late January 2026). Security researchers reported an automated campaign in which a botnet systematically flooded the public RustDesk rendezvous server with connection requests. Affected users saw incoming requests from a client labelled "Go Client" that probed random RustDesk IDs. This is abuse of the public brokering infrastructure, not a vulnerability in the RustDesk client.

The Malwarebytes report (14 January 2026). Malwarebytes documented a campaign using the fake domain rustdesk[.]work (not the official rustdesk.com). The installer offered there did install a working RustDesk - while quietly deploying the Winos4.0 backdoor framework in the background. The trick: working software removes the most obvious red flag, namely broken functionality. This too is not a RustDesk bug but a supply-chain and trust attack via a tampered download source.

The forced login on the public server. Per the RustDesk wiki (as of April 2026), controllers must now log in to the public server for free with a Google or GitHub account - with the stated reason "due to ongoing scamming and botnet abuse". In the same breath, RustDesk notes that the public server is intended only for demonstration and testing, not for production or sensitive work.

The absence from Google Play. RustDesk was removed from the Google Play Store back in September 2023 after the app was repeatedly abused by fraudsters for support scams. The official Android app has since been distributed via GitHub releases (APK) and F-Droid. That is a distribution and reputation issue, not a code problem.

The latest stable release, RustDesk 1.4.8, shipped on 21 June 2026 and continues the regular release cadence (including Windows ARM64 support and multi-monitor improvements). This article is general information and not legal advice.

The root cause: the public RustDesk server

All four incidents share one common denominator: the shared, public RustDesk server. Install RustDesk with default settings and your device registers on the demo infrastructure operated by RustDesk. With that you inherit three problems that have nothing to do with the quality of the software:

• Your device ID sits in a shared pool with millions of other IDs - which is precisely what makes a botnet's probing possible in the first place.
• You depend on the availability, policies and now the forced login of a third-party server.
• Brokering traffic runs over infrastructure whose location and operator you do not control - a problem for GDPR and for any supply-chain assessment under NIS2.

Session content is end-to-end encrypted in every case; the relay sees no plaintext. But metadata, reachability and the chain of trust hang on the public server. That is fine for a demo setup and the wrong foundation for production remote support.

Why self-hosting is the right answer

The decisive switch is remarkably simple: you run your own ID and relay server and enter its address plus public key into the client configuration. From that moment on,

• your devices register exclusively on your server, not in the public pool - the "Go Client" surge and the forced login become irrelevant;
• device IDs, connection times and logs stay in-house, on infrastructure in the EU;
• you pin the server via its stored public key, so no foreign broker can insert itself;
• binary provenance is in your hands: clients and server come from the official GitHub releases, not from rustdesk[.]work.

Self-hosting therefore solves exactly the three structural problems of the public server - shared pool, external control and data sovereignty - and turns RustDesk into a genuine, vendor-independent self-hosted TeamViewer alternative.

How a self-hosted RustDesk server works

RustDesk is open source, with a core in Rust and a UI in Flutter, and sessions are end-to-end encrypted via NaCl/libsodium. The server consists of two small services:

• hbbs (ID/rendezvous server) registers devices, keeps their reachability current and brokers connections. Default ports: TCP 21115, 21116 and 21118 plus UDP 21116 (the API port 21114 only applies to RustDesk Server Pro).
• hbbr (relay server) carries traffic when no direct peer-to-peer connection can be established. Default ports: TCP 21117 and 21119.

Both ship in the open-source rustdesk-server package and run comfortably on a small Linux VM. On first start, hbbs generates a key pair (id_ed25519 / id_ed25519.pub); you enter the public key into the clients so that only your server is accepted. For direct remote access without a separate VPN tunnel, RustDesk is a pragmatic form of remote maintenance without a VPN client - alternatively, the server can be placed behind your own overlay network.

If you need more comfort (web console, address book, LDAP/SSO, two-factor), the paid RustDesk Server Pro edition adds these per device license. For many mid-sized companies the OSS edition plus clean operations is enough.

RustDesk vs. TeamViewer and AnyDesk

The difference is not a feature comparison but a trust model. TeamViewer and AnyDesk take operations off your hands - in return you trust a closed backend and a third-party server. Self-hosted RustDesk keeps control in-house but demands disciplined operations.

GDPR and NIS2: what self-hosting means for compliance

From a data-protection standpoint, moving from the public to your own server is the difference between "a third party brokers our maintenance sessions" and "processing happens entirely with us". Self-hosted on EU infrastructure, the third-country transfer disappears, no external processor is involved in brokering, and logs and access stay with you - documentable for access and erasure obligations.

For entities in scope of NIS2, the supply-chain and access dimension is added: remote-support access is a classic attack path, and Article 21 requires appropriate measures including access control and supply-chain security. A self-hosted, hardened RustDesk server with traceable access logs is far easier to justify here than a foreign demo server. For remote maintenance of machines and plant, as we operate it for example in the ABCO Water Systems project, this traceability is mandatory, not optional. This article is general information and not legal advice.

Checklist: self-host RustDesk securely

A production RustDesk server needs more than a running container:

1. Your own hbbs/hbbr on a dedicated Linux VM in the EU, not the public server.
2. Public-key pinning in all clients, so only your server is accepted.
3. Binaries from official sources only (GitHub releases / rustdesk.com), never from typo domains like rustdesk[.]work - the lesson from the Malwarebytes case.
4. Minimize firewall exposure: open only the necessary ports, keep management access internal or behind an overlay network.
5. Secure unattended access: a strong permanent password, access only for defined devices, no open self-service.
6. Patch promptly - 1.4.8 of 21 June 2026 as the current state, with structured CVE monitoring.
7. Back up the server keys (id_ed25519) and configuration - without the key all clients lose the connection.
8. Retain access logs and prepare them for audits.

How we work at WZ-IT

We operate RustDesk as a fully managed service within our managed open-source portfolio - in three stages.

Stage 1 - build and hardening. Your own hbbs/hbbr on your infrastructure (typically Hetzner Cloud, netcup or your own Proxmox cluster), with public-key pinning, minimal port exposure, firewalling and a secured management path. On request behind your own overlay network so the server is not openly exposed to the internet.

Stage 2 - updates and CVE monitoring. Through our CVE monitoring we track releases of rustdesk/rustdesk and rustdesk/rustdesk-server plus the relevant NVD/CISA feeds and apply updates in an orderly way - documented with the timestamp in the report.

Stage 3 - operations, backup and compliance. Backup of the server keys and configuration, access logs, and on request a security audit of the entire remote-support chain. For regulated environments we deliver the evidence that GDPR and NIS2 demonstrations expect. If you are planning the move away from TeamViewer/AnyDesk, you get an honest migration and operations assessment from us - including whether the OSS or the Pro edition fits.

Further reading

• RustDesk - fully operated on your infrastructure - service overview and scope
• Remote management platforms - the big picture for remote access and support
• Self-hosted TeamViewer alternative - the options compared
• Remote maintenance without a VPN client - when direct access makes sense
• CVE monitoring for self-hosted software - structured response to vulnerabilities
• Security audit - the remote-support chain reviewed
• Case study: ABCO Water Systems - remote maintenance of plant in practice

Still using RustDesk via the public server - or considering the switch from TeamViewer/AnyDesk? We assess your current remote support for free: server setup, hardening, binary provenance, backup and audit-readiness. Output: a concrete, prioritized recommendation or direct takeover as a managed service.

Book a free initial consultation · More on RustDesk · Remote management platforms

Sources

• Malwarebytes: How real software downloads can hide remote backdoors (14 Jan 2026)
• RustDesk Security Alert: "Go Client" botnet attack (GitHub Discussion #14167)
• Daily CyberSecurity: The "Go Client" Trap - RustDesk under automated botnet siege
• RustDesk Wiki: Login required for public server
• RustDesk 1.4.8 Release (GitHub, 21 Jun 2026)
• RustDesk Discussion: Availability in Google Play (#5660)
• RustDesk Docs: Self-host (hbbs / hbbr)
• RustDesk Docs: RustDesk Server OSS