SSD Nodes Learn 🎉 VPS $4.99/माह से
गाइड Matt Connorलेखक: Matt Connor

OpenTag को VPS पर कैसे host करें

OpenTag को VPS पर host करने का तरीका जानें। Slack और GitHub mentions को अपने coding agent तक पहुँचाने के लिए TLS ingress, webhook signature और token scopes सेटअप करें।

जब आप किसी agent का उल्लेख करते हैं तो OpenTag क्या करता है

OpenTag Slack thread या GitHub issue में किए गए @mention को आपके अपने मशीन पर चलने वाले एक coding agent में बदल देता है। जब कोई किसी issue पर @opentag investigate this comment करता है, तो एक listener उस platform event को प्राप्त करता है, उसके signature की जाँच करता है, mention को एक bound project से मिलाता है, local checkout पर एक coding agent शुरू करता है, और परिणाम को उसी thread में वापस post कर देता है।

यह project MIT licensed है और amplifthq/opentag पर उपलब्ध है। अगस्त 2026 तक, सबसे नया tagged release v0.9.0 है, जिसे 28 जुलाई 2026 को प्रकाशित किया गया था, और यह एक npm package के रूप में उपलब्ध है। इसका कोई आधिकारिक container image नहीं है, इसलिए आप जिस version को pin करते हैं वह npm version है। नीचे दिए गए सभी commands इसे pin करते हैं।

GitHub के कारण यह एक laptop project के बजाय एक VPS project बन जाता है। GitHub repository events को एक ऐसे URL पर HTTP request भेजकर deliver करता है जिसे आप एक बार register करते हैं, इसलिए उस URL को कल भी उसी address पर जवाब देने में सक्षम होना चाहिए।

चार मुख्य घटक

Listener प्लेटफॉर्म इवेंट्स को प्राप्त करता है, और प्रत्येक प्लेटफॉर्म के अपने इवेंट्स होते हैं। GitHub listener पोर्ट 3050 पर /github/webhooks पाथ पर एक HTTP एंडपॉइंट है। Slack Events API listener पोर्ट 3040 पर /slack/events पर स्थित है। Slack को Socket Mode में भी चलाया जा सकता है, जहाँ ऐप एक आउटबाउंड WebSocket खोलता है और उसे किसी इनबाउंड पोर्ट की आवश्यकता नहीं होती है।

Dispatcher समन्वयक (coordinator) है। यह डिफ़ॉल्ट रूप से पोर्ट 3030 पर लिसन करता है, OPENTAG_DATABASE_PATH द्वारा सेट की गई लोकल डेटाबेस फ़ाइल में रन स्टेट रखता है, और प्रत्येक रन के लिए ऑडिट ट्रेल रिकॉर्ड करता है। बॉक्स के बाहर की किसी भी चीज़ को इस पोर्ट तक कभी नहीं पहुँचना चाहिए।

Runner एक लोकल डेमन है। यह काम के लिए पोलिंग करता है, रन को क्लेम करता है, उस पर लीज रखता है, और रन के सक्रिय रहने के दौरान डिफ़ॉल्ट रूप से हर 15 सेकंड में हार्टबीट भेजता है। यह किसी भी ऐसे क्लेम किए गए रन को अस्वीकार कर देता है जिसका प्रोजेक्ट टारगेट गायब हो या इसके कॉन्फ़िगरेशन में मौजूद अलाउलिस्ट (allowlist) से बाहर हो। यह वह चेक है जो GitHub इवेंट को आपके एजेंट को किसी ऐसे रिपॉजिटरी की ओर इशारा करने से रोकता है जिसे आपने कभी बाइंड नहीं किया था।

Executor स्वयं कोडिंग एजेंट है। OpenTag इसे ACP (agent client protocol) के माध्यम से लॉन्च करता है, जो स्टैंडर्ड इनपुट और आउटपुट पर उपयोग किया जाने वाला एक JSON-RPC प्रोटोकॉल है। इसलिए एजेंट OpenTag द्वारा दिए गए वर्किंग डायरेक्टरी के अंदर एक चाइल्ड प्रोसेस के रूप में चलता है। इन-बिल्ट नामों में echo, codex, claude-code, cursor, opencode, hermes और openclaw शामिल हैं। echo से शुरुआत करें, जो कि वह एक्जीक्यूटर है जिसके साथ उदाहरण कॉन्फ़िगरेशन आता है, क्योंकि यह साबित करता है कि कोई मॉडल आपके कोड को छूने से पहले पूरा पाथ सही ढंग से काम कर रहा है।

क्रम कभी नहीं बदलता: प्लेटफॉर्म इवेंट, सिग्नेचर चेक, रन रिकॉर्ड, क्लेम, एजेंट, थ्रेड में रिप्लाई।

लैपटॉप और टनल पर्याप्त क्यों नहीं हैं

GitHub सेटअप गाइड आपको ngrok http 3050 चलाने और टनल होस्ट को रिपॉजिटरी वेबहुक में पेस्ट करने के लिए कहती है। यह पहले दस मिनट के लिए काम करता है। एक फ्री टनल होस्ट हर बार प्रोसेस रीस्टार्ट होने पर बदल जाता है, और लैपटॉप के स्लीप मोड में जाने पर यह काम करना बंद कर देता है। GitHub पुराने पेलोड URL को बनाए रखता है और उसे बार-बार ट्राई करता रहता है, इसलिए वेबहुक सेटिंग्स में 'Recent Deliveries' टैब विफलताओं से भर जाता है जबकि थ्रेड शांत रहता है। एक सप्ताह तक किसी को पता नहीं चलता, क्योंकि जो वेबहुक कुछ नहीं करता, वह बिल्कुल ऐसे बॉट जैसा दिखता है जिसका किसी ने जिक्र ही न किया हो।

एक VPS उन दो समस्याओं को ठीक करता है जो बाधा बनती हैं। DNS नाम नहीं बदलता है, इसलिए जो पेलोड URL आप एक बार पेस्ट करते हैं वह सही बना रहता है। मशीन स्लीप मोड में नहीं जाती है, इसलिए 02:00 बजे आने वाली किसी टिप्पणी का उत्तर मिल जाता है। सबसे पहले सर्वर को ठीक से सेट करें: नए VPS पर पहले दस मिनट में उस लॉगिन यूजर और फायरवॉल को कवर किया गया है जिसे यह गाइड आधार मानती है।

Slack एक अपवाद है। Socket Mode में यह बाहर की ओर कनेक्ट होता है और इसे किसी पब्लिक URL की आवश्यकता नहीं होती, इसलिए केवल Slack वाला डिप्लॉयमेंट सुरक्षित रह सकता है। GitHub में इसका कोई समकक्ष नहीं है। रिपॉजिटरी वेबहुक इनबाउंड HTTP होते हैं, जिसका अर्थ है एक पब्लिक एंडपॉइंट, और इसका मतलब है TLS (ट्रांसपोर्ट लेयर सिक्योरिटी) और सिग्नेचर चेक की आवश्यकता।

Ubuntu पर pinned release से OpenTag को self-host करना

OpenTag v0.9.0 के लिए Node.js 22 या उससे नया वर्ज़न आवश्यक है। Ubuntu 24.04 अपने रिपॉजिटरी में Node 18 प्रदान करता है, इसलिए इसे NodeSource से इंस्टॉल करें।

curl -fsSL https://deb.nodesource.com/setup_22.x -o nodesource_setup.sh
sudo -E bash nodesource_setup.sh
sudo apt install -y nodejs
node -v

node -v को v22 या उससे अधिक प्रिंट करना चाहिए। Node 20 पर इंस्टॉलेशन एक EBADENGINE चेतावनी देता है और CLI शुरू होने पर विफल हो सकता है।

सर्विस को अपना स्वयं का अकाउंट दें। एजेंट इस यूजर की अनुमतियों के साथ चलता है, इसलिए यह आपका लॉगिन नहीं होना चाहिए और न ही यह root होना चाहिए। VPS पर Least privilege users यह बताता है कि यह अलगाव अतिरिक्त प्रयास के लायक क्यों है।

sudo adduser --disabled-password --gecos "" opentag
sudo loginctl enable-linger opentag
sudo npm install -g @opentag/cli@0.9.0
command -v opentag

command -v opentag को /usr/bin/opentag जैसा पाथ प्रिंट करना चाहिए। Linux पर linger सेटिंग महत्वपूर्ण है: OpenTag अपनी बैकग्राउंड सर्विस को systemd के माध्यम से इंस्टॉल करता है, और बिना linger के यूजर सर्विस आपके SSH सेशन के बंद होते ही रुक जाती है।

उस यूजर के रूप में सेटअप चलाएं।

sudo -iu opentag opentag setup

सेटअप छह चीजें पूछता है: CLI भाषा, लोकल लिसनिंग एड्रेस, कोडिंग एजेंट, काम करने के लिए लोकल प्रोजेक्ट, सेव करने के लिए प्लेटफॉर्म क्रेडेंशियल्स, और चलाने का तरीका। लिसनिंग एड्रेस को 127.0.0.1 पर रखें, क्योंकि nginx TLS को टर्मिनेट करता है और इसे फॉरवर्ड करता है, इसलिए लिसनर्स को बाहर से एक्सेस करने योग्य होने की आवश्यकता नहीं है। GitHub के लिए यह owner/repo फॉर्मेट में रिपॉजिटरी, क्या यह pull requests खोल सकता है, वेबहुक पोर्ट (डिफ़ॉल्ट रूप से 3050) और टोकन के बारे में भी पूछता है। अंत में बैकग्राउंड सर्विस मोड चुनें। यदि आपके पास पहले से ही कॉन्फ़िगरेशन है और आप बिना प्रॉम्प्ट के सर्विस इंस्टॉल करना चाहते हैं, तो opentag setup --service ऐसा करता है।

कॉन्फ़िगरेशन /home/opentag/.config/opentag/config.json में और रनटाइम स्टेट /home/opentag/.local/state/opentag में सेव होती है। सेटअप द्वारा फाइल लिखने के बाद इन कुंजियों को मैन्युअल रूप से जांचना उचित है।

{
  "runnerId": "runner_local",
  "dispatcherUrl": "http://localhost:3030",
  "runnerToken": "...",
  "approvalMode": "ask",
  "repositories": []
}

पुराने साझा pairingToken की तुलना में runnerToken, जो रनर-स्कोप वाला बेयरर टोकन है, को प्राथमिकता दें। कॉन्फ़िगरेशन फाइल क्रेडेंशियल्स को प्लेन टेक्स्ट में रखती है जब तक कि आप उन्हें सीक्रेट रेफरेंस से न बदल दें, जो स्टार्टअप पर एनवायरनमेंट या डिस्क पर मौजूद फाइल से वैल्यू पढ़ता है। किसी भी स्थिति में, यह फाइल बॉक्स पर सबसे संवेदनशील चीज है: मोड 600, opentag के स्वामित्व में, और कभी भी git रिपॉजिटरी के अंदर नहीं। व्यापक तर्क AI एजेंटों से सीक्रेट्स को दूर रखना में दिया गया है।

किसी भी चीज को एक्सपोज करने से पहले इंस्टॉलेशन की जांच करें।

sudo -iu opentag opentag doctor
sudo -iu opentag opentag status

opentag doctor डिस्पैचर, बाइंडिंग्स, चेकआउट्स और एक्जीक्यूटर्स की जांच करता है। opentag status कॉन्फ़िगरेशन और रनटाइम स्टेट को प्रिंट करता है, और रन मौजूद होने पर इसे एक सिंगल रन तक सीमित किया जा सकता है। इससे पहले कि आप किसी प्लेटफॉर्म को इस बॉक्स पर पॉइंट करें, doctor द्वारा रिपोर्ट की गई हर चीज को ठीक करें।

TLS को सामने रखें और केवल दो paths खोलें

Nginx TLS को terminate करता है और केवल दो paths को forward करता है। बाकी सब कुछ 404 return करता है, इसलिए जो scanner host को ढूँढता है, उसे यह पता नहीं चलता कि उसके पीछे क्या चल रहा है।

/etc/nginx/sites-available/opentag पर एक plain port 80 server block लिखें जिसमें नीचे दिए गए दो locations हों, फिर Certbot को TLS वाला हिस्सा जोड़ने दें।

sudo apt install -y nginx certbot python3-certbot-nginx
sudo ln -s /etc/nginx/sites-available/opentag /etc/nginx/sites-enabled/opentag
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d opentag.example.com

nginx -t, syntax is ok और test is successful को print करता है, और यह एक typo और एक ऐसे reload के बीच एकमात्र सुरक्षा है जो साइट को down कर सकता है। Certbot on Ubuntu 24.04 with nginx renewal और उन तरीकों को कवर करता है जिनसे ACME (automatic certificate management environment) challenge विफल हो सकता है। तैयार block ऐसा दिखता है।

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

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

    client_max_body_size 2m;

    location = /github/webhooks {
        proxy_pass http://127.0.0.1:3050;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }

    location = /slack/events {
        proxy_pass http://127.0.0.1:3040;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }

    location / {
        return 404;
    }
}

location = /github/webhooks में = एक exact match है, और बिना port के बाद कुछ भी न होने पर proxy_pass original URI को बिना बदले pass कर देता है। = को हटा दें और /github/webhooks/ के अंतर्गत आने वाला हर path भी forward हो जाएगा, जो कि listener की आवश्यकता से अधिक surface area है।

Firewall को सीमित रखें।

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw status

Ports 3030, 3040 और 3050 कभी नहीं खोले जाते। पुष्टि करें कि वे हर interface के बजाय loopback पर bound हैं।

sudo ss -tlnp

हर OpenTag line को 127.0.0.1:3030 या उसके समान होना चाहिए। 0.0.0.0:3050 पढ़ने वाली line का मतलब है कि listener खुद को पूरे internet के लिए पेश कर रहा है और केवल ufw उसे रोक रहा है, जो कि एक firewall गलती से open agent trigger का कारण बन सकता है। ufw firewall basics बताता है कि वह default deny वास्तव में क्या कर रहा है।

दो जाँचें front door को प्रमाणित करती हैं। curl -I https://opentag.example.com/, Nginx से 404 return करता है, जो दर्शाता है कि certificate valid है और catch-all बंद है। बिना signature वाले /slack/events या /github/webhooks के अनुरोध को कभी भी 200 return नहीं करना चाहिए।

हर signature की पुष्टि करें, क्योंकि URL public है

कोई भी payload URL को ढूँढ सकता है। यह आपके repository settings, browser history, या किसी ticket में पेस्ट किए गए screenshot में मौजूद होता है। signature ही वह एकमात्र चीज है जो एक वास्तविक GitHub delivery को किसी व्यक्ति द्वारा हाथ से टाइप किए गए request से अलग करती है।

GitHub प्रत्येक delivery को webhook secret के साथ sign करता है और परिणाम को x-hub-signature-256 header में भेजता है। OpenTag उस header की पुष्टि platforms.github.webhookSecret के विरुद्ध करता है। प्रोजेक्ट के hardening notes सीधे तौर पर यह नियम बताते हैं: /github/webhooks पर unsigned source events को स्वीकार न करें। Slack प्रत्येक request को SLACK_SIGNING_SECRET के साथ sign करता है और एक timestamp शामिल करता है, ताकि capture किए गए body को घंटों बाद replay न किया जा सके।

इसे छोड़ना कोई छोटा जोखिम नहीं है। एक unverified endpoint हाथ से लिखे गए issue_comment payload को स्वीकार कर लेता है जिसमें @opentag होता है, और फिर OpenTag आपके token के साथ, आपके checkout में, किसी अजनबी के निर्देशों पर एक coding agent चलाता है। उत्तर उस thread पर जाता है जिसे fake payload नाम देता है।

OpenTag इसके ऊपर दो परतें जोड़ता है। Source deliveries को delivery ID द्वारा ट्रैक किया जाता है, इसलिए एक ही event को दोबारा deliver करने से दूसरी बार run शुरू नहीं होता है। Runner calls idempotency keys स्वीकार करते हैं, इसलिए एक को replay करने पर दूसरा audit event जोड़े बिना success का उत्तर मिलता है।

Rate limits कॉन्फ़िगर करने योग्य हैं और इन्हें चालू रखना चाहिए। OPENTAG_RATE_LIMIT_WINDOW_MS और OPENTAG_RATE_LIMIT_MAX_REQUESTS request rate को सीमित करते हैं, OPENTAG_MAX_REQUEST_BODY_BYTES body को सीमित करता है, और एक बहुत बड़े payload को 413 request_body_too_large के साथ अस्वीकार कर दिया जाता है। OPENTAG_RATE_LIMIT_DISABLED=true केवल local development के लिए मौजूद है, और public box पर इसका कोई स्थान नहीं है। उन्हीं notes से एक और नियम: एक public relay URL को HTTPS का उपयोग करना चाहिए, और CLI केवल localhost के लिए plain HTTP की अनुमति देता है।

बॉट को वास्तव में किन टोकन स्कोप की आवश्यकता है?

GitHub पर, OpenTag एक GitHub App के बजाय fine-grained personal access token का उपयोग करता है। दस्तावेज़ बताते हैं कि App पाथ अभी नियोजित है और वर्तमान में डिफ़ॉल्ट CLI सेटअप नहीं है, और इसका एक परिणाम है जिसे लोग अक्सर अनदेखा कर देते हैं: बॉट उस व्यक्ति के रूप में टिप्पणी करता है जिसने टोकन बनाया है। इसे ऐसे खाते के तहत बनाएं जिसे आप हर triage उत्तर में उद्धृत होते हुए देखने के लिए तैयार हों।

इसे सेटअप गाइड के अनुसार ही सीमित रखें। Only select repositories चुनें और एक रिपॉजिटरी चुनें। Issues: Read and write और Pull requests: Read and write अनुमतियाँ प्रदान करें। किसी उल्लेख को पढ़ने और थ्रेड में उत्तर देने के लिए यह पर्याप्त है।

ध्यान दें कि क्या गायब है: कोड तक write access। OpenTag तब तक ब्रांच पुश नहीं करता जब तक कि preparePullRequestBranch को true पर सेट न किया जाए, और एक अलग githubApplyToken मौजूद होता है ताकि कोड लिखने वाला टोकन वह न हो जो टिप्पणियाँ लिखता है। उन्हें अलग रखें, और write टोकन को तब तक बंद रखें जब तक कि read-and-comment पाथ कुछ हफ़्तों तक न चल जाए।

जिस कॉन्फ़िगरेशन से बचना चाहिए वह है All repositories पर Contents: Read and write वाला टोकन। अब उन सभी रिपॉजिटरी में टिप्पणी करने वाला कोई भी व्यक्ति एक ऐसे एजेंट को निर्देशित कर सकता है जिसके पास कमिट अधिकार हैं, और ऑडिट ट्रेल यह कहेगा कि टोकन स्वामी ने ऐसा किया है। एजेंट द्वारा विश्वास अर्जित करने के बाद, एक-एक करके स्कोप बढ़ाएं।

Slack पर बॉट स्कोप app_mentions:read, chat:write, reactions:write और channels:history हैं। प्राइवेट चैनलों के लिए groups:history के साथ-साथ message.groups इवेंट के सब्सक्रिप्शन की भी आवश्यकता होती है। Socket Mode के लिए connections:write वाले एक app-level टोकन की आवश्यकता होती है, जो xapp- से शुरू होता है। channels:history उन सार्वजनिक चैनलों में संदेश इतिहास पढ़ता है जिनमें बॉट को जोड़ा गया है, इसलिए बॉट को हर जगह जोड़ने के बजाय केवल उन चैनलों में जोड़ें जहाँ इसकी आवश्यकता है।

एक issue के लिए end-to-end route का परीक्षण

सबसे पहले webhook आता है। Repository में Settings खोलें, फिर Webhooks पर जाएँ, और Add webhook चुनें। Payload URL https://opentag.example.com/github/webhooks है, content type application/json है, और secret वही है जो setup के दौरान generate हुआ था। केवल Issue comments और Pull request review comments को subscribe करें, किसी और को नहीं।

जैसे ही आप save करते हैं, GitHub एक ping delivery भेजता है। Recent Deliveries खोलें और जाँचें कि क्या request सर्वर तक पहुँची है। वहाँ 502 error का मतलब है कि Nginx listener तक नहीं पहुँच पा रहा है; यह एक local समस्या है, GitHub की नहीं।

अब इसका उपयोग करें। एक ऐसा issue खोलें जो किसी bug का वर्णन करता हो और उस पर यह comment करें:

@opentag triage this. Reproduce the report against the current main branch, then reply with the file and function most likely responsible, plus the test you would write first.

क्रमवार देखें कि क्या होना चाहिए। Recent Deliveries में 2xx response के साथ issue_comment delivery record होनी चाहिए। Dispatcher एक run record करता है। Runner उसे claim करता है और heartbeating शुरू करता है। Executor checkout खोलता है और काम शुरू करता है। उत्तर उसी issue thread में एक comment के रूप में आता है। sudo -iu opentag opentag status run को flight के दौरान दिखाता है, ताकि आप अनुमान लगाने के बजाय उसे देख सकें।

पहले वास्तविक run से पहले approvalMode को ask पर set करें। ask mode में run रुक जाता है और state बदलने वाला कोई भी काम करने से पहले व्यक्ति की प्रतीक्षा करता है। auto और autonomous modes भी मौजूद हैं, और वे बाद में उपयोगी होते हैं, जब आप किसी repository पर एक महीने के transcripts पढ़ चुके हों।

Slack की तरफ, वही run channel में /bind owner/repo के साथ शुरू होता है, उसके बाद एक mention आता है। Bot /help, /status, /doctor, /stop और /unbind confirm का भी उत्तर देता है। OPENTAG_SLACK_BINDING_ADMIN_USER_IDS के साथ यह सीमित करें कि कौन bindings बदल सकता है; यह Slack user IDs की एक comma-separated सूची है, क्योंकि binding का अर्थ public channel से आपके सर्वर पर मौजूद checkout की mapping है।

Triage पहला अच्छा route है क्योंकि यह केवल पढ़ता है, लिखता नहीं है, और इसके उत्तर को grade करना आसान है। Review अगला चरण है, जहाँ agent issue के बजाय diff पर comment करता है: a self-hosted pull request review agent यही architecture है जिसे pull requests पर point किया गया है। यदि आप चाहते हैं कि agent काम करते समय आपके अपने systems तक पहुँचे, तो यह MCP servers on a VPS का काम है।

जब एजेंट सबके सामने गलत जानकारी देता है तो क्या होता है?

यह गलत जानकारी देगा। प्रश्न यह है कि इसकी कीमत क्या चुकानी पड़ती है।

किसी सार्वजनिक issue पर गलत उत्तर एक ऐसी टिप्पणी है जो आपके नाम के तहत पोस्ट होती है जिसे आपकी टीम पहचानती है, और पोस्ट होते ही GitHub इसे सब्सक्राइब किए हुए सभी लोगों को ईमेल कर देता है। टिप्पणी को हटाने से ईमेल वापस नहीं आता है। Slack नोटिफिकेशन के साथ भी ऐसा ही है। इस बात की योजना बनाएं कि उत्तर सार्वजनिक रूप से गलत हो सकता है, न कि इस बात की कि वह निजी तौर पर सही होगा।

चार विकल्प नुकसान को सीमित करते हैं, और वे आपके द्वारा लिखे गए किसी भी प्रॉम्प्ट से अधिक महत्वपूर्ण हैं।

  • ask मोड में चलाएं, ताकि एजेंट प्रस्ताव दे, कोई व्यक्ति उसे मंजूरी दे, और एक गलत योजना की कीमत केवल एक क्लिक हो।
  • preparePullRequestBranch को उसके डिफ़ॉल्ट false पर छोड़ दें, ताकि एक खराब रन का सबसे बुरा परिणाम एक गलत शाखा (branch) के बजाय एक गलत टिप्पणी हो।
  • शुरुआत करने के लिए एक रिपॉजिटरी और एक चैनल को बाइंड करें। रनर किसी भी ऐसे रन को अस्वीकार कर देता है जिसका प्रोजेक्ट लक्ष्य उसकी स्थानीय अनुमति सूची (allowlist) से बाहर होता है, इसलिए एक अनबाउंड रिपॉजिटरी एजेंट को अपने अंदर नहीं खींच सकती है।
  • कमेंटिंग टोकन को किसी भी अप्लाई टोकन से अलग रखें, ताकि राइट एक्सेस रद्द करने से ट्राइएज (triage) प्रभावित न हो।

Slack में गलत दिशा में जा रहे रन के लिए एक /stop कमांड है। प्रत्येक रन एक ऑडिट रिकॉर्ड भी छोड़ता है जिसमें वह उल्लेख (mention) होता है जिसने इसे शुरू किया और एजेंट ने क्या किया, जिसे आप बाद में यह पता लगाने के लिए पढ़ते हैं कि गलती कहाँ हुई।

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

Backups, upgrades and the pin

दो paths में सारा डेटा सुरक्षित रहता है: /home/opentag/.config/opentag/config.json और /home/opentag/.local/state/opentag। पहले path में आपके credentials होते हैं, और दूसरे में run history तथा database file होती है। इन दोनों का backup mode 600 के साथ लें और इन्हें server से बाहर सुरक्षित रखें। इनके खोने का अर्थ है tokens और bindings को फिर से बनाना, न कि पूरे server को दोबारा तैयार करना।

Upgrades का अर्थ है version को बढ़ाना और service को restart करना।

sudo npm install -g @opentag/cli@0.9.0
sudo -iu opentag opentag service stop
sudo -iu opentag opentag service start
sudo -iu opentag opentag doctor

@latest को track करने के बजाय version को pin करें। यह software एक live token के साथ आपके repository पर coding agent चलाता है, इसलिए रात भर में publish हुआ कोई भी नया release आपके लिए एक बिना जाँचा गया बदलाव है। Security policy में पुराने versions के लिए कोई backport नहीं दिया जाता है, और सुधार केवल नवीनतम release में ही मिलते हैं। इसलिए, pin करने का अर्थ है कि आप changelog पढ़ें और सोच-समझकर upgrade करें। इसका अर्थ यह नहीं है कि आप हमेशा v0.9.0 पर ही बने रहें। July 2026 तक का इतिहास दिखाता है कि हर महीने कई releases आते हैं, जो इस बात का पर्याप्त कारण है कि प्रत्येक upgrade से पहले release notes को पढ़ा जाए।

FAQ

क्या OpenTag चलाने के लिए मुझे VPS की आवश्यकता है, या लैपटॉप पर्याप्त है?

केवल Slack के लिए एक लैपटॉप पर्याप्त है, क्योंकि Socket Mode एक outbound WebSocket खोलता है और उसे किसी inbound port की आवश्यकता नहीं होती। GitHub के मामले में स्थिति अलग है। Repository webhooks एक inbound HTTP के माध्यम से उस URL पर डिलीवर होते हैं जिसे आप एक बार रजिस्टर करते हैं, इसलिए पता स्थिर रहना चाहिए और आपके सोने के दौरान भी उसे प्रतिक्रिया देनी चाहिए। एक मुफ्त खाते का tunnel host हर बार restart करने पर बदल जाता है, और GitHub पुराने पते पर ही पोस्ट करता रहता है, जो repository के Recent Deliveries टैब में failed entries के रूप में और थ्रेड में चुप्पी के रूप में दिखाई देता है। एक स्थिर DNS नाम और certificate वाला VPS इन दोनों समस्याओं को दूर करता है।

OpenTag को GitHub की कौन सी अनुमतियाँ (permissions) चाहिए?

Only select repositories तक सीमित एक fine-grained personal access token, जिसमें Issues: Read and write और Pull requests: Read and write की अनुमति हो। यह किसी उल्लेख (mention) को पढ़ने और थ्रेड में उत्तर देने के लिए पर्याप्त है। कोड के लिए write access की आवश्यकता तब तक नहीं है जब तक आप preparePullRequestBranch को true पर सेट नहीं करते ताकि OpenTag branches push कर सके। एक अलग githubApplyToken मौजूद है ताकि code-writing token, commenting token से अलग रहे। contents write वाली all-repositories token का उपयोग करने से बचें, क्योंकि उन repositories में टिप्पणी करने वाला कोई भी व्यक्ति ऐसे एजेंट को नियंत्रित कर सकता है जो commit करने में सक्षम हो।

गलत दिशा में जा रहे रन (run) को मैं कैसे रोकूँ?

Slack में इसके लिए एक /stop कमांड है। सर्वर पर, opentag status दिखाता है कि क्या चल रहा है, और opentag service stop daemon को रोक देता है, जो एक रन के बजाय पूरी pipeline को समाप्त कर देता है। इन दोनों की आवश्यकता से बचने के लिए, approvalMode को ask पर सेट करें ताकि रन किसी भी बदलाव से पहले व्यक्ति की पुष्टि के लिए रुक जाए, और preparePullRequestBranch को false पर रखें ताकि एक खराब रन branch बनाने के बजाय केवल एक टिप्पणी (comment) उत्पन्न करे।

मेरा webhook 502 क्यों लौटा रहा है जबकि थ्रेड शांत है?

502 त्रुटि nginx से आती है, OpenTag से नहीं, और इसका अर्थ है कि proxy listener तक नहीं पहुँच सका। /var/log/nginx/error.log से connect() failed (111: Connection refused) while connecting to upstream दिखाई देगा। या तो listener बंद है, या वह उस port पर नहीं है जिसे proxy_pass लाइन में निर्दिष्ट किया गया है। sudo ss -tlnp चलाएँ और पुष्टि करें कि GitHub के लिए 127.0.0.1:3050 और Slack के लिए 127.0.0.1:3040 पर कुछ listen कर रहा है, फिर bindings और executors के लिए opentag doctor चलाएँ।

#opentag#ai-agents#slack#github#webhooks#सेल्फ़-होस्टिंग