Home / Servers / RUSTDESK VPS

Run your own RustDesk server

hbbs and hbbr on a VPS that never asked for a name, an email or a document. Your device IDs, your relay, your key.

Deploy a RustDesk server from $9.99 / month / 2 vCPU and 4 GB is plenty

Why put the rendezvous server on a no-KYC VPS

Self-hosting moves the device list off someone else's infrastructure. That only helps if the box underneath is not tied to you.

Two small daemons, one machine01

hbbs registers IDs and brokers the introduction, hbbr carries the session when hole punching fails. Same image, cheapest plan.

Your own ID namespace02

Devices register with your server, not the public one, so the record of which machines exist and which called which stays with you.

Key pinning by default03

Clients need the server public key for an encrypted connection. Wrong key, no session. The key lives in your data folder.

Signup asks for nothing04

A 32-character credential is the whole account. No email, no phone, no name, no KYC, and no JavaScript needed.

Pay without a paper trail05

Bitcoin, Monero, Litecoin, Ethereum, BNB, Tron, USDT and USDC settle on Servury's own nodes, no gateway. Cards, or cash by mail.

8 locations to choose from06

New York City, Montreal, London, Paris, Frankfurt, Amsterdam, Singapore and Hong Kong, stock permitting.

Quick start: hbbs and hbbr on Debian 13

Server release 1.1.16, published 2026-07-20. Deploy a 4 GB plan, SSH in as root, paste. 
# 1. Docker, installed the way the RustDesk docs install it
apt update && apt install -y wget ufw
bash <(wget -qO- https://get.docker.com)

# 2. Firewall. 21115-21117/tcp plus 21116/udp is the working minimum.
#    21118 and 21119 are the websocket ports for the browser client and stay
#    shut here: reachable directly, they let anyone forge the X-Real-IP and
#    X-Forwarded-For headers the daemons trust. Open them only behind a
#    reverse proxy that sets those headers itself.
ufw allow 22/tcp
ufw allow 21115:21117/tcp
ufw allow 21116/udp
ufw --force enable

# 3. Official compose file, with the version and networks keys dropped and the
#    two websocket publishes (21118, 21119) removed. Images, commands, volumes
#    and the remaining port mappings are unchanged.
#    The -r argument is the relay address handed to clients, so it must be
#    this server's public hostname or IP, never localhost.
mkdir -p /opt/rustdesk && cd /opt/rustdesk
cat > compose.yml <<'YAML'
services:
  hbbs:
    container_name: hbbs
    image: rustdesk/rustdesk-server:latest
    command: hbbs -r rustdesk.example.com:21117
    ports:
      - 21115:21115
      - 21116:21116
      - 21116:21116/udp
    volumes:
      - ./data:/root
    depends_on:
      - hbbr
    restart: unless-stopped
  hbbr:
    container_name: hbbr
    image: rustdesk/rustdesk-server:latest
    command: hbbr
    ports:
      - 21117:21117
    volumes:
      - ./data:/root
    restart: unless-stopped
YAML

# Replace the placeholder with your own hostname before starting.
sed -i 's/rustdesk.example.com/rustdesk.yourdomain.tld/' compose.yml
docker compose up -d

# 4. The public key every client must pin. Copy the whole line.
cat /opt/rustdesk/data/id_ed25519.pub

# 5. Confirm what actually got bound. Both daemons have come up on
#    IPv6-only sockets on dual-stack hosts before, so look before you
#    tell an IPv4-only client that the server is ready.
ss -lntup | grep -E '2111[5-7]'
docker compose logs --tail 20

Point the clients at it

The same five minutes on Windows, macOS, Linux and Android. Nothing here needs the Pro licence.
01Copy the public key

Take the contents of id_ed25519.pub from the data folder. It is a short base64 string: the connection key, not a licence key.

02Fill in ID Server and Key

In the client: Settings, Network, ID/Relay server. ID Server is the hostname, optionally with :21116. Relay Server can stay empty, since it refers to hbbr on 21117.

03Roll it out without clicking

For fleets the documented path is a config string applied at install, one command per platform, plus --password for unattended access. Exact commands and source below.

04Verify both daemons

A client that has reached the server shows Ready. To prove hbbr too, force a relayed session by appending /r to the remote ID and watch the logs.

05Keep the machine paid up

Terms run 7 to 365 days, with auto-renewal from balance or card. Blackbox bills pure pro-rata; the standard line adds a 10% short-term fee under 31 days.

Ports, sizing and how much bandwidth a relay really eats

A self-hosted RustDesk install is two processes. hbbs is the ID and rendezvous server that clients ping to register; hbbr is the relay. RustDesk's FAQ puts the order of events plainly: the server "is primarily used to help your RustDesk clients to find each other ... If this fails ... the relay part of side the server will be used" (rustdesk wiki FAQ). Relay is the fallback, not the normal path.

Ports. The self-hosting documentation lists TCP 21114 to 21119 plus UDP 21116, with TCP 21115 to 21117 the minimum for signal, NAT traversal and relay; 21118 and 21119 serve the web client and 21114 the Pro API (self-host docs). The install guide opens the whole range with ufw allow 21114:21119/tcp, but warns that hbbs and hbbr trust the X-Real-IP and X-Forwarded-For headers on the websocket ports, that those headers "are not validated", and that without the web client you should "keep ports 21118 and 21119 closed" (install guide). Hence the script above stops at 21117 and drops those two publishes from the project compose file (docker-compose.yml).

Sizing. RustDesk's server documentation states that "1 cpu core and 1G ram is enough to support 1000 relay concurrent connections" and that "Each relay connection consumes avg 180kb per second" (server docs). The wiki FAQ puts one relayed session at "30k-3M/s (1920x1080 screen)" in its own units, "around 100K/s" for ordinary office work. CPU is never the limit; bandwidth is, and only for relayed sessions.

So the cheapest plan on the pricing list is the right one: Blackbox Core, 2 vCPU, 4 GB and 50 GB NVMe for $9.99 a month with 10 Gbps unmetered. The current server release is 1.1.16, published 2026-07-20 (releases). It is AGPL-3.0, and the README documents the flags worth knowing: -r for the relay address handed to clients, -b for the bind address (1.1.17 and later), -p for the port, -k for the key (rustdesk-server).

Clients. The key every client pins is the one hbbs makes for itself: it "is usually generated on the first run of hbbs and can be found in the file id_ed25519.pub in your working directory / data folder". The Relay Server field can stay empty because it "refers to hbbr (port 21117)", and the Key you paste "is the public key used for connection encryption, distinct from the license key provided with your Pro version purchase" (client configuration). A client that has reached the server says "Ready" (client docs). Fleets take the same settings as a config string at install: .\rustdesk.exe --config $rustdesk_cfg on Windows, rustdesk --config $rustdesk_cfg on Linux, /Applications/RustDesk.app/Contents/MacOS/RustDesk --config $rustdesk_cfg on macOS, each with a matching --password form (client deployment).

What self-hosting moves, and what it does not

Running your own rendezvous server changes who holds the metadata: which device IDs exist, when they come online and from where, and which ID asked to reach which. Move hbbs to your own machine and that ledger moves with it, but it still exists, and whoever controls the box under hbbs is now the party that matters.

Servury holds little to begin with: no access logs anywhere, no analytics, no third-party scripts, support messages deleted after 72 hours, and a PGP-signed warrant canary.

Be honest about the machine itself. On the standard VPS and VDS line the panel can reset the root password, so treat it as a rented server. Blackbox, in Montreal on hardware Servury owns, is the harder target: no guest agent, so the panel cannot reset anything and losing your key loses the machine; AMD SEV-SNP encrypted memory with debug disabled, so host-side RAM dumps do not work; LUKS2 you unlock over SSH into the initramfs, on firmware you can verify first (measured boot guide). Servury can still power the machine off; it cannot hand over what it does not have.

Two limits up front. There is no DDoS mitigation on any Servury line, and hbbs is a public UDP and TCP listener, so keep the port list tight. IPv6 exists on Blackbox only, as one IPv4 plus a routed /64, while the standard line is IPv4 only. RustDesk issue 554, now closed, reported that "hbbs and hbbr default to listening on IPv6 when both IPv6 and IPv4 are available", leaving IPv4-only clients unable to connect (issue 554). Run ss -lntup after install and believe what it prints.

To take the service off the public internet, put it behind a tunnel and let only your own peers reach 21115 to 21117. A WireGuard server on the same box, or a separate self-hosted VPN, makes RustDesk an internal service, at the cost of every endpoint needing the tunnel. Direct IP access, the LAN mode that skips the server, is not a substitute: "the connection is unecrypted, please do not send us issue about this" (wiki FAQ). Crypto mining is prohibited on Servury: run the relay, not a miner.

Your relay. Your key. Your ID list.

Pick a location, pay with Monero or a card, and have hbbs answering in a few minutes.

Deploy a server

Fair questions

What is the difference between hbbs and hbbr?

hbbs is the ID and rendezvous server: clients register with it and it introduces two peers. hbbr is the relay, used only when those peers cannot reach each other directly. One image, one VPS.

Which ports do I have to open?

TCP 21115, 21116 and 21117 plus UDP 21116 are the working minimum. TCP 21118 and 21119 serve the browser client and TCP 21114 the Pro API. Leave those closed unless you use the web client.

How big does the VPS need to be, and how much bandwidth does the relay use?

Small, and less than you think. RustDesk documents one CPU core and 1 GB of RAM for 1000 concurrent relay connections, and only relayed sessions cost bandwidth at all. Both figures are quoted with their sources below.

Where do I find the key that clients have to enter?

hbbs generates a key pair on first run and writes the public half to id_ed25519.pub in its data folder, ./data/id_ed25519.pub with the official compose file. Paste that string into every client.

Does IPv6 work?

On Blackbox, yes: one IPv4 plus a routed /64 per machine. The standard VPS and VDS line is IPv4 only.

Can Servury see my remote desktop sessions?

On the standard line, treat it as an ordinary VPS: the panel can reset the root password. On Blackbox there is no guest agent, memory is encrypted with AMD SEV-SNP, and you unlock LUKS2 yourself. No access logs either way.

Is a RustDesk server allowed under the acceptable use policy?

Yes, that is ordinary self-hosting. Crypto mining is prohibited on Servury, so do not mine on the same box. Abuse reports are read by a person.

Guides on this

How to Set Up a Self-Hosted VPN with WireGuard on a VPS Ten minutes from a fresh Ubuntu server to a WireGuard VPN you control: keys, config, forwarding, firewall, a phone client by QR code, and the two sett Self-Hosted Apps vs SaaS: Why Running Your Own Nextcloud, Vaultwarden, or Pi-hole Beats Trusting a Third Party What changes when you run your own Nextcloud, Vaultwarden, or Pi-hole instead of trusting a SaaS provider, and how an anonymous VPS closes the last pr Why Developers Are Self-Hosting AI Agents and LLMs Instead of Relying on Cloud AI Platforms Why developers are moving language models and agents onto their own VPS, keeping prompts, documents, and agent memory private instead of sending them VPS vs VPN: Why a VPN Alone Isn't Enough for Real Privacy & Opsec A VPN doesn't give you privacy. It just moves your trust from your ISP to one company that sees everything and whose no-logs promise you can't verify.

Related use cases

Headscale VPS Pi-hole VPS SearXNG VPS Plausible Analytics VPS Nextcloud VPS n8n VPS Coolify VPS Gitea / Forgejo VPS