Open Connector को खुद कैसे होस्ट करें

AI एजेंट के लिए Open Connector क्या करता है

Open Connector को स्वयं होस्ट करने से आपके AI एजेंट और उनके द्वारा कॉल किए जाने वाले प्रत्येक SaaS (सॉफ्टवेयर एज़ ए सर्विस) API के बीच एक ऑथेंटिकेशन गेटवे स्थापित हो जाता है, जिससे एजेंट के पास कभी भी प्रोवाइडर टोकन नहीं रहता है। यह OOMOL Lab का एक ओपन सोर्स गेटवे है, जो Apache 2.0 लाइसेंस के अंतर्गत आता है। यह एक कंटेनर के रूप में चलता है, अपनी स्थिति को एक एकल SQLite फ़ाइल में रखता है, और प्रोवाइडर क्रियाओं को HTTP और MCP (मॉडल कॉन्टेक्स्ट प्रोटोकॉल) के माध्यम से एक्सपोज़ करता है।

समस्या दूसरी इंटीग्रेशन के साथ शुरू होती है। प्रत्येक प्रोवाइडर का अपना OAuth (ओपन ऑथराइजेशन) फ्लो, अपना रिफ्रेश टोकन लाइफटाइम और अपने स्कोप नाम होते हैं। एक एजेंट में पांच प्रोवाइडर्स को मैन्युअल रूप से जोड़ने का मतलब है पांच रीडायरेक्ट हैंडलर, पांच क्रेडेंशियल स्टोर, और पांच रिफ्रेश लूप, जिन्हें टोकन समाप्त होने से पहले चलना चाहिए। लगभग कोई भी यह कोड नहीं लिखता है। वे प्रति सर्विस एक लॉन्ग-लाइव्ड पर्सनल एक्सेस टोकन बनाते हैं और उसे एजेंट कॉन्फ़िगरेशन, एनवायरनमेंट फ़ाइल, या प्रॉम्प्ट में पेस्ट कर देते हैं। वह टोकन फिर एजेंट द्वारा चलाए जाने वाले प्रत्येक टूल द्वारा पढ़ा जा सकता है, और यह ट्रांसक्रिप्ट में आ जाता है, जो कि AI एजेंटों से सीक्रेट्स को सुरक्षित रखना में वर्णित विफलता है।

एक ऑथेंटिकेशन गेटवे क्रेडेंशियल को दो भागों में विभाजित करता है। गेटवे प्रोवाइडर क्रेडेंशियल को स्टोर करता है और OAuth फ्लो को चलाता है। एजेंट को एक रनटाइम टोकन मिलता है जो केवल गेटवे के विरुद्ध मान्य होता है। जब एजेंट कोई क्रिया कॉल करता है, तो गेटवे स्टोर किए गए क्रेडेंशियल को लोड करता है, उसे सर्वर साइड पर आउटबाउंड रिक्वेस्ट में इंजेक्ट करता है, और केवल रिस्पॉन्स बॉडी लौटाता है। एजेंट को कभी भी प्रोवाइडर एक्सेस टोकन प्राप्त नहीं होता है, इसलिए लीक हुई एजेंट ट्रांसक्रिप्ट की कीमत आपको आपके GitHub अकाउंट के बजाय केवल एक रिवोकेबल रनटाइम टोकन चुकानी पड़ती है।

कैटलॉग 1,000 से अधिक प्रोवाइडर्स और 10,000 से अधिक प्रीबिल्ट क्रियाओं का विज्ञापन करता है, जो प्रोजेक्ट का अपना आंकड़ा है और जिसे आप बाहर से सत्यापित नहीं कर सकते हैं। आप जो सत्यापित कर सकते हैं वह इसका स्वरूप है: प्रति क्रिया एक HTTP एंडपॉइंट, प्रति प्रोवाइडर एक स्टोर्ड कनेक्शन, और प्रति एजेंट एक टोकन।

Open Connector को स्वयं होस्ट क्यों करें, न कि किसी होस्टेड कनेक्टर सेवा का उपयोग करें

एक होस्टेड कनेक्टर सेवा वही काम करती है, और यह आपके द्वारा कनेक्ट किए गए प्रत्येक प्रदाता के लिए रिफ्रेश टोकन को सुरक्षित रखती है। Google या GitHub के लिए एक रिफ्रेश टोकन आपके मेल और रिपॉजिटरी के लिए एक दीर्घकालिक कुंजी है, और यह आमतौर पर पासवर्ड बदलने के बाद भी सक्रिय रहता है। उनका उल्लंघन आपका उल्लंघन बन जाता है। स्वयं होस्ट करने से वे रिकॉर्ड एक ऐसी मशीन पर SQLite में चले जाते हैं जिसे आप किराए पर लेते हैं और प्रबंधित करते हैं, जो एक ऐसी कुंजी के साथ सुरक्षित होती है जो कभी भी आपके बॉक्स से बाहर नहीं जाती है।

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

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

Open Connector अभी नया है। रिपॉजिटरी पहली बार 29 June 2026 को दिखाई दी थी, और 1 August 2026 तक सबसे नया टैग किया गया रिलीज़ v1.3.3 है, जिसे 30 July 2026 को प्रकाशित किया गया था और इसमें latest टैग भी शामिल है। रजिस्ट्री एक tip टैग भी प्रकाशित करती है, जिसे main पर सबसे नए कमिट से बनाया गया है।

इतने नए प्रोजेक्ट पर मूविंग टैग अक्सर बदलते रहते हैं। एक docker compose pull जो दो रिलीज़ आगे बढ़ जाता है, वह उस एंडपॉइंट को बदल सकता है जिस पर आपका एजेंट निर्भर करता है, और आप पूरी शाम इसे एजेंट की समस्या मानकर डीबग करने में बिता देंगे। इमेज को एक रिलीज़ टैग पर पिन करें, और रिलीज़ नोट्स पढ़ने के बाद, जब आप चाहें तब अपग्रेड करें।

अपने VPS पर TLS के पीछे Open Connector को डिप्लॉय करें

कंटेनर शुरू करने से पहले आपको इनकी आवश्यकता है:

• Ubuntu 24.04 या इसके समान किसी सिस्टम पर Docker और Compose प्लगइन
• एक होस्टनेम जिसका A रिकॉर्ड इस VPS को पॉइंट करता हो, उदाहरण के लिए connect.example.com
• एक रिवर्स प्रॉक्सी जो उस होस्टनेम के लिए पहले से ही TLS (transport layer security) को टर्मिनेट करती हो
• दो रैंडम सीक्रेट्स, जिन्हें नीचे जनरेट किया गया है

कई Docker Compose ऐप्स के लिए Traefik रिवर्स प्रॉक्सी गाइड प्रॉक्सी वाले हिस्से को कवर करती है। एक सिंगल ऐप के लिए शुरू से अंत तक सर्टिफिकेट सेटअप की प्रक्रिया Docker और HTTPS के साथ VPS पर n8n गाइड में दी गई है।

सबसे पहले सीक्रेट्स जनरेट करें। एन्क्रिप्शन की (encryption key) स्टोर किए गए क्रेडेंशियल्स को सुरक्षित करती है। एडमिन टोकन वेब कंसोल और पूरे /api इंटरफेस को सुरक्षित रखता है। इनमें से किसी का भी कोई डिफॉल्ट मान नहीं है, और इनके बिना भी रनटाइम शुरू हो जाता है।

mkdir -p ~/open-connector && cd ~/open-connector
umask 077
printf 'OOMOL_CONNECT_ENCRYPTION_KEY=%s\n' "$(openssl rand -base64 32)" > .env
printf 'OOMOL_CONNECT_ADMIN_TOKEN=%s\n' "$(openssl rand -base64 32)" >> .env
chmod 600 .env

दोनों वैल्यूज को अभी अपने पासवर्ड मैनेजर में कॉपी कर लें, पहली बार शुरू करने से पहले। एन्क्रिप्शन की का कोई रिकवरी पाथ नहीं है, और इसका कारण नीचे दी गई विफलता सूची में है।

अब compose.yaml तैयार करें। यह अपस्ट्रीम उदाहरण से दो जगहों पर अलग है, और दोनों महत्वपूर्ण हैं।

services:
  connector:
    image: ghcr.io/oomol-lab/open-connector:v1.3.3
    restart: unless-stopped
    ports:
      - "127.0.0.1:3000:3000"
    volumes:
      - connector-data:/app/data
    environment:
      OOMOL_CONNECT_DATA_DIR: /app/data
      OOMOL_CONNECT_ORIGIN: "https://connect.example.com"
      OOMOL_CONNECT_ENCRYPTION_KEY: "${OOMOL_CONNECT_ENCRYPTION_KEY:?set this in .env}"
      OOMOL_CONNECT_ADMIN_TOKEN: "${OOMOL_CONNECT_ADMIN_TOKEN:?set this in .env}"

volumes:
  connector-data:

पहला बदलाव latest के बजाय पिन किया गया टैग है। दूसरा बदलाव पोर्ट है। अपस्ट्रीम फ़ाइल 3000:3000 को पब्लिश करती है, जो होस्ट के हर इंटरफेस पर बाइंड होती है। Docker अपने पब्लिश किए गए पोर्ट्स को NAT (network address translation) टेबल में तब लिखता है जब ufw फ़िल्टर चेन पैकेट को देखती भी नहीं है, इसलिए ufw deny 3000 उस पोर्ट को बंद नहीं करता है, यह वह ट्रैप है जिसका वर्णन Docker पोर्ट्स ufw को क्यों बायपास करते हैं में किया गया है। 127.0.0.1:3000:3000 लिखने से यह केवल लूपबैक इंटरफेस पर पब्लिश होता है, और आपका रिवर्स प्रॉक्सी उसी होस्ट से कनेक्ट होता है।

:? प्रत्येक वेरिएबल को आवश्यक के रूप में चिह्नित करता है, इसलिए जब .env गायब होता है तो स्टैक शुरू होने से मना कर देता है, बजाय इसके कि वह बिना एन्क्रिप्शन के क्रेडेंशियल्स के साथ शुरू हो जाए। वैल्यूज को compose फ़ाइल के बजाय .env में रखना Docker Compose env फ़ाइलें और सीक्रेट्स का पैटर्न है।

docker compose up -d
docker compose logs -n 30 connector
curl -s http://127.0.0.1:3000/health
sudo ss -tlnp | grep 3000

रनटाइम शुरू होने के बाद /health, { "ok": true } का उत्तर देता है। ss को 127.0.0.1:3000 प्रिंट करना चाहिए। यदि कोई लाइन 0.0.0.0:3000 पढ़ती है, तो इसका मतलब है कि पोर्ट मैपिंग अभी भी अपस्ट्रीम वाली है, और गेटवे सीधे पूरे इंटरनेट को उत्तर दे रहा है। हेल्थ चेक पर 'Connection refused' का मतलब है कि कंटेनर अभी लिसन नहीं कर रहा है, इसलिए प्रॉक्सी को छूने से पहले लॉग्स पढ़ें।

    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.connector.rule=Host(`connect.example.com`)"
      - "traefik.http.routers.connector.entrypoints=websecure"
      - "traefik.http.routers.connector.tls.certresolver=le"
      - "traefik.http.services.connector.loadbalancer.server.port=3000"

OAuth के लिए वास्तविक होस्टनेम की आवश्यकता क्यों है

OOMOL_CONNECT_ORIGIN वह सेटिंग है जिसे लोग छोड़ देते हैं, और इसे छोड़ने से OAuth इस तरह से विफल हो जाता है कि यह किसी प्रदाता की खराबी जैसा लगता है। रनटाइम उस ऑरिजिन से अपना रीडायरेक्ट URI बनाता है, जो <origin>/oauth/callback के रूप में होता है। यदि इसे सेट नहीं किया जाता है, तो ऑरिजिन डिफ़ॉल्ट रूप से http://localhost:3000 हो जाता है, इसलिए रनटाइम प्रदाता को http://localhost:3000/oauth/callback का रीडायरेक्ट URI भेजता है जबकि आपके OAuth ऐप में https://connect.example.com/oauth/callback पंजीकृत होता है। ये दोनों स्ट्रिंग अलग-अलग हैं, इसलिए GitHub यह उत्तर देता है:

The redirect_uri MUST match the registered callback URL for this application.

एक OAuth प्रदाता ब्राउज़र को उस URI पर वापस रीडायरेक्ट करता है, जिसका अर्थ है कि यह एक ऐसा पता होना चाहिए जिसे बाहरी दुनिया एक्सेस कर सके, और प्रदाता localhost को छोड़कर किसी भी चीज़ के लिए सादे http:// को अस्वीकार कर देते हैं। यही एकमात्र कारण है कि इस डिप्लॉयमेंट को एक होस्टनेम और एक सर्टिफिकेट की आवश्यकता है। पहली बार शुरू करने से पहले ऑरिजिन सेट करें, क्योंकि यह मान स्टार्टअप पर पढ़ा जाता है: .env या compose.yaml को संपादित करने के बाद, इसे लागू करने के लिए फिर से docker compose up -d चलाएं।

अपने पहले प्रदाता को OAuth के माध्यम से कनेक्ट करें

सबसे पहले प्रदाता के पास OAuth ऐप बनाएं। GitHub पर पथ Settings है, फिर Developer settings, फिर OAuth Apps, और फिर New OAuth App है। ऑथराइजेशन कॉलबैक URL को https://connect.example.com/oauth/callback पर सेट करें। क्लाइंट ID और क्लाइंट secret को सुरक्षित रखें।

प्रत्येक /api कॉल में एडमिन टोकन होता है, इसलिए इसे शेल सत्र के लिए एक बार एक्सपोर्ट करें।

export ADMIN_TOKEN='paste-the-admin-token'
curl -s https://connect.example.com/api/oauth/configs \
  -H "authorization: Bearer $ADMIN_TOKEN"

वह लिस्टिंग उस रीडायरेक्ट URI को दिखाती है जिसकी अपेक्षा रनटाइम प्रत्येक प्रदाता के लिए करता है, जो इसे यह जांचने का सबसे तेज़ तरीका बनाता है कि आपका ओरिजिन प्रभावी हुआ है या नहीं। यदि यह अभी भी localhost दिखाता है, तो कंटेनर पुराने मान के साथ चल रहा है और OAuth फ्लो अंतिम चरण में विफल हो जाएगा।

क्लाइंट क्रेडेंशियल्स को स्टोर करें, फिर एक ऑथराइजेशन शुरू करें।

curl -s -X PUT https://connect.example.com/api/oauth/configs/github \
  -H "authorization: Bearer $ADMIN_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"clientId":"...","clientSecret":"..."}'

curl -s -X POST https://connect.example.com/api/oauth/authorizations \
  -H "authorization: Bearer $ADMIN_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"service":"github"}'

दूसरी कॉल एक authorizationUrl लौटाती है। इसे ब्राउज़र में खोलें, स्कोप्स को स्वीकृत करें, और प्रदाता ब्राउज़र को वापस /oauth/callback पर भेज देता है, जहाँ रनटाइम कोड का आदान-प्रदान करता है और क्रेडेंशियल को स्टोर करता है। आपके ओरिजिन पर वेब कंसोल उसी एडमिन टोकन के पीछे, एक फॉर्म के साथ इन्हीं चरणों का पालन करता है। जो प्रदाता सादे API की (API key) का उपयोग करते हैं, वे इस पूरी प्रक्रिया को छोड़ देते हैं: PUT /api/connections/<service> के साथ {"authType":"api_key","values":{"apiKey":"..."}} सीधे की (key) को स्टोर करता है।

प्रत्येक एजेंट को एक रनटाइम टोकन दें, क्रेडेंशियल कभी न दें

एजेंट एक रनटाइम टोकन के साथ गेटवे पर प्रमाणित होता है, जिसे admin API जारी करता है।

curl -s -X POST https://connect.example.com/api/runtime-tokens \
  -H "authorization: Bearer $ADMIN_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"name":"research-agent"}'

प्रतिक्रिया में एक टोकन होता है जो oct_ से शुरू होता है। प्रति एजेंट एक टोकन जारी करें और उसका नाम उस एजेंट के नाम पर रखें, क्योंकि जिस टोकन की पहचान आप नहीं कर सकते उसे रद्द करने का अर्थ उन सभी को रद्द करना है। इसके बाद एजेंट सामान्य HTTP पर क्रियाएं (actions) कॉल करता है।

curl -s -X POST https://connect.example.com/v1/actions/github.get_current_user \
  -H "authorization: Bearer oct_..." \
  -H 'content-type: application/json' \
  -d '{"input":{}}'

एक सफल उत्तर एक लिफाफा (envelope) है जिसका success फ़ील्ड true है, जिसमें प्रदाता पेलोड data के अंतर्गत होता है। GitHub टोकन उस प्रतिक्रिया में कहीं भी नहीं होता है। MCP क्लाइंट के लिए, इसे उसी bearer हेडर के साथ https://connect.example.com/mcp पर इंगित करें, और गेटवे प्रति API एक टूल के बजाय search_actions और execute_action जैसे डिस्कवरी टूल प्रदान करता है, जो एजेंट की टूल सूची को छोटा रखता है। VPS पर MCP सर्वर चलाना उस वायरिंग के क्लाइंट भाग को कवर करता है।

इसे समाप्त करने से पहले एक और जांच करें। authorization हेडर को हटाकर एक्शन कॉल को दोहराएं। प्रोजेक्ट का अपना quickstart बिना किसी bearer के /v1 को कॉल करता है, इसलिए बिना रनटाइम ऑथ कॉन्फ़िगर किए किया गया इंस्टॉलेशन उन सभी के लिए क्रियाएं निष्पादित करेगा जो पोर्ट तक पहुंच सकते हैं। यदि आपकी बिना प्रमाणीकरण वाली कॉल सफल हो जाती है, तो आपके पास दो विकल्प हैं: रनटाइम टोकन कॉन्फ़िगर करें और पुष्टि करें कि अब अनाम कॉल विफल हो रही है, या रिवर्स प्रॉक्सी पर /api, /v1 और /mcp को उन पतों तक सीमित करें जहां से आपके एजेंट आते हैं। केवल /oauth/callback को दुनिया के लिए खुला रहना चाहिए, क्योंकि यह वह एकमात्र पथ है जिसकी प्रदाता के ब्राउज़र रीडायरेक्ट को आवश्यकता होती है।

एजेंट की आवश्यकता के अनुसार एक्शन लिस्ट को सीमित करना

हजारों प्रोवाइडर्स वाला एक गेटवे लैंग्वेज मॉडल को देने के लिए बहुत बड़ा एक्सपोज़र सरफेस है। दो कंट्रोल्स इसे सीमित करते हैं।

OOMOL_CONNECT_ALLOWED_ACTIONS एक कॉमा-सेपरेटेड अलाउलिस्ट लेता है और service.* तथा * को समझता है। OOMOL_CONNECT_BLOCKED_ACTIONS डेनिलिस्ट है, और डेनिलिस्ट प्रभावी रहती है। अलाउलिस्ट को github.get_current_user,github.list_issues पर सेट करने का अर्थ है कि एजेंट चाहे कुछ भी मांगे, बाकी सभी एक्शन्स को अस्वीकार कर दिया जाएगा; यही एक गलती और एक इंसिडेंट के बीच का अंतर है। रनटाइम टोकन्स ग्लोबल रूल्स के ऊपर अपने स्वयं के एक्शन रूल्स रखते हैं, और उनकी allowedProxies लिस्ट खाली शुरू होती है, इसलिए जब तक आप अनुमति नहीं देते, POST /v1/proxy/:service को अस्वीकार कर दिया जाता है। वह प्रॉक्सी एंडपॉइंट आपके क्रेडेंशियल के साथ एक रॉ रिक्वेस्ट को प्रोवाइडर को फॉरवर्ड करता है, इसलिए इसे खाली छोड़ दें जब तक कि किसी विशिष्ट एजेंट को इसकी आवश्यकता न हो।

OOMOL_CONNECT_ALLOW_PRIVATE_NETWORK डिफ़ॉल्ट रूप से false पर सेट होता है, जो एक सेल्फ-होस्टेड प्रोवाइडर कनेक्शन को 169.254.169.254 पर क्लाउड मेटाडेटा सर्विस या उसी नेटवर्क पर आपके डेटाबेस जैसे प्राइवेट एड्रेस की ओर इशारा करने से रोकता है। इसे ऑफ रखें। इसे केवल उस प्रोवाइडर के लिए ऑन करें जिसे आप स्वयं होस्ट करते हैं।

उन सभी टोकन को रखने वाले बॉक्स का बैकअप लें

दो चीजें मायने रखती हैं, और एक-दूसरे के बिना दोनों बेकार हैं। connector-data वॉल्यूम के अंदर /app/data/connect.sqlite पर स्थित डेटाबेस में सीलबंद क्रेडेंशियल्स होते हैं। .env में मौजूद एन्क्रिप्शन की (encryption key) उन्हें अनसील करती है। की (key) के बिना वॉल्यूम का बैकअप कुछ भी रिस्टोर नहीं करता है, और वॉल्यूम के बिना की (key) कुछ भी रिस्टोर नहीं करती है, इसलिए की (key) को आपके पासवर्ड मैनेजर में होना चाहिए और वॉल्यूम को आपके सामान्य बैकअप रोटेशन में होना चाहिए।

SQLite फ़ाइल को कॉपी करते समय कंटेनर को रोक दें, क्योंकि राइट ऑपरेशन के दौरान ली गई कॉपी एक करप्ट डेटाबेस के रूप में रिस्टोर हो सकती है।

docker volume ls | grep connector-data
docker compose stop connector
docker run --rm -v open-connector_connector-data:/data -v "$PWD":/backup alpine \
  tar czf /backup/connector-data.tgz -C /data .
docker compose start connector

वॉल्यूम का नाम आपका प्रोजेक्ट डायरेक्टरी प्लस _connector-data है, इसीलिए पहला कमांड वहां दिया गया है: तीसरे कमांड में वास्तविक नाम पेस्ट करें। VPS से restic बैकअप का उपयोग करके आर्काइव को VPS से बाहर भेजें, जो इसे बाहर जाने से पहले एन्क्रिप्ट करता है, क्योंकि वह आर्काइव क्रेडेंशियल स्टोर है।

रनटाइम हालिया एक्शन रन को ऑडिट रिकॉर्ड के रूप में रखता है, डिफ़ॉल्ट रूप से 5,000 रिकॉर्ड, ताकि कंसोल आपको बता सके कि किस एजेंट ने क्या और कब रन किया। जब कोई एजेंट अजीब व्यवहार करे तो वह लॉग सबसे पहले पढ़ने वाली चीज है। Uptime Kuma स्टेटस पेज को भी https://connect.example.com/health पर पॉइंट करें। जब गेटवे जवाब देना बंद कर देता है, तो एजेंट भ्रमित करने वाले तरीकों से विफल हो जाते हैं, और यह जानना कि गेटवे डाउन है, एजेंट आउटपुट को पढ़ने में लगने वाला एक घंटा बचा लेता है।

क्या विफल होता है, और आपको क्या संदेश दिखाई देगा

redirect_uri_mismatch प्रदाता पर। ओरिजिन और पंजीकृत कॉलबैक URL अलग-अलग हैं। /api/oauth/configs से सटीक स्ट्रिंग की तुलना प्रदाता की ऐप सेटिंग्स से करें, जिसमें https की तुलना http से करना और किसी भी ट्रेलिंग स्लैश की जांच करना शामिल है।

प्रत्येक /api कॉल 401 लौटाता है। एडमिन टोकन हेडर गायब है या उसकी वर्तनी गलत है। हेडर Authorization: Bearer <token> है, और वेब कंसोल उसी टोकन के लिए पूछता है।

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

docker compose cp connector:/app/data/connect.sqlite /tmp/connect.sqlite
grep -c 'github_pat_' /tmp/connect.sqlite
shred -u /tmp/connect.sqlite

0 से अधिक की संख्या का अर्थ है कि की (key) प्रभावी नहीं है, इसलिए जांचें कि .env उसी डायरेक्टरी में है जहाँ compose.yaml है और docker compose config वह मान दिखाता है। की सेट होने के बाद, वही खोज 0 लौटाती है, क्योंकि रिकॉर्ड AES-256-GCM (एडवांस्ड एन्क्रिप्शन स्टैंडर्ड, 256-बिट की, गैलोज़/काउंटर मोड) के साथ सील किया गया है।

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

एजेंट को एक ऐसी क्रिया का नाम लेने वाली त्रुटि मिलती है जिसे वह कैटलॉग में देख सकता है। डिस्कवरी और निष्पादन अलग-अलग हैं। एक क्रिया search_actions में दिखाई दे सकती है और फिर भी OOMOL_CONNECT_ALLOWED_ACTIONS द्वारा, डेनलिस्ट द्वारा, या उस रनटाइम टोकन के अपने नियमों द्वारा अस्वीकार की जा सकती है।

अपग्रेड। वॉल्यूम का बैकअप लें, इमेज टैग को नई रिलीज़ में संपादित करें, फिर docker compose pull && docker compose up -d करें। माइग्रेशन लाइन के लिए docker compose logs -n 50 connector पर नज़र रखें, और उस पर दोबारा भरोसा करने से पहले हेल्थ चेक और एक वास्तविक क्रिया को फिर से चलाएं। रोल बैक करने का अर्थ है पुराने टैग को वापस लगाना, जो केवल इसलिए काम करता है क्योंकि आपने इसे पिन किया था।

FAQ

क्या Open Connector को सेल्फ-होस्ट करने के लिए मुझे पब्लिक डोमेन की आवश्यकता है?

जो प्रोवाइडर API key का उपयोग करते हैं, उनके लिए नहीं: 127.0.0.1 पर एक गेटवे पर्याप्त है। OAuth के लिए, व्यवहार में इसकी आवश्यकता होती है। प्रोवाइडर ब्राउज़र को आपके callback URL पर रीडायरेक्ट करता है, इसलिए उस URL को पब्लिक इंटरनेट से रिज़ॉल्व होना चाहिए, और प्रोवाइडर localhost के बाहर सादे http:// को स्वीकार करने से मना कर देते हैं। पहली बार शुरू करने से पहले OOMOL_CONNECT_ORIGIN को अपने https:// होस्टनेम पर सेट करें, और प्रोवाइडर के OAuth ऐप में <origin>/oauth/callback को रजिस्टर करें।

यदि मैं Open Connector एन्क्रिप्शन की (key) खो दूँ तो क्या होगा?

संग्रहीत क्रेडेंशियल्स को डिक्रिप्ट नहीं किया जा सकता है, और इसका कोई रिकवरी विकल्प नहीं है। इस की (key) को जानबूझकर कभी भी डेटा के साथ स्टोर नहीं किया जाता है, ताकि डेटाबेस रखने वाला कोई भी व्यक्ति इसे न पढ़ सके, आप भी नहीं। आपका एकमात्र विकल्प एक नई की (key) सेट करना और प्रत्येक प्रोवाइडर को फिर से कनेक्ट करना है। की (key) को एक पासवर्ड मैनेजर में रखें और डेटाबेस को अपने बैकअप रोटेशन में शामिल करें, क्योंकि रिस्टोर करने के लिए दोनों की आवश्यकता होती है।

क्या मेरा AI एजेंट प्रोवाइडर एक्सेस टोकन देख सकता है?

जब यह गेटवे के माध्यम से कॉल करता है, तब नहीं। एजेंट oct_ से शुरू होने वाले रनटाइम टोकन के साथ ऑथेंटिकेट होता है, और गेटवे सर्वर पर आउटबाउंड रिक्वेस्ट में प्रोवाइडर क्रेडेंशियल इंजेक्ट करता है, और केवल रिस्पॉन्स वापस करता है। दो चीजें इस सुरक्षा को तोड़ती हैं: /v1/proxy/:service एंडपॉइंट, जो आपके क्रेडेंशियल के साथ रॉ रिक्वेस्ट को फॉरवर्ड करता है और जिसके ग्रांट्स खाली शुरू होते हैं, और स्वयं एजेंट में API key पेस्ट करना, जो गेटवे को पूरी तरह से छोड़ देता है।

क्या गेटवे पब्लिक इंटरनेट से एक्सेस करने योग्य होना चाहिए?

केवल /oauth/callback को एक्सेस करने योग्य होना चाहिए। कंटेनर पोर्ट को 127.0.0.1 पर पब्लिश करें ताकि Docker के NAT रूल्स इसे आपके फायरवॉल के बाहर एक्सपोज़ न कर सकें, और रिवर्स प्रॉक्सी को सामने रखें। फिर बिना किसी authorization हेडर के एक एक्शन कॉल का परीक्षण करें। यदि यह सफल होता है, तो प्रॉक्सी पर /api, /v1 और /mcp को उन एड्रेस तक सीमित करें जिनका उपयोग आपके एजेंट करते हैं, जब तक कि केवल ऑथेंटिकेटेड कॉल्स ही काम न करें।

क्या Open Connector प्रोडक्शन उपयोग के लिए तैयार है?

यह Apache 2.0 लाइसेंस प्राप्त है और तेजी से विकसित हो रहा है: रिपॉजिटरी 29 June 2026 को दिखाई दी और v1.3.3 को 30 July 2026 को शिप किया गया, इसलिए इस गाइड में प्रत्येक वर्ज़न नंबर को 1 August 2026 के स्नैपशॉट के रूप में मानें। इसे हमेशा एक रिलीज़ टैग पर पिन करके चलाएं, कभी भी latest या tip पर नहीं, प्रत्येक अपग्रेड से पहले रिलीज़ नोट्स पढ़ें, और एक वॉल्यूम बैकअप रखें जिसे आपने एक बार रिस्टोर करके देखा हो। डिज़ाइन आपके अपने सर्वर के लिए सही है, और जोखिम वर्ज़न में होने वाले बदलाव हैं, न कि आर्किटेक्चर।