RustDesk Server: Self-Host Your Own TeamViewer Alternative on a 1 GB VPS

A RustDesk server is two small programs on a machine you control: hbbs, the ID server that tells RustDesk clients where to find each other, and hbbr, the relay that carries a session when two PCs cannot connect directly. Self-hosted on a VPS, it replaces RustDesk's public servers, so your support sessions are brokered by your own machine and checked against your own key. In our lab, version 1.1.16 from the official Debian packages used about 15 MB of RAM for both programs, and a relayed session pushed 0.3 to 91 KB/s into the server and the same amount back out.

That makes VPS Nano, the smallest of our VPS hosting plans with 1 vCPU and 1 GB of RAM, more than enough. The short version of the setup: open TCP 21115 to 21117 and UDP 21116, give every client the public key, and start hbbr with -k _ so nobody else can borrow your relay.

Key facts, checked on 17 October 2026:

• The current open-source server is rustdesk-server 1.1.16, released on 20 July 2026, with a fix for unauthenticated UDP punch-hole requests that could be abused for reflection attacks (release 1.1.16).
• Server and client are licensed under the AGPL-3.0. The latest client is 1.5.0, released on 30 September 2026 (client 1.5.0).
• The relay hbbr starts with an empty key by default, which switches off its key checks (configuration reference). The flag -k _ turns them on.
• RustDesk puts a relayed 1920x1080 session at 30 KB/s to 3 MB/s, and office work at about 100 KB/s (OSS install docs).
• RustDesk says 1 CPU core and 1 GB of RAM handle 1,000 concurrent relay connections, and its public ID server serves more than 1 million endpoints from 2 CPUs and 4 GB (Server Pro docs).

How does a RustDesk server work?

Every RustDesk client keeps pinging the ID server (hbbs, also called the rendezvous server), so it always knows the client's current address. When a technician types a customer's ID, hbbs introduces the two PCs and asks them to try hole punching: both send packets to each other at the same moment, so each router lets the other side's traffic in. RustDesk's self-host docs say this succeeds in the majority of cases.

When it fails, typically behind a strict company firewall or a carrier-grade NAT (one public address shared by many customers of an internet provider), both PCs connect out to the relay (hbbr). Because both sides connect out, neither PC needs an open port of its own; only the server does. In our lab a direct session put no screen data on the server at all, although our two clients sat on the same virtual network, the easy case, so we could not try hole punching through real home or office routers.

Is a self-hosted RustDesk server secure?

Security rests on a key pair. On first start hbbs creates an Ed25519 key pair: the private id_ed25519 stays on the server, and the public id_ed25519.pub, a 44-character string, goes into every client. When we removed the key from one client, hbbs refused its connection request and logged Authentication failed ... invalid key. Sessions are end-to-end encrypted with NaCl, according to RustDesk's documentation, so the relay forwards data it cannot read.

Two defaults need fixing, and the install steps below fix both:

• The relay ignores the key. hbbr 1.1.16 starts with an empty key, and RustDesk's configuration reference warns that clients without your key can then use the relay, so anyone who learns your IP could spend your bandwidth. The flag -k _ makes hbbr load the same key pair as hbbs.
• The private key is readable by every user. The Debian packages left id_ed25519 at mode 644 and run both services as root, so step 3 tightens the file to mode 600.

RustDesk server ports: four to open, three to keep closed

Port roles are from RustDesk's self-host docs. The firewall example on RustDesk's install page opens 21114 to 21119, but the same page warns that hbbs and hbbr trust client IP headers on 21118 and 21119 without checking them. For the browser client, put those two behind a reverse proxy such as Caddy or Nginx. Otherwise keep them closed.

RustDesk server requirements: what it used in our lab

We ran three Debian 13 containers on our Amsterdam test server, each limited to 1 vCPU and 1 GB of RAM, the size of a VPS Nano: the server, plus two RustDesk 1.5.0 Linux clients on a virtual 1280x800 screen (Xvfb), one sharing and one controlling. Memory below is RSS, the RAM a process really holds, and "whole server" is the used column of free -m.

For relay traffic we read the server's network counters for 60 seconds per scenario while one client controlled the other. Traffic in and traffic out were almost equal, because the relay passes on what it receives, so each row shows one figure that held both ways:

Treat the video row as a floor: the player alone took about 60% of the sharing container's single vCPU, so RustDesk encoded fewer frames than a real 1080p PC would. hbbr also has a small built-in console that takes short text commands, such as u for usage, over a TCP connection made from the server itself to port 21117. For our 346-second session it reported a peak of 4,559 kbit/s, about 570 KB/s, and an average of 416 kbit/s.

So RAM and CPU will not be your limit; bandwidth for relayed sessions is. A 1 Gb/s port carries about 40 sessions at RustDesk's worst case of 3 MB/s (24 Mbit/s each), or over 1,000 at the 100 KB/s office figure. hbbr caps itself too: its log showed defaults of 128 Mbit/s per session and 1,024 Mbit/s in total, the same values as in RustDesk's configuration reference. All RS Computers plans have unmetered traffic, so a busy month of relayed sessions does not become a bill.

Which VPS plan and city for a RustDesk relay

Almost nobody needs the last row. If you do, remember that hbbr's default total of 1,024 Mbit/s would hold it below the 10 Gb/s port. The TOTAL_BANDWIDTH setting in the configuration reference raises that cap.

VPS plans have shared vCPUs, which is fine for a relay that used well under 1% of one vCPU while carrying our sessions, and you can upgrade later from the client area with a short reboot. A Windows desktop for your technicians would be a separate Windows VPS on a Mini or VDS plan, because Nano and Micro are Linux only.

The city matters because a relayed frame travels from customer to relay to technician, so the relay's distance counts twice. On 6 October 2026 a ping.pe probe in Prishtina reached our Amsterdam server in 36.9 ms, so a Kosovo technician helping a Kosovo customer through an Amsterdam relay carries roughly 74 ms of round trip, by our estimate. With the relay in Prishtina both legs stay inside Kosovo, and Skopje is about 3 ms away on our own network.

For Western Europe, the same tests put our Amsterdam server 6.6 ms from Frankfurt and 6.7 ms from London. The full tables are on our VPS Netherlands and VPS Kosovo pages, and availability by city is on the VPS plans page.

How to install a RustDesk server on Debian 13

We tested two of the install routes in RustDesk's docs:

Start from a fresh Debian 13 VPS, ideally hardened as in our guide to securing a Debian 13 VPS. Clients can use the server's IP, but a DNS name such as rd.example.com lets you move servers later by changing one record. Steps 1 to 5 use the .deb packages, and the Docker route follows them.

Step 1: firewall first

ufw is a simple front end for the Linux firewall. Allow SSH before you switch it on so you do not lock yourself out. The --force option skips the yes/no question.

# as root on the VPS
apt update
apt install -y wget ca-certificates ufw
ufw allow 22/tcp
ufw allow 21115:21117/tcp
ufw allow 21116/udp
ufw --force enable
ufw status

What we saw: Status: active and ALLOW lines for 22/tcp, 21115:21117/tcp and 21116/udp, each repeated with (v6). If SSH runs on another port, allow that one instead of 22.

Step 2: install hbbs, hbbr and the check tool

# as root on the VPS
cd /root
wget https://github.com/rustdesk/rustdesk-server/releases/download/1.1.16/rustdesk-server-hbbs_1.1.16_amd64.deb
wget https://github.com/rustdesk/rustdesk-server/releases/download/1.1.16/rustdesk-server-hbbr_1.1.16_amd64.deb
wget https://github.com/rustdesk/rustdesk-server/releases/download/1.1.16/rustdesk-server-utils_1.1.16_amd64.deb
apt install -y ./rustdesk-server-hbbs_1.1.16_amd64.deb ./rustdesk-server-hbbr_1.1.16_amd64.deb ./rustdesk-server-utils_1.1.16_amd64.deb

Near the end you should see Created symlink lines for rustdesk-hbbs.service and rustdesk-hbbr.service: both services are running and start at boot. Data lives in /var/lib/rustdesk-server/, logs in /var/log/rustdesk-server/.

Step 3: read the public key, protect the private one

# as root on the VPS
systemctl is-active rustdesk-hbbs rustdesk-hbbr
cat /var/lib/rustdesk-server/id_ed25519.pub
chmod 600 /var/lib/rustdesk-server/id_ed25519

Expected: active twice, then your public key, 44 characters ending in =; ours was cWnUfsnP3Q79kemkugXNO05uJ9gXv2cGNrLPVpGi+pM=. The chmod makes the private key readable by root only. Keep a copy of both key files off the server: lose them and every client needs a new key.

Step 4: make the relay ask for the key

A systemd override changes the start command without touching the package's file. The empty ExecStart= line clears the original command.

# as root on the VPS
mkdir -p /etc/systemd/system/rustdesk-hbbr.service.d
cat > /etc/systemd/system/rustdesk-hbbr.service.d/override.conf <<'EOF'
[Service]
ExecStart=
ExecStart=/usr/bin/hbbr -k _
EOF
systemctl daemon-reload
systemctl restart rustdesk-hbbr
ps -o cmd= -C hbbr
grep Key /var/log/rustdesk-server/hbbr.log

Expected: /usr/bin/hbbr -k _, then a log line with Key: and the same public key as in step 3. Before the change, hbbr's log had no key line. Relayed sessions between clients that have the key kept working.

Step 5: let the server check itself

# as root on the VPS
rustdesk-utils doctor 127.0.0.1

Expected: OK for 21115 to 21119 and ERROR for 21114, which is normal because 21114 is the Pro API. Locally all five ports answer; the firewall is what hides 21118 and 21119 from the internet.

How to run the RustDesk server with Docker Compose

RustDesk's install guide recommends Docker as the easiest way to reproduce, upgrade and move a server. We used Debian 13's own packages (Docker 26.1.5, Compose 2.26.1) and RustDesk's compose file with two changes: the image is pinned to 1.1.16 instead of latest, and hbbr gets -k _. Do step 1 above first.

# as root on the VPS
apt install -y docker.io docker-compose
mkdir -p /opt/rustdesk/data

If the .deb version ran before, stop it and carry its key over so existing clients keep working:

# as root on the VPS, only if you installed the .deb packages first
systemctl disable --now rustdesk-hbbs rustdesk-hbbr
cp /var/lib/rustdesk-server/id_ed25519 /var/lib/rustdesk-server/id_ed25519.pub /opt/rustdesk/data/

# /opt/rustdesk/compose.yml, written as root
services:
  hbbs:
    container_name: hbbs
    image: rustdesk/rustdesk-server:1.1.16
    command: hbbs
    volumes:
      - ./data:/root
    network_mode: "host"
    depends_on:
      - hbbr
    restart: unless-stopped

  hbbr:
    container_name: hbbr
    image: rustdesk/rustdesk-server:1.1.16
    command: hbbr -k _
    volumes:
      - ./data:/root
    network_mode: "host"
    restart: unless-stopped

# as root, in /opt/rustdesk
docker compose up -d
docker compose ps
docker logs hbbs 2>&1 | grep Key

Both containers should show Up, and the Key: line should match your old key. Both of our clients registered again within four seconds, with no change on their side.

Keep network_mode: "host". Docker's firewall documentation explains that ports published with -p are routed before ufw's rules apply, while host networking adds no such rules. Our Docker on a VPS guide covers the basics.

How to connect RustDesk clients to your own server

Every PC, the technician's and the customer's, needs two values: ID server (your server's IP or DNS name) and Key (the public key from step 3). Leave Relay server empty when hbbr runs next to hbbs. Our clients found the relay with only those two set. API server is for Pro.

A handful of PCs: type it in, or import one line

In RustDesk, open the menu next to your ID, go to Network, unlock the settings with administrator rights and fill in both fields (client configuration docs). Once one PC works, Export Server Config copies one line of text that Import Server Config pastes on the next PC. According to the 1.5.0 source code, that line is just the server settings as JSON, base64-encoded and reversed, with no password in it.

Dozens of PCs: a silent install script

For an RMM tool, Intune or a group policy, RustDesk's deployment scripts install the client silently and then run --get-id, --config and --password. Their config string comes from the Pro web console. With the open-source server, use your exported line or the plain host=...,key=... form, which the client accepts too. A shorter version with the options from RustDesk's MSI page:

# in PowerShell as Administrator on the Windows PC (adapted from RustDesk's docs, not run by us on Windows)
New-Item -ItemType Directory -Force -Path C:\Temp | Out-Null
cd C:\Temp
Invoke-WebRequest https://github.com/rustdesk/rustdesk/releases/download/1.5.0/rustdesk-1.5.0-x86_64.msi -OutFile rustdesk.msi
Start-Process msiexec.exe -Wait -ArgumentList '/i rustdesk.msi /qn CREATEDESKTOPSHORTCUTS="N" /l*v install.log'
cd "$env:ProgramFiles\RustDesk"
.\rustdesk.exe --config "host=rd.example.com,key=YOUR_PUBLIC_KEY"
.\rustdesk.exe --password "a-long-password-for-this-PC-only"
.\rustdesk.exe --get-id | Write-Output

If the RustDesk service is missing after the install, RustDesk's own script runs .\rustdesk.exe --install-service and waits 20 seconds. Give every customer PC its own long password and keep it in your team's password manager, for example a self-hosted Vaultwarden password manager.

We ran the same switches with the 1.5.0 client on Linux, where both the plain form and a line built in the export format worked:

# as root on a Linux PC with the RustDesk 1.5.0 .deb installed
rustdesk --config "host=YOUR_SERVER_IP,key=YOUR_PUBLIC_KEY"
rustdesk --option custom-rendezvous-server
rustdesk --option key

The last two commands print your address and key back. Once the RustDesk service ran, hbbs logged update_pk with the client's ID: the PC had registered.

Common RustDesk server problems and fixes

• "Key mismatch" after rebuilding the server. hbbs creates a new key pair when it finds none, and then turns away every client that still holds the old key. Copy id_ed25519 and id_ed25519.pub to the new server before its first start, as we did when moving to Docker.
• A relay you did not ask for. A session started with --relay is remembered for that peer (force-always-relay = 'Y' in the client's peer file), so later sessions to that PC also went through hbbr. To relay every session on purpose, RustDesk documents ALWAYS_USE_RELAY=Y for hbbs.
• "No --server process found" when setting a password. --password hands the value to the running RustDesk service; once it ran, our client answered Done!.
• An installer name Windows refuses. Older guides rename the installer to rustdesk-host=YOUR_SERVER,key=YOUR_KEY.exe, a method RustDesk's current client configuration page no longer describes. Keys are base64, which includes the slash that Windows forbids in file names, and by our calculation about one key in two contains one. Use --config instead.
• ERROR for port 21114 in rustdesk-utils doctor. That is the Pro API port, which the open-source server never opens.

Self-hosted RustDesk vs TeamViewer and AnyDesk

RustDesk's GitHub page presents the client as a TeamViewer alternative that you host yourself. With your own server you decide where the relay sits, who holds the key and when to update, with no per-technician fee. The cost is work: you patch the server yourself, help comes from the community rather than a support contract, and without Pro there is no web console or shared address book.

To reach customer networks rather than screens, see our Headscale vs NetBird comparison. For your own Windows servers, secure RDP on Windows Server is simpler. SSH on the RustDesk server itself can hide behind a WireGuard VPN server.

RustDesk Server OSS vs Pro: when Pro is worth paying for

Pro is RustDesk's paid edition, still self-hosted. The self-host docs list a web console, API, OIDC and LDAP logins, two-factor authentication, device management, access control and management of several relays. The custom client generator, which builds a branded installer with your server inside, is marked in the client configuration docs as Pro only, on the Basic plan or a custom plan. The licence covers the hbbs machine; hbbr needs none (licence docs). Plans are on RustDesk's pricing page.

A one- or two-person shop does well with the open-source server. Once several technicians share customers, Pro is worth a look. We tested only the open-source edition.

Frequently asked questions

What are the minimum requirements for a RustDesk server?

Very little. In our lab, RustDesk server 1.1.16 from the official .deb packages used about 15 MB of RAM for hbbs and hbbr together, and the relay used well under 1% of one vCPU during a session. RustDesk says 1 CPU core and 1 GB of RAM handle 1,000 concurrent relay connections. Bandwidth for relayed sessions is the real limit, so a 1 vCPU, 1 GB VPS is plenty for a small IT shop.

What ports does a RustDesk server need?

The open-source RustDesk server needs TCP 21115, 21116 and 21117 and UDP 21116 open to the internet. TCP 21118 and 21119 serve only the browser client and should stay closed unless a reverse proxy sits in front. TCP 21114 is used only by RustDesk Server Pro.

Where do I find my RustDesk server key?

The public key is the file id_ed25519.pub in the server's data folder: /var/lib/rustdesk-server/ with the official .deb packages, or the folder mounted as /root with Docker. It is a 44-character string ending in "=", and hbbs prints it in its log on every start after "Key:".

Does every RustDesk session go through my relay server?

No. hbbs first tries to connect the two PCs directly by hole punching, which RustDesk's docs say succeeds in most cases; only when it fails does hbbr relay the session. In our lab a relayed session used 0.3 KB/s on a still screen and about 91 KB/s with full-screen motion, and a direct session sent nothing through the relay.

Is the RustDesk server free for commercial use?

The open-source RustDesk server is free and licensed under the AGPL-3.0, so an IT company can run it unmodified for its customers. If you change its code and let others use your version over a network, the AGPL requires you to offer them the source. RustDesk Server Pro is the paid edition.

Can a self-hosted RustDesk server replace TeamViewer or AnyDesk?

For an IT shop comfortable with a small Linux server, yes. You control the server, the key and the update schedule, and the open-source edition has no per-technician fee. You give up vendor support and, unless you buy RustDesk Server Pro, a shared address book and web console.

Put your relay where your customers are

A RustDesk server needs a public IP, four open ports and a few megabytes of RAM; the rest is bandwidth for sessions that cannot connect directly. RS Computers runs KVM VPS and VDS servers in Prishtina, Amsterdam and Dublin, all with NVMe storage, unmetered traffic and their own IPv4 and IPv6. VPS Nano covers a RustDesk-only server, and Micro leaves room for a VPN and monitoring next to it. Compare sizes and city availability on our VPS hosting plans page, or message us on Telegram if you would like the setup quoted.

← All articles