HarnessRouter को self-host कैसे करें: गाइड
Codex, Claude Code और Hermes को एक ही API के पीछे चलाने के लिए HarnessRouter का उपयोग करें। Docker deploy, loopback bind, डिफ़ॉल्ट लॉगिन और TLS सेटअप की पूरी प्रक्रिया जानें।
HarnessRouter क्या हटाता है
आप HarnessRouter Community Edition को self-host करते हैं ताकि अपने सर्वर पर कई agent harnesses के सामने एक API लगा सकें। एक agent harness वह command line प्रोग्राम है जो एक model को loop में चलाता है: यह एक session बनाए रखता है, फाइलों को edit करता है, commands चलाता है, और काम के लिए अनुरोध करने वाले को प्रगति की जानकारी stream करता है। Codex, Claude Code और Hermes प्रत्येक यह काम करते हैं, और प्रत्येक अपने स्वयं के install, अपने स्वयं के credential format और session क्या है, इस बारे में अपनी समझ के साथ आते हैं। HarnessRouter उन सभी को एक container के अंदर चलाता है और सामने एक single HTTP endpoint, एक single login और एक single secret store लगाता है।
यही पूरा विचार है, और इसकी लागत को स्पष्ट रूप से बताना उचित है। आप अपने सर्वर पर एक container, एक login, एक volume और एक upgrade path जोड़ रहे हैं ताकि कई गतिशील हिस्से एक बन जाएं। यदि आप आज केवल एक ही harness चलाते हैं, तो यह उस harness को सीधे install करने की तुलना में एक खराब setup है। वह समझौता इस अनुभाग का अंतिम हिस्सा है, इसलिए deploy करने से पहले उसे पढ़ें।
नीचे दी गई हर चीज़ को image tag 0.5.5 के विरुद्ध जाँचा गया था, जिसे 19 August 2026 को pull किया गया था। यह project लगभग हर दिन नए tags प्रकाशित करता है, इसलिए एक महीने बाद इस पृष्ठ पर भरोसा करने के बजाय उस tag की जाँच करें जिसे आप वास्तव में चला रहे हैं। ये commands github.com/HarnessRouter/harnessrouter पर स्थित project README से ली गई हैं।
Unified Harness Protocol वास्तव में क्या है
HarnessRouter, Unified Harness Protocol (UHP) को लागू करता है, जो unifiedharnessprotocol.org पर प्रकाशित है। UHP यह बताता है कि कोई product किसी harness पर task कैसे शुरू करता है, चलते हुए task को कैसे ट्रैक करता है, sessions और files को कैसे manage करता है, और विफलता की रिपोर्ट कैसे देता है। इस spec का version तारीख के अनुसार निर्धारित है। 19 August 2026 तक जो version live है, वह 2026-08-11 दिनांकित है, और साइट इसे एक draft standard कहती है, जो "बनाने के लिए पर्याप्त स्थिर है, और versioned है ताकि इसे सुरक्षित रूप से बदला जा सके"।
यहाँ "open standard" वाक्यांश को ध्यान से पढ़ें। वही कंपनी specification, reference implementation और 52-check conformance suite लिखती है जो यह तय करता है कि कौन conform करता है। इतने नए protocol के लिए यह सामान्य है, और Apache-2.0 licence का मतलब है कि आप इसके किसी भी हिस्से को fork कर सकते हैं। इसका यह भी अर्थ है कि UHP अभी तक multi-vendor standard नहीं है। इसे एक उभरते हुए protocol के रूप में देखें: उपयोगी, गतिशील, और ऐसी चीज़ जिसे आपके अपने code को बिना rewrite किए उपयोग करना बंद करने में सक्षम होना चाहिए।
शुरू करने से पहले आपकी आवश्यकताएं
Docker और लगभग 4 GB खाली डिस्क स्पेस। आपको एक ऐसे मॉडल प्रदाता से API key की भी आवश्यकता होगी जिसके लिए आप पहले से भुगतान करते हैं। इमेज का आकार लगभग 700 MB है, और शेष डिस्क स्पेस का उपयोग agent CLIs और उनके द्वारा लिखे जाने वाले workspaces के लिए किया जाता है। इमेज में कोई बंडल मॉडल या ट्रायल की (key) शामिल नहीं है, इसलिए जब तक आप किसी प्रदाता को कनेक्ट नहीं करते, तब तक कार्य (tasks) विफल हो जाएंगे। HarnessRouter स्वयं Apache-2.0 लाइसेंस के अंतर्गत है। agent CLIs इस लाइसेंस के अंतर्गत नहीं आते हैं, इसीलिए उन्हें इमेज में शामिल करने के बजाय पहली बार start करने पर fetch किया जाता है।
एक docker run कमांड के साथ HarnessRouter को self-host करें
docker pull harnessrouter/harnessrouter
docker run -d --name harnessrouter \
-p 127.0.0.1:3000:3000 \
-v harnessrouter:/data \
harnessrouter/harnessrouterइसके बाद container के start होने की प्रतीक्षा करें। पहली बार start होने में समय लगता है, और logs में इसका कारण बताया जाता है।
docker logs -f harnessrouterकाम करते समय आपको इस तरह की lines दिखाई देंगी:
installing Claude Code (Anthropic's terms apply)…
installing Codex (Apache-2.0)…
installing Hermes (check its upstream license before use)…ready on :3000 के आने तक प्रतीक्षा करें। यह install प्रक्रिया प्रति volume केवल एक बार होती है, इसलिए बाद के हर start में केवल कुछ सेकंड लगते हैं और कोई install line print नहीं होती।
उस download से दो तथ्य सामने आते हैं, और VPS पर दोनों ही महत्वपूर्ण हैं। पहला, पहली बार boot होने के लिए outbound network access की आवश्यकता होती है। यह image पूरी तरह self-contained नहीं है, इसलिए यदि server egress filter के पीछे है या बाहर जाने का कोई रास्ता नहीं है, तो यह यहाँ अटक जाएगा और कभी भी ready on :3000 print नहीं करेगा। यह पहली बार start होने पर ही विफल हो जाता है, न कि docker pull पर, जो कि पता लगाने के लिए एक भ्रमित करने वाली जगह है। दूसरा, आप तीसरे पक्ष (third-party) के software को उनकी शर्तों के तहत install कर रहे हैं। Claude Code, Anthropic की शर्तों के तहत आता है और Hermes अपने upstream की शर्तों के तहत, इसलिए व्यावसायिक रूप से उपयोग करने से पहले दोनों की जाँच कर लें।
-v harnessrouter:/data एक named Docker volume बनाता है। सभी स्थायी डेटा /data में रहते हैं: SQLite databases, stored files, secret store और agent workspaces। उस volume को delete करने का अर्थ है आपने instance को delete कर दिया है, जिसमें provider keys और सभी transcripts शामिल हैं। container को stop करने के बाद ही इसका backup लें, क्योंकि लिखते समय SQLite database को copy करने से ऐसी file मिल सकती है जो शायद open न हो। यही stop-then-copy का नियम server पर मौजूद हर stateful container पर लागू होता है, हालाँकि विवरण सेवा के अनुसार भिन्न हो सकते हैं, क्योंकि PhotoPrism और Immich में से प्रत्येक को अपनी स्वयं की backup commands की आवश्यकता होती है।
docker stop harnessrouter
docker run --rm -v harnessrouter:/data -v "$PWD":/backup alpine \
tar czf /backup/harnessrouter-data.tgz -C / data
docker start harnessrouterCompose variant और वह लाइन जिसे आपको बदलना है
Repository में एक compose file शामिल है। यह "3000:3000" को publish करती है, जिसका अर्थ है host के सभी interfaces पर access। इसे public server पर चलाने से पहले उस लाइन को बदलें।
services:
harnessrouter:
image: harnessrouter/harnessrouter:0.5.5
ports:
- "127.0.0.1:3000:3000"
env_file:
- .env
volumes:
- harnessrouter-data:/data
restart: unless-stopped
volumes:
harnessrouter-data:Upstream से दो चीजें अलग हैं: bind address, और latest के बजाय एक pinned version tag। Version को pin करना महत्वपूर्ण है क्योंकि 9 और 18 August 2026 के बीच सोलह version tags जारी किए गए थे, और यदि agent runtime आपके नियंत्रण के बिना बदलता है, तो उसे debug करना कठिन होता है। इसके बाद environment file को copy करें, उसकी permissions को lock करें, और start करें।
cp .env.example .env
chmod 600 .env
docker compose up -d
docker compose logs -f.env में आपकी provider key plain text में होती है, इसलिए mode 600 न्यूनतम आवश्यकता है। यदि आप docker compose subcommand से परिचित नहीं हैं, तो Docker Compose command cheat sheet में दैनिक उपयोग होने वाली commands की जानकारी दी गई है।
पोर्ट को 127.0.0.1 पर पब्लिश क्यों किया जाता है, न कि 0.0.0.0 पर
-p 3000:3000 पोर्ट को होस्ट के हर उपलब्ध इंटरफ़ेस पर पब्लिश करता है। -p 127.0.0.1:3000:3000 इसे केवल लूपबैक पर पब्लिश करता है, जिसका अर्थ है कि इसे एक्सेस करने का एकमात्र तरीका केवल VPS के भीतर से है। कंटेनर हमेशा अंदर 3000 पोर्ट पर लिसन करता है, इसलिए बाईं ओर का हिस्सा ही वह है जिसे आप बदलते हैं। जांचें कि आपके पास क्या है:
docker port harnessrouter
sudo ss -ltnp | grep 3000ss का 127.0.0.1:3000 प्रिंट होना सही है। 0.0.0.0:3000 का अर्थ है कि कंसोल पब्लिक इंटरनेट पर है। यह अधिकांश self-hosted ऐप्स की तुलना में यहाँ अधिक खतरनाक है, क्योंकि कंसोल हार्नेस बनाता है, हर ट्रांसक्रिप्ट को पढ़ता है, एजेंट्स चलाता है, और उन एजेंट्स को उनके वर्कस्पेस में एक शेल और वास्तविक फाइलसिस्टम देता है। इसमें वह प्रोवाइडर की (key) भी होती है जिसे आपने कनेक्ट किया है। कोई भी व्यक्ति जो असुरक्षित कंसोल तक पहुँचता है, वह आपके काम को पढ़ सकता है, कमांड चला सकता है, और आपकी की (key) का उपयोग कर सकता है।
होस्ट फायरवॉल आपको इससे नहीं बचाता है। Docker अपने स्वयं के रूल्स को सीधे कर्नल nat टेबल में लिखकर पोर्ट्स पब्लिश करता है, और इनका मूल्यांकन ufw द्वारा मैनेज की जाने वाली चेन से पहले किया जाता है। इसलिए, पब्लिश किया गया पोर्ट तब भी एक्सेसिबल रहता है जब sudo ufw status उसे डिनाइड (denied) के रूप में दिखाता है। किसी अन्य मशीन से टेस्ट करें, न कि VPS से, अन्यथा आप कुछ भी टेस्ट नहीं कर पाएंगे। यह running dsh headless on port 3080 जैसा ही सबक है: सर्विस को लूपबैक पर बाइंड करें, और फिर सोच-समझकर तय करें कि आप इसे कैसे एक्सेस करेंगे।
किसी भी अन्य कार्य से पहले डिफ़ॉल्ट लॉगिन बदलें
http://localhost:3000 पर username harnessrouter और password harnessrouter के साथ साइन इन करें। ये क्रेडेंशियल्स README में प्रिंट किए गए हैं क्योंकि ये केवल प्लेसहोल्डर हैं, गुप्त नहीं। जब तक आप इन्हें बदलते नहीं हैं, कंटेनर हर बार स्टार्ट होने पर आपको चेतावनी देता है:
using the DEFAULT password. Set HR_AUTH_PASSWORD, or change it from the profile page, before exposing this instance.इसे Profile पेज से बदलें, या स्क्रिप्टेड डिप्लॉयमेंट के लिए स्टार्ट-अप के समय सेट करें। HR_AUTH_USER और HR_AUTH_PASSWORD डिफ़ॉल्ट मानों को ओवरराइड कर देते हैं।
docker run -d --name harnessrouter \
-p 127.0.0.1:3000:3000 \
-v harnessrouter:/data \
-e HR_AUTH_USER='you' \
-e HR_AUTH_PASSWORD='the-password-you-chose' \
harnessrouter/harnessrouterइसमें पासवर्ड रीसेट करने के लिए ईमेल की सुविधा नहीं है, क्योंकि इसमें कोई अकाउंट सिस्टम या मेल सर्वर नहीं है। यदि आप पासवर्ड भूल जाते हैं, तो वॉल्यूम में मौजूद auth फ़ाइल को डिलीट करें और रीस्टार्ट करें, फिर डिफ़ॉल्ट क्रेडेंशियल्स के साथ दोबारा साइन इन करें।
docker stop harnessrouter
docker run --rm -v harnessrouter:/data alpine rm -f /data/selfhost-auth.json
docker start harnessrouterHR_AUTH_DISABLED=1 साइन-इन गेट को पूरी तरह से हटा देता है। README में इसे "ऐसे बॉक्स के लिए जिसे कोई और एक्सेस न कर सके" तक सीमित रखने की सलाह दी गई है। पब्लिक IP एड्रेस वाला VPS ऐसा बॉक्स नहीं होता है, इसलिए जब तक आप इसे लैपटॉप पर नहीं चला रहे हैं, तब तक गेट को चालू रखें।
अपना version चेक करें, क्योंकि पुराने versions में कोई gate नहीं है
यह वह हिस्सा है जिसे गंभीरता से लेना चाहिए। versions 0.1.x और 0.2.0 बिना किसी authentication gate के release किए गए थे: जो कोई भी port 3000 तक पहुँच सकता था, वह सीधे console के अंदर होता था। 0.3.0 पहला ऐसा release था जिसमें login की सुविधा दी गई थी। वे पुराने tags अभी भी प्रकाशित हैं और pull किए जा सकते हैं, इसलिए कोई पुराना pinned tag, या किसी सहकर्मी से copy की गई compose file, आज भी एक असुरक्षित console को public port पर डाल सकती है।
19 August 2026 तक, सबसे नया प्रकाशित tag 0.5.5 है, जो 18 August 2026 का है, और latest इसी की ओर इशारा करता है। चेक करें कि आपके पास कौन सा version है, और फिर Docker Hub पर मौजूद tag list से उसकी तुलना करें:
docker image ls harnessrouter/harnessrouter0.3.0 से नीचे के किसी भी version को तुरंत बदला जाना चाहिए, इसे भविष्य के लिए न टालें। 0.3.0 या उससे ऊपर के versions में भी password बदलना आवश्यक है, क्योंकि port 3000 को scan करने वाले व्यक्ति के लिए default password और बिना password के होना एक ही बात है। इस पृष्ठ पर दिए गए version numbers को वर्तमान न मानें। वे ऊपर दी गई तारीख पर सही थे, और यह project बहुत तेज़ी से update होता है।
एक प्रदाता (provider) को कनेक्ट करें
जब तक कोई मॉडल प्रदाता कनेक्ट नहीं होता, तब तक कुछ भी नहीं चलता। इसे कंसोल में Integrations पेज से जोड़ें, या environment में docker run के माध्यम से पास करें। इसका मान JSON है, इसलिए shell में इसे quotes के भीतर रखें:
-e HR_SECRET_GLOBAL_HARNESS_CONN_ANTHROPIC='{"name":"anthropic","provider":"anthropic","api_key":"sk-ant-…"}'.env.example प्रत्येक प्रदाता परिवार के लिए एक कनेक्शन वेरिएबल का नाम बताता है: claude-code बैकएंड के लिए HR_SECRET_GLOBAL_HARNESS_CONN_ANTHROPIC, codex बैकएंड के लिए HR_SECRET_GLOBAL_HARNESS_CONN_OPENAI, और किसी भी OpenAI-compatible एंडपॉइंट के लिए HR_SECRET_GLOBAL_HARNESS_CONN_CUSTOM, जहाँ एक एग्रीगेटर या आपका अपना इन्फरेंस सर्वर काम करता है। संबंधित HR_SECRET_GLOBAL_HARNESS_POLICY_CLAUDE, HR_SECRET_GLOBAL_HARNESS_POLICY_CODEX और HR_SECRET_GLOBAL_HARNESS_POLICY_HERMES वेरिएबल यह बताते हैं कि प्रत्येक बैकएंड डिफ़ॉल्ट रूप से किस कनेक्शन का उपयोग करता है। HR_SECRET_KEY एक अलग चीज़ है, और इसकी आवश्यकता केवल तब होती है जब आप किसी एजेंट से डेटाबेस कनेक्ट करते हैं।
HR_BACKENDS यह चुनता है कि कौन से बैकएंड लोड होंगे, जैसा कि HR_BACKENDS=claude,codex,hermes में है। एक ज्ञात समस्या के बारे में जानना महत्वपूर्ण है इससे पहले कि यह आपको प्रभावित करे: कोई भी मान जिसमें hermes शामिल नहीं है, कंटेनर को तुरंत status 1 के साथ बंद कर देता है और कोई त्रुटि संदेश नहीं देता है। आप शुरू करने के एक सेकंड बाद docker ps -a में Exited (1) देखते हैं, और docker logs कुछ भी उपयोगी नहीं दिखाता है। जब तक upstream इसे ठीक नहीं करता, तब तक hermes को सूची में रखें। यदि Hermes ही एकमात्र harness है जिसे आप चाहते हैं, तो Hermes एजेंट को अपने स्वयं के VPS पर चलाना एक छोटा डिप्लॉयमेंट है।
कंसोल के बिना API को कॉल करें
कंसोल वैकल्पिक है। एक ही API दोनों के लिए काम करता है, और यह Responses-style कॉन्ट्रैक्ट का पालन करता है। सेशन कुकी प्राप्त करने के लिए पहले साइन इन करें:
curl -c hr.cookies http://localhost:3000/api/selfhost/login \
-H 'content-type: application/json' \
-d '{"username":"harnessrouter","password":"your-password"}'फिर एक टास्क भेजें, जिसमें metadata.harness_id में हार्नेस का नाम और वह मॉडल बताएं जिसे आपका कनेक्टेड प्रदाता वास्तव में सर्व करता है:
curl -s -b hr.cookies http://localhost:3000/api/harness/v1/responses \
-H 'content-type: application/json' \
-d '{"input":"Reply with exactly this and nothing else: it works.",
"metadata":{"harness_id":"codex"},
"model":"gpt-5.4-mini",
"stream":false}'एक JSON ऑब्जेक्ट जिसमें आउटपुट ब्लॉक और टोकन काउंट हो, इसका मतलब है कि हार्नेस चल गया है। harness_id को codex से बदलकर claude करने पर वही रिक्वेस्ट एक अलग हार्नेस पर चली जाती है, और यही स्वैप इस सॉफ्टवेयर के अस्तित्व का एकमात्र कारण है। ऊपर दिया गया कस्टम कनेक्शन वह तरीका है जिससे आप हार्नेस को किसी ऐसे OpenAI-compatible एंडपॉइंट की ओर निर्देशित करते हैं जिसे आप पहले से होस्ट कर रहे हैं, ठीक वैसे ही जैसे VPS पर सेल्फ-होस्टेड DeepSeek हार्नेस को कनेक्ट किया जाता है।
इसे किसी पोर्ट को पब्लिश किए बिना अपने लैपटॉप से एक्सेस करें
इसके दो तरीके हैं, और इनमें से कोई भी 0.0.0.0 पर रॉ पोर्ट का उपयोग नहीं करता है।
एक SSH tunnel सबसे आसान तरीका है, और इसके लिए सर्वर पर कुछ भी इंस्टॉल करने की आवश्यकता नहीं है। यह आपकी मशीन के एक लोकल पोर्ट को VPS के लूपबैक (loopback) पर फॉरवर्ड करता है।
ssh -N -L 3000:127.0.0.1:3000 you@your-vpsइसे चलते रहने दें और अपने ब्राउज़र में http://localhost:3000 खोलें। यदि SSH bind: Address already in use प्रिंट करता है, तो इसका मतलब है कि आपके लैपटॉप पर पोर्ट 3000 पहले से ही किसी अन्य प्रक्रिया द्वारा उपयोग में है। ऐसी स्थिति में -L 3100:127.0.0.1:3000 के साथ कोई दूसरा लोकल पोर्ट चुनें और पोर्ट 3100 पर ब्राउज़ करें।
एक terminating reverse proxy तब सबसे अच्छा विकल्प है जब अन्य लोगों को भी एक्सेस की आवश्यकता हो। प्रॉक्सी TLS (transport layer security) सर्टिफिकेट को संभालता है और ट्रैफिक को लूपबैक पर फॉरवर्ड करता है। README में Caddy का कॉन्फ़िगरेशन इस प्रकार दिया गया है:
console.example.com {
encode zstd gzip
reverse_proxy 127.0.0.1:3000 {
flush_interval -1 # agent turns stream for minutes; never buffer them
}
}flush_interval -1 वह लाइन है जिसे लोग अक्सर छोड़ देते हैं। Agent कई मिनटों तक स्ट्रीम टोकन भेजता है, और यदि कोई प्रॉक्सी रिस्पॉन्स को बफर (buffer) करती है, तो वह टर्न समाप्त होने तक उन टोकन को रोक कर रखती है। इस कारण कंसोल जमा हुआ (frozen) दिखता है और फिर एक साथ सब कुछ प्रिंट कर देता है। Nginx में इसका समकक्ष proxy_buffering off; है, जिसे location ब्लॉक के अंदर रखा जाता है। आप जो भी चुनें, DNS नाम को प्रॉक्सी पर पॉइंट रखें और कंटेनर को लूपबैक पर रखें। रिवर्स प्रॉक्सी के रूप में Nginx, Caddy और Traefik की तुलना में बताया गया है कि आपके सर्वर के लिए कौन सा विकल्प सबसे उपयुक्त है।
इसे root के बजाय अपने स्वयं के user के रूप में चलाएं
Docker daemon root के रूप में चलता है, और docker group की सदस्यता root के बराबर होती है, क्योंकि एक सदस्य ऐसा container शुरू कर सकता है जो host filesystem को mount करता है। इसलिए "team को docker group में जोड़ना" उस box पर root access देना है जिसमें आपकी provider key मौजूद है।
सरल संस्करण: एक service account बनाएं जो compose file और .env का स्वामी हो, और उन files को किसी भी shared home directory से बाहर रखें।
sudo adduser --disabled-password --gecos "" harness
sudo install -d -o harness -g harness -m 750 /srv/harnessrouterअधिक मजबूत संस्करण rootless Docker है, जहाँ daemon स्वयं उस unprivileged user के रूप में चलता है। इसके लिए newuidmap और newgidmap के लिए uidmap package की आवश्यकता होती है, और user के लिए /etc/subuid और /etc/subgid में कम से कम 65536 subordinate UIDs की आवश्यकता होती है। uidmap Ubuntu archive में है, लेकिन docker-ce-rootless-extras नहीं है: यह Docker के अपने apt repository (download.docker.com) से आता है, जिसे Docker engine install जोड़ देता है। यदि आपने उस repository से engine install नहीं किया है, तो grep -rl download.docker.com /etc/apt/sources.list.d/ कुछ भी print नहीं करेगा और नीचे दिया गया install package को नहीं ढूंढ पाएगा।
sudo apt install -y uidmap docker-ce-rootless-extras
sudo loginctl enable-linger harness
sudo -iu harness
dockerd-rootless-setuptool.sh install
export DOCKER_HOST=unix:///run/user/$(id -u)/docker.sock
systemctl --user enable --now dockerloginctl enable-linger यहाँ वैकल्पिक नहीं है। इसके बिना, user का systemd instance तब बंद हो जाता है जब अंतिम session समाप्त होता है, इसलिए आपके log out होते ही container मर जाता है। परिणाम की पुष्टि docker info के साथ करें, जो Security Options के अंतर्गत rootless को सूचीबद्ध करता है। Rootless mode अतिरिक्त configuration के बिना 1024 से नीचे के ports को bind नहीं कर सकता है, जो यहाँ मायने नहीं रखता क्योंकि port 3000 उस सीमा से ऊपर है। account को set up करना VPS पर least-privilege users बनाना में कवर किया गया है।
क्या खराब होता है, और आप क्या देखेंगे
कंटेनर शुरू होने के एक सेकंड बाद ही बंद हो जाता है और लॉग खाली होते हैं। docker ps -a में Exited (1) दिखाई देता है। यह ऊपर बताया गया HR_BACKENDS मुद्दा है: आपके मान में hermes छूट गया है। इसे वापस डालें।
पहली बार शुरू होने की प्रक्रिया कभी पूरी नहीं होती। लॉग एक installing लाइन के बाद रुक जाता है और ready on :3000 कभी दिखाई नहीं देता। बॉक्स एजेंट CLI को लाने के लिए नेटवर्क तक नहीं पहुँच पा रहा है, क्योंकि वे इमेज में मौजूद नहीं हैं। आउटबाउंड रूट या प्रॉक्सी सेटिंग्स को ठीक करें, फिर रीस्टार्ट करें।
कंसोल लोड होता है और हर टास्क विफल हो जाता है। कोई प्रदाता (provider) कनेक्टेड नहीं है। इमेज के अंदर कोई बंडल मॉडल और कोई फ्री टियर नहीं है, इसलिए एक नया इंस्टेंस आपको साइन इन तो करा सकता है लेकिन कुछ भी चला नहीं सकता।
प्रॉक्सी के पीछे कंसोल उत्तर देते समय बीच में ही फ्रीज हो जाता है। आउटपुट टर्न समाप्त होने पर एक ही ब्लॉक में दिखाई देता है। यह रिस्पॉन्स बफरिंग है। Caddy में flush_interval -1 सेट करें, या Nginx में proxy_buffering off; सेट करें।
आप अपने लैपटॉप से इसे एक्सेस नहीं कर पा रहे हैं और टनल चालू है। सर्वर पर docker port harnessrouter चलाएँ। यदि यह कुछ भी प्रिंट नहीं करता है, तो कंटेनर कुछ भी पब्लिश नहीं कर रहा है, इसका मतलब है कि इसे -p के बिना शुरू किया गया था।
क्या इसे चलाना सार्थक है?
यदि आप वास्तव में एक से अधिक harness का उपयोग करते हैं और आप तीन अलग-अलग endpoints और credential stores के बजाय एक ही endpoint और एक ही credential store चाहते हैं, तो इसे चलाना सार्थक है। यदि आप इसके ऊपर कोई product बना रहे हैं और चाहते हैं कि harness एक configuration value हो न कि rewrite, तो भी इसे चलाना सार्थक है। UHP आपको यही सुविधा देता है, लेकिन protocol के अभी शुरुआती चरण में होने की चेतावनी को ध्यान में रखें।
यदि आप केवल एक harness का उपयोग करते हैं, तो इसे चलाना सार्थक नहीं है। सर्वर पर उस CLI को install करने में कम components शामिल होते हैं और आपके और CLI के बीच कोई login प्रक्रिया नहीं होती। यदि आप एक ही कार्य पर कई agents को सहयोग करते हुए देखना चाहते हैं, न कि कई harnesses के सामने एक API, तो यह सही विकल्प नहीं है; उस pattern के लिए Omnigent जैसे multi-agent harness देखें। किसी भी स्थिति में deployment के नियम नहीं बदलते हैं। Loopback bind, बदला हुआ password, 0.3.0 या उससे ऊपर का pinned tag, और इसका अपना user होना अनिवार्य है।
FAQ
क्या HarnessRouter को port 3000 पर publish करना सुरक्षित है?
नहीं। यह console harnesses बनाता है, हर transcript को पढ़ता है, shell और filesystem access के साथ agents चलाता है, और आपके द्वारा connect की गई provider key को सुरक्षित रखता है। इसलिए, एक खुला port इन सभी चीजों को उजागर कर देता है। इसे -p 127.0.0.1:3000:3000 के साथ loopback पर publish करें और SSH tunnel या TLS-terminating reverse proxy के माध्यम से एक्सेस करें। केवल host firewall पर्याप्त नहीं है: Docker kernel nat table में अपने नियम खुद लिखता है, इसलिए एक published port internet से जवाब देता है, भले ही ufw उसे denied दिखाए। sudo ss -ltnp | grep 3000 के साथ verify करें, जिसे 127.0.0.1:3000 प्रिंट करना चाहिए।
HarnessRouter के किस version में login gate जोड़ा गया था?
0.3.0। Version 0.1.x और 0.2.0 बिना किसी authentication के release किए गए थे। ये दोनों tags अभी भी published हैं और pull किए जा सकते हैं, इसलिए जो भी इन्हें चला रहा है, वह इस भरोसे पर है कि किसी को port का पता नहीं चलेगा। 19 August 2026 तक, सबसे नया tag 0.5.5 है, जो 18 August 2026 का है। यह देखने के लिए कि आपके पास क्या है, docker image ls harnessrouter/harnessrouter चलाएं, इसकी तुलना इस page के बजाय Docker Hub पर मौजूद tag list से करें, और current version पर भी default password बदलें।
HR_BACKENDS set करने के तुरंत बाद container exit क्यों हो जाता है?
कोई भी HR_BACKENDS value जिसमें hermes शामिल नहीं है, वह container को status 1 के साथ तुरंत बंद कर देती है और कोई error message नहीं देती। यह project README में एक ज्ञात समस्या है। इसका लक्षण एक या दो सेकंड के भीतर docker ps -a में Exited (1) दिखना है, और docker logs में कुछ भी उपयोगी न होना है। जब तक upstream इसे ठीक नहीं करता, HR_BACKENDS=claude,codex,hermes की तरह hermes को list में बनाए रखें।
क्या HarnessRouter को पहली बार start करने पर internet access की आवश्यकता होती है?
हाँ। agent CLIs को image में शामिल करने के बजाय पहली बार start करने पर fetch किया जाता है, क्योंकि प्रत्येक का अपना license होता है। जिस machine में outbound route नहीं होता, वह installing lines प्रिंट करती है और कभी भी ready on :3000 तक नहीं पहुँचती। download प्रति volume एक बार होता है, इसलिए बाद में start करने पर कुछ ही सेकंड लगते हैं और आपके द्वारा connect किए गए model provider के अलावा किसी network की आवश्यकता नहीं होती।
मैं console password भूल गया हूँ। मैं वापस कैसे access करूँ?
इसमें कोई reset email नहीं है, क्योंकि इसमें कोई account system या mail server नहीं है। container को stop करें, volume से /data/selfhost-auth.json को delete करें, इसे फिर से start करें, फिर default credentials के साथ sign in करें और Profile page से नया password set करें। यदि container और volume दोनों का नाम harnessrouter है, तो यह docker stop harnessrouter है, फिर docker run --rm -v harnessrouter:/data alpine rm -f /data/selfhost-auth.json, और अंत में docker start harnessrouter है।