rustdesk docker: containerized RustDesk server guide

आप मैनुअल बिल्ड, निर्भरता की जटिलताओं या नाज़ुक VM इमेज़ से जूझे बिना RustDesk को स्वयं‑होस्ट करना चाहते हैं। यह गाइड दिखाता है कि Docker और Docker Compose से उत्पादन‑तैयार RustDesk सर्वर स्टैक कैसे चलाएँ, ताकि आप अपडेट, बैकअप और स्केलिंग को एक ऑप्स व्यक्ति की तरह प्रबंधित कर सकें — शौकिया की तरह नहीं।

RustDesk के लिए Docker क्यों इस्तेमाल करें

कंटेनर स्व‑होस्टेड रिमोट‑एक्सेस स्टैक के लिए दो तत्काल फायदे देते हैं: पुनरुत्पादन योग्य परिनियोजन और अलगाव। लोकल रूप से hbbs/hbbr कंपाइल करने या प्लेटफ़ॉर्म‑विशिष्ट पैकेज चलाने के बजाय, आप एक Docker इमेज पुल करते हैं, एक स्थायी वॉल्यूम माउंट करते हैं और स्टार्ट करते हैं। इससे अपग्रेड, CI/CD और होस्ट माइग्रेशन सरल होते हैं। यदि आप पहले से ही अन्य सेवाएँ कंटेनरों में चला रहे हैं (NGINX, certbot, मॉनिटरिंग), तो इसी तरह RustDesk जोड़ना आपकी स्टैक को संगत रखता है।

कब कंटेनरीकरण न करें: यदि आपको अत्यधिक प्रदर्शन वाले रिले के लिए कस्टम पैच्ड बाइनरी या गहरे कर्नेल एकीकरण की आवश्यकता है, तो नेटिव इंस्टॉल बेहतर हो सकता है। और यदि आपको विक्रेता से आधिकारिक सपोर्ट वाला एंटरप्राइज़ SLA चाहिए, तो जांचें कि वे कंटेनरों को सपोर्ट करते हैं या नहीं।

RustDesk सर्वर घटक — संक्षिप्त अवलोकन

RustDesk सर्वर रोल को कम से कम दो हिस्सों में विभाजित करता है:

• hbbs — ID/सिग्नलिंग सर्वर। यह क्लाइंट्स के लिए रजिस्ट्रेशन और रैंडीवज़ को संभालता है।
• hbbr — रिले सर्वर (यदि NAT traversal विफल हो)। यह पीयर्स के बीच ट्रैफ़िक रिले करता है।

प्रोडक्शन में आप सामान्यतः दोनों चलाते हैं। एक ही हल्का होस्ट दोनों सेवाएँ चला सकता है; बड़े परिनियोजनों में इन्हें अलग करते हैं, hbbr इंस्टेंसेज़ को लोड बैलेंसर के पीछे रखते हैं और रिले क्षमता के लिए ऑटो‑स्केलिंग जोड़ते हैं।

Quickstart: example Docker Compose deployment

पूर्वापेक्षाएँ: Ubuntu 22.04 LTS (या कोई भी Linux जिस पर Docker Engine 20.10+ हो), Docker Compose v2.x, एक डोमेन नाम (उदाहरण: rustdesk.example.com)। एक छोटा टेस्ट सर्वर के लिए कम से कम 512 MB RAM आवंटित करें; एक रिले के लिए जो कई सक्रिय सत्र संभालेगा, 1 GB+ अनुशंसित है।

नीचे एक व्यावहारिक Docker Compose उदाहरण है जो hbbs और hbbr को अलग‑अलग सेवाओं में चलाता है, स्थायी डेटा माउंट करता है और मानक RustDesk पोर्ट्स प्रकाशित करता है। चलाने से पहले, officical rustdesk/rustdesk-server इमेज टैग्स के लिए नवीनतम स्थिर टैग की जांच करें और यदि आप पिन्ड संस्करण चाहते हैं तो rustdesk/rustdesk-server:latest को बदलें।

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

व्याख्या:

• हम hbbs को TCP/UDP पोर्ट 21115 पर और hbbr को 21116 पर चला रहे हैं — ये RustDesk सर्वर बिल्ड्स के सामान्य डिफ़ॉल्ट हैं। उस इमेज के लिए पोर्ट मैपिंग की पुष्टि करें जिसे आप उपयोग कर रहे हैं (कुछ समुदाय द्वारा बनाए गए बिल्ड विभिन्न डिफ़ॉल्ट उपयोग करते हैं)।
• स्थायी वॉल्यूम ./data/hbbs और ./data/hbbr आपके रजिस्ट्रेशन और रिले डेटा को रीस्टार्ट्स में बनाए रखते हैं।
• बेसिक रिसिलिएंस के लिए restart: unless-stopped का उपयोग करें; प्रोडक्शन में अपने ऑर्केस्ट्रेशन प्लेटफ़ॉर्म की रीस्टार्ट नीतियों से जोड़ें।

सुरक्षित रूप से एक्सपोज़ करें: TLS, रिवर्स प्रॉक्सी और फ़ायरवॉल

RustDesk का सिग्नलिंग और रिले ट्रैफ़िक TLS और मानक फ़ायरवॉल नियमों से सुरक्षित किया जा सकता है। दो सामान्य दृष्टिकोण होते हैं:

1. hbbs के सामने एक प्रॉक्सी के साथ डायरेक्ट TLS (वेब‑लेवल सर्टिफिकेट प्रबंधन के लिए अनुशंसित)।
2. hbbr को कच्चे TCP/UDP रिले के रूप में रखें और होस्ट नेटवर्क को सुरक्षित रखें (ufw/nftables का उपयोग करें), जबकि hbbs को TLS से सुरक्षित करें।

अधिकांश सेटअप TLS terminate करने और ट्रैफ़िक को hbbs पर फारवर्ड करने के लिए NGINX या Traefik का उपयोग करते हैं। rustdesk.example.com के लिए TLS terminate करने वाला NGINX सर्वर ब्लॉक उदाहरण:

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;
}

certbot (Let's Encrypt) या अपनी CA का उपयोग करके सर्ट हासिल करें। यदि आपका रिले (hbbr) सार्वजनिक UDP/TCP पर चलता है, तो उन पोर्ट्स को सीधे फ़ायरवॉल पर एक्सपोज़ करें परंतु अपेक्षित IP रेंज तक सीमित रखें, या रिले नोड्स को प्राइवेट सबनेट में रखें और उनके आगे एक लोड बैलेंसर लगाएँ।

DNS, क्लाइंट्स और NAT traversal

एक DNS A रिकॉर्ड (उदाहरण: rustdesk.example.com) अपने सर्वर के पब्लिक IP पर पॉइंट करें। RustDesk क्लाइंट में सर्वर एड्रेस को उस डोमेन पर सेट करें (ID और रिले lookup के लिए)। क्लाइंट्स ID सर्वर का उपयोग रैंडीवज़ के लिए करते हैं; यदि दोनों क्लाइंट्स प्रतिबंधित NAT के पीछे हैं, तो hbbr आपके रिले सर्वर के माध्यम से सत्र रिले करेगा।

यदि आप LAN में क्लाइंट मशीनों को नियंत्रित करते हैं, तो आप एक इंटरनल DNS चला सकते हैं या एक कॉन्फ़िगरेशन फ़ाइल वितरित कर सकते हैं जो क्लाइंट्स को तेज़ लोकल कनेक्शनों के लिए hbbs के इंटरनल IP की ओर निर्देशित करे।

स्केलिंग और संसाधन मार्गदर्शन

रिले को कितना CPU/RAM चाहिए? यह समवर्ती सत्रों और सत्र के प्रकार पर निर्भर करता है:

• छोटा टेस्ट सर्वर: 1 vCPU, 512 MB RAM — कुछ निष्क्रिय कनेक्शनों के लिए।
• प्रोडक्शन रिले (हल्का उपयोग): 2 vCPU, 1–2 GB RAM — दर्जनों समवर्ती सत्रों के लिए।
• उच्च थ्रूपुट रिले: 4+ vCPU, 4+ GB RAM और अपेक्षित बैंडविड्थ के अनुरूप नेटवर्क क्षमता (उदा., 100+ Mbps)।

यदि आप स्पाइक्स (मीडिया‑भारी रिमोट कंट्रोल, स्क्रीन शेयरिंग) की उम्मीद करते हैं तो hbbr इंस्टेन्सेज़ को लोड बैलेंसर के पीछे ऑटो‑स्केल करने की अनुशंसा करते हैं। कंटेनर ऑर्केस्ट्रेशन (Kubernetes, Docker Swarm) या क्लाइंट IPs को संरक्षित रखने वाले साधारण हॉरिज़ॉन्टल स्केलिंग के साथ TCP/UDP लोड बैलेंसर (haproxy, क्लाउड LB) का उपयोग करें।

बैकअप, अपडेट और वर्शन पिनिंग

हमेशा डेटा के लिए स्थायी वॉल्यूम माउंट करें और नियमित रूप से बैकअप लें। एक न्यूनतम बैकअप स्क्रिप्ट:

# 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 {} \;

अपडेट्स के लिए, :latest के बजाय Docker इमेज को टैग के साथ पिन करें। सर्वर इमेज बढ़ाने पर स्टेजिंग टेस्ट चलाएँ। उदाहरण वर्कफ़्लो:

1. नया इमेज पुल करें: docker pull rustdesk/rustdesk-server:1.3.0 (उदाहरण)।
2. उसी वॉल्यूम्स के साथ एक टेस्ट कंटेनर स्पिन करें और स्मोक टेस्ट चलाएँ।
3. मेंटेनेंस विंडो शेड्यूल करें और प्रोडक्शन होस्ट(स) पर कंटेनरों को बदलें।

समस्या निवारण और सामान्य जाल

लॉग से शुरू करें: docker logs rustdesk-hbbs और docker logs rustdesk-hbbr। सामान्य समस्याएँ:

• क्लाइंट रजिस्टर नहीं कर पा रहे: जांचें कि hbbs डोमेन पर पहुंच योग्य है और TLS वैध है।
• सत्र रिले पर फallback होते हैं लेकिन प्रदर्शन खराब है: रिले होस्ट का CPU/मेमोरी और नेटवर्क जांचें। रिले पैकेट सामान्यतः UDP होते हैं; सुनिश्चित करें कि UDP आपके फ़ायरवॉल और क्लाउड सिक्योरिटी ग्रुप में अनुमति है।
• क्लाइंट्स पर असंगत वर्शन दिख रहे हैं: मेल खाते या संगत RustDesk क्लाइंट/सर्वर वर्शन का उपयोग करें। यदि आप सर्वर इमेज पिन करते हैं, तो सुनिश्चित करें कि क्लाइंट्स डिप्रिकेटेड प्रोटोकॉल फीचर्स का उपयोग नहीं कर रहे।

यदि कई क्लाइंट्स के लिए NAT traversal लगातार विफल हो रहा है, तो समस्या आमतौर पर symmetric NAT या एंटरप्राइज़ फ़ायरवॉल होती है। ऐसे मामलों में hbbr रिले पर निर्भर करें और स्वीकार्य यूएक्स सुनिश्चित करने के लिए लेटनसी/थ्रूपुट का मॉनिटर करें।

सुरक्षा विचार

स्वयं‑होस्ट करना जिम्मेदारी आपके ऊपर डालता है। मुख्य कदम:

• रिवर्स प्रॉक्सी पर TLS terminate करें और मजबूत सिफ़र का उपयोग करें। Let's Encrypt या किसी भरोसेमंद CA से सर्ट लें।
• होस्ट को हार्डन करें: केवल आवश्यक पोर्ट खोलें, OS पर ऑटोमैटिक सुरक्षा अपडेट सक्षम रखें और फ़ायरवॉल (ufw/nftables) का उपयोग करें।
• एडमिन इंटरफेस तक पहुँच सीमित रखें और ब्रूट फोर्स प्रयासों के लिए लॉग्स मॉनिटर करें। नेटवर्क सेगमेंटेशन पर विचार करें; संभव हो तो रिले नोड्स को अलग सबनेट में रखें।

यदि आप रिमोट एक्सेस को लॉकडाउन करने पर विस्तृत चर्चा चाहते हैं, तो हमारे लेख देखें: remote desktop security और self‑hosted remote desktop में व्यावहारिक ट्रेडऑफ़।

जब मैनेज्ड विक्रेता बेहतर होता है

Docker के साथ स्वयं‑होस्ट करने से नियंत्रण और गोपनीयता मिलती है, लेकिन यदि आपको पूर्ण प्रबंधित SLA, आधिकारिक एंटरप्राइज़ फीचर्स (यूज़र मैनेजमेंट, केंद्रीकृत बिलिंग), या टर्न‑की Windows AD एकीकरण चाहिए, तो TeamViewer या AnyDesk जैसे वाणिज्यिक विक्रेता बेहतर विकल्प हो सकते हैं। ट्रेडऑफ़ के प्रति पारदर्शी रहें: स्वयं‑होस्टिंग प्रति‑सीट आवर्ती शुल्क बचाता है और डेटा लोकैलिटी देता है, पर इसमें मेंटेन, मॉनिटर और सिक्योर करने का ऑपरेशनल समय खर्च होता है।

अगले कदम और संदर्भ

प्रोडक्शन तक पहुँचने के लिए चेकलिस्ट:

1. ऐसा होस्ट चुनें जिस पर Docker Engine 20.10+ और Docker Compose v2.x हों।
2. स्थायी वॉल्यूम बनाएं और एक दैनिक बैकअप जॉब रखें।
3. सर्वर इमेज पिन करें और स्टेजिंग में अपडेट्स को मान्य करें।
4. NGINX/Traefik के साथ TLS terminate करें और Let's Encrypt से सर्ट लें।
5. रिले होस्ट्स की निगरानी करें और CPU या बैंडविड्थ हेल्थ थ्रेशोल्ड पर hbbr को स्केल करें।

क्लीन डाउनलोड लेकर कंटेनर तरीके से साइड‑बाय‑साइड तुलना करना चाहते हैं? Tenvo के binaries या installers /download पर Grab करें और परिनियोजन विकल्पों के लिए हमारे /pricing पृष्ठ को देखें। यदि आप विस्तृत रिमोट एक्सेस सेटअप चाहेंगे, तो हमारा remote access setup guide नेटवर्क, ऑथ और उपयोगिता विषयों पर टूल्स के बीच कवर करता है।

Docker के तहत RustDesk चलाना अधिकांश स्वयं‑होस्टर्स के लिए एक ठोस, बनाए रखने योग्य तरीका है: यह अपग्रेड्स को सरल बनाता है और मौजूदा कंटेनर इंफ्रा के साथ अच्छी तरह मेल खाता है। यदि आप Kubernetes के लिए एक मैनिफेस्ट या Helm चार्ट चाहते हैं, तो बताइए—मैं K8s मैनिफेस्ट और Helm चार्ट का उदाहरण प्रदान कर दूँगा।

प्रयास करने के लिए तैयार हैं? आवश्यक क्लाइंट्स या टेस्ट इमेजेज़ /download से डाउनलोड करें और अपना कंटेनराइज़्ड RustDesk सर्वर आज ही चलाएँ।