rustdesk docker: panduan server RustDesk berbasis container

You're trying to self‑host RustDesk without wrestling with manual builds, dependency hell, or brittle VM images. This guide shows how to run a production‑ready RustDesk server stack with Docker and Docker Compose, so you can manage updates, backups and scaling like an ops person — not a hobbyist.

Mengapa menggunakan Docker untuk RustDesk

Container memberikan dua keuntungan langsung untuk stack akses jarak jauh yang di‑self‑host: penyebaran yang dapat direproduksi dan isolasi. Alih‑alih mengompilasi hbbs/hbbr secara lokal atau menjalankan paket spesifik platform, Anda menarik image Docker, mount volume persisten dan menjalankannya. Itu menyederhanakan upgrade, CI/CD dan migrasi host. Jika Anda sudah menjalankan layanan lain dalam container (NGINX, certbot, monitoring), menambahkan RustDesk dengan cara ini menjaga konsistensi stack Anda.

Kapan tidak menggunakan container: jika Anda membutuhkan binary yang dipatch khusus atau integrasi kernel mendalam untuk relay berkinerja sangat tinggi, instalasi native mungkin lebih disukai. Juga, jika Anda memerlukan SLA enterprise resmi dari vendor, periksa apakah vendor tersebut mendukung container.

RustDesk server components — brief overview

RustDesk membagi peran server menjadi setidaknya dua komponen:

• hbbs — the ID/signaling server. It handles registration and rendezvous for clients.
• hbbr — the relay server (if NAT traversal fails). It relays traffic between peers.

Dalam produksi Anda biasanya menjalankan keduanya. Satu host ringan bisa menjalankan kedua layanan; untuk deployment besar pisahkan layanan, tempatkan instance hbbr di belakang load balancer, dan tambahkan autoscaling untuk kapasitas relay.

Quickstart: example Docker Compose deployment

Prerequisites: Ubuntu 22.04 LTS (or any Linux with Docker Engine 20.10+), Docker Compose v2.x, a domain name (example: rustdesk.example.com). Allocate at least 512 MB RAM for a tiny test server; 1 GB+ recommended for a relay that will handle multiple active sessions.

Below is a practical Docker Compose example that runs hbbs and hbbr in separate services, mounts persistent data, and publishes the standard RustDesk ports. Before you run it, check the official rustdesk/rustdesk-server image tags for the latest stable tag and replace rustdesk/rustdesk-server:latest if you want a pinned version.

version: '3.8'

services:
  hbbs:
    image: rustdesk/rustdesk-server:latest
    container_name: rustdesk-hbbs
    command: ["hbbs", "--listen", "0.0.0.0:21115"]
    ports:
      - "21115:21115/tcp"
      - "21115:21115/udp"
    volumes:
      - ./data/hbbs:/data
    restart: unless-stopped

  hbbr:
    image: rustdesk/rustdesk-server:latest
    container_name: rustdesk-hbbr
    command: ["hbbr", "--listen", "0.0.0.0:21116", "--relay", "0.0.0.0:21116"]
    ports:
      - "21116:21116/tcp"
      - "21116:21116/udp"
    volumes:
      - ./data/hbbr:/data
    restart: unless-stopped

networks:
  default:
    external: false

Penjelasan:

• Kami menjalankan hbbs pada TCP/UDP port 21115 dan hbbr pada 21116 — ini adalah default umum untuk build server RustDesk. Konfirmasi pemetaan port untuk image yang Anda gunakan (beberapa build komunitas menggunakan default berbeda).
• Volume persisten ./data/hbbs dan ./data/hbbr menjaga data registrasi dan relay Anda tetap ada setelah restart.
• Gunakan restart: unless-stopped untuk ketahanan dasar; untuk produksi, integrasikan dengan kebijakan restart platform orkestrasi Anda.

Expose securely: TLS, reverse proxy and firewall

Traffic signaling dan relay RustDesk dapat dilindungi dengan TLS dan aturan firewall standar. Ada dua pendekatan umum:

1. Direct TLS with a proxy in front of hbbs (recommended for web-level cert management).
2. Keep hbbr as a raw TCP/UDP relay and secure the host network (use ufw/nftables) while securing hbbs with TLS.

Kebanyakan setup menggunakan NGINX atau Traefik untuk terminasi TLS dan meneruskan lalu lintas ke hbbs. Contoh server block NGINX untuk terminasi TLS pada rustdesk.example.com:

server {
  listen 443 ssl;
  server_name rustdesk.example.com;

  ssl_certificate /etc/letsencrypt/live/rustdesk.example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/rustdesk.example.com/privkey.pem;

  location / {
    proxy_pass http://127.0.0.1:21115;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
  }
}

# Optional: redirect http to https
server {
  listen 80;
  server_name rustdesk.example.com;
  return 301 https://$host$request_uri;
}

Gunakan certbot (Let's Encrypt) atau CA Anda untuk memperoleh sertifikat. Jika relay (hbbr) berjalan pada UDP/TCP publik, buka port tersebut langsung pada firewall namun batasi ke rentang IP yang Anda harapkan, atau tempatkan node relay di subnet privat di belakang load balancer.

DNS, clients and NAT traversal

Arahkan record DNS A (mis., rustdesk.example.com) ke IP publik server Anda. Di klien RustDesk, atur alamat server ke domain itu (untuk lookup ID dan relay). Klien menggunakan ID server untuk rendezvous; jika kedua klien berada di belakang NAT yang ketat, hbbr akan merelay sesi melalui server relay Anda.

Jika Anda mengontrol mesin klien di LAN, Anda bisa menjalankan DNS internal atau mendistribusikan file konfigurasi yang menunjuk klien ke IP internal hbbs untuk koneksi lokal yang lebih cepat.

Scaling and resource guidance

Berapa banyak CPU/RAM yang dibutuhkan relay? Itu bergantung pada sesi konkuren dan tipe sesi:

• Small test server: 1 vCPU, 512 MB RAM — beberapa koneksi idle.
• Production relay (light usage): 2 vCPU, 1–2 GB RAM — puluhan sesi konkuren.
• High throughput relay: 4+ vCPU, 4+ GB RAM and network capacity matching expected bandwidth (e.g., 100+ Mbps).

Kami merekomendasikan autoscaling instance hbbr di belakang load balancer jika Anda mengharapkan lonjakan (remote control berat media, screen sharing). Gunakan orkestrasi container (Kubernetes, Docker Swarm) atau penskalaan horizontal sederhana dengan TCP/UDP load balancer (haproxy, cloud LB) yang mempertahankan IP klien.

Backups, updates and version pinning

Selalu mount volume persisten untuk data dan backup secara teratur. Skrip backup minimal:

# daily-backup.sh
TIMESTAMP=$(date +%F)
mkdir -p /backups/rustdesk/$TIMESTAMP
rsync -a ./data /backups/rustdesk/$TIMESTAMP/
# rotate: keep 14 days
find /backups/rustdesk -maxdepth 1 -type d -mtime +14 -exec rm -rf {} \;

Untuk update, pin image Docker dengan tag daripada :latest. Jalankan pengujian staging saat menaikkan versi image server. Alur kerja contoh:

1. Pull new image: docker pull rustdesk/rustdesk-server:1.3.0 (example).
2. Spin up a test container with the same volumes and run smoke tests.
3. Schedule a maintenance window and replace the containers on production host(s).

Troubleshooting and common pitfalls

Mulai dari log: docker logs rustdesk-hbbs dan docker logs rustdesk-hbbr. Masalah tipikal:

• Clients cannot register: check hbbs is reachable on the domain and TLS is valid.
• Sessions fall back to relay but performance is poor: inspect relay host CPU/memory and network. Relay packets are typically UDP; ensure UDP is allowed through your firewall and on your cloud security group.
• Clients show mismatched versions: use matched or compatible RustDesk client/server versions. If you pin your server image, ensure clients are not using deprecated protocol features.

Jika NAT traversal gagal konsisten untuk banyak klien, masalah biasanya NAT simetris atau firewall enterprise. Dalam kasus tersebut, andalkan relay hbbr dan pantau latensi/throughput untuk memastikan UX yang dapat diterima.

Security considerations

Self‑hosting memindahkan tanggung jawab kepada Anda. Langkah kunci:

• Terminate TLS at a reverse proxy and use strong ciphers. Obtain certs from Let's Encrypt or a trusted CA.
• Harden the host: run only necessary ports, enable automatic security updates on the OS, and use a firewall (ufw/nftables).
• Limit access to admin interfaces and monitor logs for brute force attempts. Consider network segmentation; place relay nodes in a separate subnet if possible.

Jika Anda ingin diskusi lebih luas tentang memperketat akses jarak jauh, lihat tulisan kami tentang remote desktop security dan tradeoff praktis di self‑hosted remote desktop.

When a managed vendor is better

Self‑hosting dengan docker memberi kontrol dan privasi, tetapi jika Anda membutuhkan SLA terkelola penuh, fitur enterprise resmi (manajemen pengguna, penagihan terpusat), atau integrasi Windows AD yang plug‑and‑play, vendor komersial seperti TeamViewer atau AnyDesk mungkin lebih cocok. Jujurlah tentang tradeoff: self‑hosted menghemat biaya berulang per‑kursi dan memberikan lokalisasi data, tetapi membutuhkan waktu operasional untuk memelihara, memantau dan mengamankan.

Next steps and references

Checklist untuk berpindah dari lab ke produksi:

1. Pick a host with Docker Engine 20.10+ and Docker Compose v2.x.
2. Create persistent volumes and a daily backup job.
3. Pin the server image and validate updates in staging.
4. Terminate TLS with NGINX/Traefik and obtain certs from Let's Encrypt.
5. Monitor the relay hosts and scale hbbr when CPU or bandwidth hits health thresholds.

Ingin unduhan bersih untuk dibandingkan berdampingan dengan pendekatan container? Ambil binary atau installer Tenvo di /download dan periksa halaman /pricing kami untuk opsi deployment. Jika Anda lebih memilih panduan setup akses jarak jauh yang lebih luas, remote access setup guide kami membahas jaringan, autentikasi dan aspek kegunaan di berbagai alat.

Menjalankan RustDesk di bawah Docker adalah pendekatan yang solid dan mudah dipelihara untuk kebanyakan self‑hoster: itu menyederhanakan upgrade dan menyatu baik dengan infrastruktur container yang ada. Jika Anda membutuhkan salinan file compose atau bantuan menyesuaikan ini ke Kubernetes, kembali dan saya akan menyediakan manifest K8s dan contoh Helm chart.

Siap mencobanya? Download the necessary clients or test images from /download and get your containerized RustDesk server running today.