स्व-होस्टेड रिमोट डेस्कटॉप: ईमानदार 2026 गाइड

स्व-होस्टेड रिमोट डेस्कटॉप के लिए खोजें और आपको दर्जनों ट्यूटोरियल मिलेंगे जो docker compose up -d पर समाप्त होते हैं। इंस्टॉल सबसे आसान हिस्सा है, और वाकई में यह 30 मिनट का काम है। यह गाइड इसे पूरी तरह कवर करता है — और फिर उस हिस्से को कवर करता है जो तय करता है कि आपको यह करना चाहिए था भी या नहीं: ट्यूटोरियल खत्म होने के बाद इसे चलाते रखने की लागत क्या है।

संक्षिप्त उत्तर

जब कोई आवश्यकता आपको मजबूर करे तभी स्व-होस्ट करें। जब ऐसी कोई आवश्यकता न हो तो प्रबंधित रिले का उपयोग करें। यह सुनने में सरल लग सकता है, इसलिए असली परीक्षण यहाँ है:

• स्व-होस्ट करें अगर: कोई लिखित अनुपालन अनिवार्यता कहती है कि सत्र ट्रैफ़िक तीसरे पक्ष के इन्फ्रास्ट्रक्चर से होकर नहीं जाना चाहिए; आप एयर-गैप्ड या अन्यथा प्रतिबंधित नेटवर्क चला रहे हैं जहाँ बाहरी रिले पहुँचा नहीं जा सकता; या डेटा-निवास नियम किसी ऐसे अधिकार क्षेत्र का नाम लेते हैं जिसके अंदर आपको रुकना अनिवार्य है।
• प्रबंधित रिले का उपयोग करें अगर: आपका कारण किसी भी तरह का "मैं इसे खुद चलाना पसंद करूँगा" है। यह एक वैध प्राथमिकता है, और यह एक लगातार संचालन कार्य भी है — नीचे दिए बिल को देखें इससे पहले कि आप इसके लिए साइन अप करें।

यह स्पष्ट होना महत्वपूर्ण है कि आप किसके बीच विकल्प चुन रहे हैं, क्योंकि यह दो अलग उत्पाद नहीं हैं। Tenvo AGPL-3.0 है और प्रबंधित रिले वही hbbs/hbbr आर्किटेक्चर चलाता है जो यह गाइड इंस्टॉल करता है। विकल्प यह है कि कौन बॉक्स को ऑपरेट करता है, न कि सॉफ़्टवेयर क्या करता है।

पहला: रिले वास्तव में क्या देख सकता है

यह सबसे पहले मायने रखता है, क्योंकि यही आमतौर पर वह कारण होता है जिसकी वजह से लोग स्व-होस्टिंग की ओर बढ़ते हैं — और अक्सर इसे गलत बताया जाता है।

सीधे पीयर-टू-पीयर कनेक्शन पर, सत्र दोनों उपकरणों के बीच एंड-टू-एंड चलता है। जब सीधा कनेक्शन स्थापित नहीं हो पाता — सिमेट्रिक NAT, कड़े कॉर्पोरेट फायरवॉल — तब सत्र रिले किया जाता है, और TLS रिले पर समाप्त होता है। जो भी उस रिले को ऑपरेट करता है वह रिले किए गए ट्रैफ़िक को देखने की स्थिति में होता है। हम अपने के बारे में आपको कुछ और नहीं बताने वाले हैं।

यह प्रोटोकॉल की एक विशेषता है, न कि सर्वर के भुगतानकर्ता की। रिले खुद चलाने से वह कुछ भी एन्क्रिप्ट नहीं होता जो किसी विक्रेता के रिले में नहीं होगा; यह बदलता है कि कौन उस स्थान पर बैठता है। अगर आपके जवाब में "कौन उसे आबाद करने की अनुमति है" लिखित रूप में किसी अनुपालन अनिवार्यता में वर्णित है, तो स्व-होस्टिंग सही उत्तर है और यह गाइड आपके काम की है। अगर कहीं भी यह लिखित नहीं है, तो आप एक ऑपरेशन्स का काम ले रहे हैं एक समस्या को हल करने के लिए जो आपके पास नहीं है।

आप जो बना रहे हैं

दो सेवाएँ:

• hbbs (rendezvous server): प्रारंभिक हैंडशेक संभालता है। दोनों क्लाइंट थोड़ी देर के लिए इसमें कनेक्ट करते हैं ताकि वे एक-दूसरे को खोज सकें, सार्वजनिक कुंजी का आदान-प्रदान कर सकें, और पता कर सकें कि क्या सीधा P2P संभव है। TCP/UDP 21115-21117 पर सुनता है।
• hbbr (relay server): जब सीधा P2P विफल हो तो सत्र को वहन करता है। TCP 21117 (और कुछ परिदृश्यों के लिए UDP) पर सुनता है।

रिले केवल तब शामिल होता है जब P2P काम नहीं करता — यह कंज्यूमर NAT पर सामान्य है, उसी LAN सेटअप पर दुर्लभ है। इसलिए भले ही आप स्व-होस्ट कर रहे हों, आप केवल उन सत्रों के लिए VPS बैंडविड्थ का भुगतान करते हैं जिन्हें वास्तव में रिले की आवश्यकता होती है।

चरण 1: एक VPS चुनें

बैंडविड्थ वह संसाधन है जो मायने रखता है। CPU और RAM न्यूनतम होते हैं, क्योंकि रिले बाइट्स को फॉरवर्ड कर रहा होता है न कि उन्हें प्रोसेस कर रहा होता है।

• Hetzner CX22 (€4/mo, 2 vCPU, 4 GB RAM, 20 TB bandwidth, EU data centres) — कीमत-से-बैंडविड्थ अनुपात के लिहाज़ से सर्वश्रेष्ठ।
• DigitalOcean Basic Droplet ($6/mo, 1 vCPU, 1 GB, 1 TB bandwidth) — अच्छा UX, US/EU क्षेत्र।
• OVH VPS Starter (€3.50/mo, 2 vCPU, 2 GB, unmetered bandwidth) — उच्च बैंडविड्थ परिदृश्यों के लिए सर्वोत्तम।

उन क्लाइंट्स के पास का एक क्षेत्र चुनें जो कनेक्ट होंगे। रिले ट्रैफ़िक राउंड-ट्रिप-बंधित होता है, इसलिए यह आपकी प्रतीत होने वाली विलम्बता पर सबसे बड़ा नियंत्रण है — और, जैसा कि नीचे बताया गया है, वहीं एक अकेला VPS सबसे खराब होता है।

चरण 2: सर्वर सेट करें

एक ताज़ा Ubuntu 22.04 या Debian 12 VPS उठाएँ। root के रूप में SSH करें।

# Update + harden basics
apt update && apt upgrade -y
apt install -y ufw fail2ban docker.io docker-compose-plugin
ufw allow 22/tcp     # SSH
ufw allow 21115:21119/tcp
ufw allow 21115:21119/udp
ufw enable
systemctl enable --now docker

फ़ायरवॉल छोड़ें नहीं। डिफ़ॉल्ट कॉन्फ़िगरेशन केवल आवश्यक पोर्ट ही खोलता है; बाक़ी सब लॉकडाउन होना चाहिए।

चरण 3: Docker के जरिए hbbs + hbbr चलाएँ

/opt/tenvo-relay/docker-compose.yml बनाएँ:

services:
  hbbs:
    image: rustdesk/rustdesk-server:latest
    container_name: hbbs
    restart: unless-stopped
    ports:
      - "21115:21115/tcp"
      - "21116:21116/tcp"
      - "21116:21116/udp"
      - "21118:21118/tcp"
    command: hbbs -r your-server.example.com:21117
    volumes:
      - ./data:/root
  hbbr:
    image: rustdesk/rustdesk-server:latest
    container_name: hbbr
    restart: unless-stopped
    ports:
      - "21117:21117/tcp"
      - "21119:21119/tcp"
    command: hbbr
    volumes:
      - ./data:/root

your-server.example.com को वास्तविक होस्टनाम से बदलें, फिर इसे शुरू करें:

cd /opt/tenvo-relay
mkdir -p data
docker compose up -d
docker compose logs --tail 20

पहली स्टार्ट पर hbbs लॉग में एक सार्वजनिक कुंजी प्रिंट करता है। इसे लॉग्स से सहेजें (id_ed25519.pub डेटा वॉल्यूम में) — क्लाइंट इसका उपयोग यह सत्यापित करने के लिए करते हैं कि वे आपके रिले से कनेक्ट कर रहे हैं न कि किसी नकलची से।

चरण 4: DNS कॉन्फ़िगर करें

relay.yourdomain.com के लिए एक A रेकॉर्ड VPS IP पर पॉइंट करें। एक नंगा IP भी काम करेगा, लेकिन होस्टनाम रख लेना माईग्रेट करते समय बहुत आसान होता है।

चरण 5: क्लाइंट्स को आपके रिले की ओर निर्देशित करें

यह हिस्सा अधिकांश गाइड्स स्किप कर देते हैं। हर क्लाइंट को तीन मान चाहिए:

• ID server = relay.yourdomain.com:21116
• Relay server = relay.yourdomain.com:21117
• Public key = VPS के data/id_ed25519.pub का कंटेंट

Windows, macOS और Linux पर:

1. Tenvo या RustDesk क्लाइंट खोलें — डाउनलोड अगर ज़रूरी हो।
2. Settings → Network → ID/Relay server.
3. ऊपर दिए तीन मान दर्ज करें और सहेजें।
4. क्लाइंट को पुनः आरंभ करें।

स्टेटस संकेतक कुछ सेकंड के भीतर हरा हो जाना चाहिए। अगर यह लाल रहता है तो फ़ायरवॉल नियम और यह जांचें कि सार्वजनिक कुंजी बिल्कुल मेल खाती है — आम कारण आगे का नया लाइनब्रेक होता है।

चरण 6: TLS जोड़ें

रिले पोर्ट्स के सामने एक रिवर्स प्रॉक्सी रखें। Caddy सबसे छोटा रास्ता है:

relay.yourdomain.com {
    reverse_proxy /ws/* localhost:21118
    reverse_proxy * localhost:21115
}

Caddy आपके लिए Let's Encrypt प्रमाणपत्र जारी और नवीनीकृत कर देता है। क्लाइंट्स को पोर्ट 443 और TLS सक्षम करने के लिए अपडेट करें — जिससे आप उन आउटबाउंड फ़ायरवॉल्स को भी पार कर पाएँगे जो केवल 443 की अनुमति देते हैं।

चरण 7: कुंजियों का बैकअप लें

data/ निर्देशिका rendezvous सर्वर की कुंजी युग्म रखती है। इसे खो दें और हर क्लाइंट को नया सार्वजनिक कुंजी के साथ मैन्युअल रूप से पुन:कॉन्फ़िगर करना होगा — हर मशीन पर।

# Local backup
rsync -avz vps:/opt/tenvo-relay/data/ ~/tenvo-relay-backup-$(date +%Y%m%d)/
# OR copy the two key files
scp vps:/opt/tenvo-relay/data/id_ed25519* ~/tenvo-keys/

इसे ऑफ़लाइन स्टोर करें। अगर VPS कभी समझौता हो जाता है तो आप चाहेंगे कि आप उसी कुंजियों के साथ एक ताज़ा बॉक्स पर पुनर्निर्माण कर सकें, ताकि मौजूदा क्लाइंट बिना बदलाव के काम करते रहें।

विफलता के मामले जो ट्यूटोरियल्स छोड़ देते हैं

क्लाइंट रिले तक नहीं पहुँच पाते। लगभग हमेशा फ़ायरवॉल ही कारण होता है। ufw status जाँचें, क्लाउड प्रोवाइडर के सिक्योरिटी ग्रुप में भी वही पोर्ट ओपन हैं यह जाँचें, और पहुँच सत्यापित करने के लिए क्लाइंट से nc -vz relay.yourdomain.com 21116 चलाएँ।

सब कुछ रिले पर वापस गिर जाता है। सिमेट्रिक NAT और कड़े कॉर्पोरेट फायरवॉल हर सत्र को रिले के माध्यम से मजबूर करते हैं। प्रदर्शन बरकरार रहता है, लेकिन अब आपका बैंडविड्थ बिल अपवाद नहीं बल्कि मुख्य कहानी बन जाता है।

रिले मर जाता है और वापस नहीं आता। Docker का restart: unless-stopped सामान्य मामलों को कवर करता है। यह फुल डिस्क, OOM kill, या कर्नेल पैनिक को कवर नहीं करता — उन घटनाओं के लिए आपको निगरानी चाहिए जो किसी को पेज करे, और वह कोई आप ही हैं।

प्रमाणपत्र समाप्त हो जाता है। Caddy के अंतर्गत यह स्वचालित है। nginx + certbot के अंतर्गत यह एक क्रोन जॉब बन जाता है जिसे आपको याद रखना होगा कि यह आपका है; आधिकारिक गाइड के लिए certbot.eff.org देखें।

वह बिल जो ट्यूटोरियल आपको नहीं दिखाते

€4 VPS चालान पर सबसे सस्ती लाइन है, और इसे स्व-होस्टिंग की लागत के रूप में उद्धृत करना उसी तरकीब के बराबर है जैसे किसी कार की खरीद कीमत को चलने की लागत बताना। बाकी चीज़ें:

• आप अपनी स्वयं की रिले के लिए ऑन-कॉल होते हैं। जब यह रात के 2 बजे मरता है, दूर से एक्सेस वही चीज़ है जिसे आप अब फिक्स करने के लिए उपयोग नहीं कर पाएँगे।
• OS पैचिंग, हमेशा के लिए। इंटरनेट पर सार्वजनिक बॉक्स वह बॉक्स है जिसे आप पैच रखते रहने के लिये ज़िम्मेदार हैं।
• कुंजी की रख-रखाव। data/ खो दें और हर क्लाइंट को मैन्युअल रूप से पुनःकॉन्फ़िगर करना होगा। वह बैकअप अब सचमुच उस चीज़ को बन जाता है जिसे आपको सत्यापित करना है, न कि केवल शेड्यूल करना।
• प्रमाणपत्र नवीनीकरण। स्वचालित जब तक एक दिन वह नहीं होता।
• एक क्षेत्र, एक बॉक्स। एक अकेला VPS एक स्थान है और कोई फ़ेलओवर नहीं। दुनिया के दूसरी तरफ के क्लाइंट्स को इसका भुगतान राउंड-ट्रिप विलम्ब के रूप में करना पड़ता है; अगर बॉक्स डाउन है तो सब डाउन हैं।

बैंडविड्थ एकमात्र लागत है जिसे वास्तविक रूप से अनुमानित करना आसान है। रिले किए गए सत्र के मोटे आँकड़े:

• कम गुणवत्ता, टेक्स्ट-भारी काम: ~50 KB/s = 180 MB/hour
• मध्यम, सामान्य ऑफिस काम: ~200 KB/s = 720 MB/hour
• उच्च, वीडियो और डिजाइन काम: ~1 MB/s = 3.6 GB/hour

Hetzner CX22 का 20 TB/month लगभग 5,500 घंटे उच्च-गुणवत्ता रिले किए गए सत्र कवर करता है। एक व्यक्ति या छोटे टीम के लिए वह सीमा कभी बाइंडिंग बाधा नहीं होती — यही बात का सार है। अगर बैंडविड्थ ही वह कारण था जिसकी वजह से आप स्व-होस्ट करने वाले थे, तो वह अच्छा कारण नहीं है। बाइंडिंग बाधाएँ ऊपर चार बिंदुओं में हैं।

प्रबंधित रिले इसके बजाय क्या करता है

वही आर्किटेक्चर, अलग ऑपरेटर। रिले फ़्लीट एक VPS के बजाय मल्टी-रिजन है, इसलिए क्लाइंट उनके नज़दीक किसी नोड से जुड़ते हैं न कि आपके नज़दीक। इसका मॉनिटरिंग उन लोगों द्वारा किया जाता है जिनका यह काम है। कुंजी सामग्री, पैचिंग और प्रमाणपत्र नवीनीकरण आपकी समस्या नहीं रहते। जब कुछ रात में 2am पर टूटता है, तो जिसे पेज किया जाता है वह आप नहीं होते।

यही सब्सक्रिप्शन खरीदता है: Free at $0, Lite at $2.99/mo, Pro at $7.99/mo — किस टियर में क्या है के लिए मूल्य देखें, या अगर आप टीम में डिप्लॉय कर रहे हैं तो व्यावसायिक योजनाएँ देखें। €4 VPS प्लस अपनी ऑन-कॉल रोटा के सापेक्ष, अधिकांश लोगों के लिए गणित बहुत करीब नहीं बैठती।

जब स्व-होस्टिंग सचमुच सही विकल्प है

यह सही विकल्प है जब कोई अनिवार्यता इसे नामित करती है: नियमन वाले कार्य जहाँ ट्रैफ़िक तीसरे पक्ष के इन्फ्रास्ट्रक्चर को पार नहीं कर सकता, एयर-गैप्ड या प्रतिबंधित नेटवर्क जहाँ बाहरी रिले पहुँचा नहीं जा सकता, या निवास नियम जो आपको किसी अधिकार क्षेत्र के भीतर बाँध देते हैं। उन मामलों में परिचालन लागत ओवरहेड नहीं है, यह आवश्यकता है, और यह गाइड ठीक वही है जो आपको चाहिए।

यह भी मायने रखता है कि विकल्प मौजूद है। Tenvo AGPL-3.0 है और सर्वर स्टैक ओपन सोर्स है, इसलिए प्रबंधित रिले एक सुविधा है जिसे आप खरीद रहे हैं, किसी लॉक-इन को स्वीकार नहीं कर रहे। अगर हम कभी उपयोगी होना बंद कर दें, तो बाहर निकलने का रास्ता ऊपर दिया गया गाइड है — यही प्रकाशित करने का मकसद है। देखें प्रबंधित बिल्ड की तुलना सादा RustDesk से कैसे होती है, या सुरक्षा मॉडल कैसे काम करता है।

सारांश

1. आपके क्लाइंट्स के सबसे नज़दीक क्षेत्र में एक VPS।
2. Docker, UFW, और hbbs/hbbr कंटेनर।
3. VPS की ओर संकेत करता हुआ एक DNS A रिकॉर्ड।
4. हर क्लाइंट पर तीन कॉन्फ़िग मान: ID सर्वर, रिले सर्वर, सार्वजनिक कुंजी।
5. data/ का एक ऑफ़लाइन बैकअप जिसे आपने सचमुच एक बार रिस्टोर किया हो।
6. Caddy के माध्यम से TLS, और ऐसी मॉनिटरिंग जो आपको पेज करे।

खड़ा करने में तीस मिनट; मालिकाना होने में अनिश्चित काल। अगर कोई आवश्यकता आपको उस सीट पर बैठाती है तो ऊपर दिए कदम पूरा काम हैं। अगर कुछ भी ऐसा नहीं करता, तो प्रबंधित रिले से शुरू करें — क्लाइंट डाउनलोड करें, और जब किसी अनुपालन फॉर्म की वजह से यह प्रासंगिक हो तब वापस इस पेज पर आइए।