How to Self-Host RustDesk with Docker

In this tutorial, we’ll walk through deploying your own RustDesk server using Docker, providing a self-hosted alternative to remote support tools like Bomgar or TeamViewer—but with full control over your data and infrastructure. When set up correctly, self-hosting RustDesk is highly secure, as it establishes end-to-end encrypted connections between clients, ensuring your remote sessions remain private. You’ll need a Debian or Ubuntu server with Docker installed, access to manage firewall rules, and DNS A records for your domain.

Note: While configuring a firewall using UFW (Uncomplicated Firewall) is strongly recommended to harden your server by restricting access to only the necessary ports, it is considered outside the scope of this tutorial.

🔧 Requirements

• A Docker-compatible VM (e.g., Debian/Ubuntu) for hosting RustDesk
• A Firewall with admin rights
• A domain/subdomain pointing to your firewall (e.g., remote.yourdomain.com)

📦 Step 1: Deploy RustDesk Server via Docker

1. SSH into your Docker host VM.

2. Create a project folder for RustDesk:

   mkdir -p ~/rustdesk && cd ~/rustdesk

3. Create a Docker Compose file:

   nano docker-compose.yml

   Paste the following:

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

4. Start the containers:

   docker compose up -d

🌐 Step 2: Configure Your Domain

Log into your DNS provider and point an A record to your NGINX reverse proxy VM:

remote.yourdomain.com → [Public IP of reverse proxy VM]

🚪 Step 3: Open Firewall Ports

1. This tutorial assumes you know how to handle your own firewall settings. You will have to work with your specific firewall settings outside of the scope of this tutorial. Ports required for RustDesk Server self-hosting depends largely on your environment and what you want to do with RustDesk. The Examples shown throughout the docs will generally have all ports suggested to be opened.

2. Core Ports:
   TCP 21114-21119
   UDP 21116

3. The above 21115-21117 are the minimum required ports for RustDesk to work, these handle the signal and relay ports as well as NAT traversal.

4. TCP ports 21118 and 21119 are the WebSocket ports for the RustDesk Web Client, you need a reverse proxy to make it support HTTPS, please refer this sample Nginx configuration.

5. For Pro users without an SSL Proxy you will need to open TCP port 21114 for the API to work alternatively using an SSL Proxy open TCP port 443.

🔐 Step 4: Secure and Verify Your RustDesk Server

1. After the containers start, get your RustDesk public key (used for secure connections):

   cat ~/rustdesk/data/id_ed25519.pub

2. Visit https://remote.yourdomain.com — you should see a 404 or blank response (this is expected — the API is not for browsers).

💻 Step 5: Connect with RustDesk Client

1. Download the RustDesk client from rustdesk.com.
2. Open the client and go to Settings > Network > ID/Relay Server.
3. Enter:
   • ID Server: remote.yourdomain.com
   • Key (from Step 4): 2dfadgaw1dfasfaegafageafdsahfahefwegha;ohgueaygageawga!5
4. On another machine, enter the 9-digit code and connect.

🔐 Extra: Additional Security

Using UFW (Uncomplicated Firewall) on a Debian server hosting RustDesk is a smart and effective way to enhance security. While RustDesk itself provides encryption and access control features, UFW adds an essential layer of protection by restricting which ports and IP addresses can communicate with your server. This minimizes exposure to unauthorized access, reduces the attack surface, and helps prevent automated scans or intrusion attempts. By allowing only the specific ports needed for RustDesk and blocking everything else, UFW acts as a safeguard, ensuring that your server remains as secure and hardened as possible without adding significant complexity. Although setting up UFW is highly recommended, it is considered outside the scope of this tutorial.

🎯 Summary

With this setup, you're no longer dependent on 3rd-party cloud relays. You're in full control of your remote support infrastructure, ready to serve clients securely and reliably.