Open Connector को self-host कैसे करें: गाइड

AI agent के लिए Open Connector क्या करता है

Open Connector को self-host करने से आपके AI agents और उनके द्वारा कॉल किए जाने वाले हर software as a service (SaaS) API के बीच एक auth gateway आ जाता है, जिससे agent के पास कभी भी provider token नहीं रहता। यह OOMOL Lab का एक open source gateway है, जो Apache 2.0 license के तहत उपलब्ध है। यह एक container के रूप में चलता है, अपनी state को एक single SQLite file में रखता है, और provider actions को HTTP तथा MCP (model context protocol) के माध्यम से expose करता है।

परेशानी दूसरी integration के समय शुरू होती है। हर provider का अपना OAuth (open authorization) flow, अपने refresh token की lifetime, और अपने scope names होते हैं। एक agent में हाथ से पाँच providers को जोड़ने का मतलब है पाँच redirect handlers, पाँच credential stores, और पाँच ऐसे refresh loops जिन्हें token expire होने से पहले चलना चाहिए। लगभग कोई भी यह code नहीं लिखता। वे हर service के लिए एक long-lived personal access token बनाते हैं और उसे agent config, environment file, या खुद prompt में paste कर देते हैं। वह token फिर agent द्वारा चलाए जाने वाले हर tool के लिए readable होता है, और वह transcript में चला जाता है, जो कि वह विफलता है जिसका वर्णन keeping secrets out of AI agents में किया गया है।

एक auth gateway credential को दो भागों में बाँट देता है। Gateway provider credential को store करता है और OAuth flow चलाता है। Agent को एक runtime token मिलता है जो केवल gateway के विरुद्ध valid होता है। जब agent कोई action call करता है, तो gateway stored credential को load करता है, उसे server side पर outbound request में inject करता है, और केवल response body वापस करता है। Agent को कभी भी provider access token प्राप्त नहीं होता, इसलिए एक leaked agent transcript की कीमत आपको आपके GitHub account के बजाय केवल एक revocable runtime token चुकानी पड़ती है।

Catalog में 1,000 से अधिक providers और 10,000 prebuilt actions का विज्ञापन दिया गया है, जो project के अपने आँकड़े हैं और ऐसी चीज़ नहीं है जिसे आप बाहर से verify कर सकें। आप जो verify कर सकते हैं वह है इसका ढाँचा: प्रति action एक HTTP endpoint, प्रति provider एक stored connection, और प्रति agent एक token। यदि इसका agent side अभी नया है और tool call या MCP server जैसे शब्द अभी तक स्थिर नहीं हुए हैं, तो how to learn AI agents from scratch में दिया गया staged path उस loop, tools, और safety habits को बनाता है जिन्हें इस तरह का gateway पहले से मौजूद मानकर चलता है।

Hosted connector service के बजाय Open Connector को self-host क्यों करें

एक hosted connector service वही काम करती है, और यह आपके द्वारा कनेक्ट किए गए प्रत्येक provider के लिए refresh tokens को सुरक्षित रखती है। Google या GitHub के लिए एक refresh token आपके मेल और repositories के लिए एक long-lived key होती है, और यह आमतौर पर password बदलने के बाद भी बनी रहती है। यदि उनका सिस्टम breach होता है, तो यह आपका breach बन जाता है। Self-hosting इन records को आपके द्वारा किराए पर लिए गए और प्रबंधित किए जाने वाले मशीन पर SQLite में स्थानांतरित कर देती है, जिसे एक ऐसी key से सील किया जाता है जो कभी भी आपके बॉक्स से बाहर नहीं जाती।

शुरू करने से पहले इसकी लागत को स्पष्ट रूप से समझें। यह VPS आपके द्वारा चलाए जाने वाले सबसे महत्वपूर्ण सर्वर में बदल जाता है। इसमें एक ही फाइल में दर्जनों सेवाओं के लिए working credentials होते हैं, इसलिए इसे वही सुरक्षा दी जानी चाहिए जो आप एक password manager host को देते हैं: एक firewall जो केवल 443 port को expose करे, कोई shared login न हो, एक ऐसा backup जिसे आपने वास्तव में एक बार restore करके देखा हो, और इसके बंद होने पर एक alert। यदि आप अपना password vault इस बॉक्स पर नहीं रखेंगे, तो connector को भी इस पर न रखें।

किसी भी चीज़ को install करने से पहले एक version को pin करें

Open Connector अभी नया है। यह repository पहली बार 29 June 2026 को दिखाई दी थी, और 1 August 2026 तक सबसे नया tagged release v1.3.3 है, जिसे 30 July 2026 को publish किया गया था और इसमें latest tag भी शामिल है। Registry एक tip tag भी publish करती है, जिसे main पर सबसे नए commit से build किया गया है।

इतने नए project पर moving tags अक्सर बदलते रहते हैं। एक docker compose pull जो दो releases के बीच jump करता है, वह उस endpoint को बदल सकता है जिस पर आपका agent निर्भर करता है, और आप पूरी शाम इसे agent की समस्या मानकर debug करने में बिता देंगे। Image को एक release tag पर pin करें, और release notes पढ़ने के बाद, जब आप चाहें तब upgrade करें।

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

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

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

कई 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 (नेटवर्क एड्रेस ट्रांसलेशन) टेबल में तब लिखता है जब ufw फ़िल्टर चेन पैकेट को देखती भी नहीं है, इसलिए ufw deny 3000 उस पोर्ट को बंद नहीं करता है, जो Docker पोर्ट्स ufw को बायपास क्यों करते हैं में वर्णित एक ट्रैप है। 127.0.0.1:3000:3000 लिखने से यह केवल लूपबैक इंटरफेस पर पब्लिश होता है, और आपकी रिवर्स प्रॉक्सी उसी होस्ट से कनेक्ट होती है।

:? प्रत्येक वेरिएबल को आवश्यक के रूप में चिह्नित करता है, इसलिए जब .env गायब होता है तो स्टैक शुरू होने से मना कर देता है, बजाय इसके कि वह बिना एन्क्रिप्टेड क्रेडेंशियल्स के शुरू हो जाए। मानों को कंपोज़ फ़ाइल के बजाय .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 के लिए वास्तविक hostname की आवश्यकता क्यों है

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

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

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

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

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

प्रत्येक /api कॉल में admin token होता है, इसलिए इसे shell session के लिए एक बार export करें।

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

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

client credentials को स्टोर करें, फिर authorization शुरू करें।

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 लौटाती है। इसे ब्राउज़र में खोलें, scopes को स्वीकार करें, और प्रदाता ब्राउज़र को वापस /oauth/callback पर भेज देगा, जहाँ runtime code का आदान-प्रदान करता है और credential को स्टोर कर लेता है। आपके origin पर मौजूद web console उसी admin token के पीछे, एक फॉर्म के माध्यम से इन्हीं चरणों का पालन करता है। जो प्रदाता सादे API key का उपयोग करते हैं, वे इन सभी चरणों को छोड़ देते हैं: PUT /api/connections/<service> के साथ {"authType":"api_key","values":{"apiKey":"..."}} का उपयोग करके key को सीधे स्टोर किया जाता है।

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

एजेंट एक रनटाइम टोकन के साथ गेटवे पर प्रमाणित होता है, जिसे एडमिन 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 क्लाइंट के लिए, इसे उसी बेयरर हेडर के साथ https://connect.example.com/mcp पर पॉइंट करें, और गेटवे प्रत्येक API के लिए एक टूल के बजाय search_actions और execute_action जैसे डिस्कवरी टूल प्रदान करता है, जिससे एजेंट की टूल सूची छोटी रहती है। VPS पर MCP सर्वर चलाना उस वायरिंग के क्लाइंट पक्ष को कवर करता है।

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

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

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

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 प्रदाता (provider) पर। ऑरिजिन और रजिस्टर्ड कॉलबैक URL अलग-अलग हैं। /api/oauth/configs की सटीक स्ट्रिंग की तुलना प्रदाता की ऐप सेटिंग्स से करें, जिसमें https की तुलना http से करना और किसी भी ट्रेलिंग स्लैश (trailing slash) की जाँच करना शामिल है।

हर /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-बिट की, गैलुआ/काउंटर मोड) के साथ सील होता है।

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

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

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

FAQ

क्या Open Connector को self-host करने के लिए मुझे public domain की आवश्यकता है?

उन providers के लिए जो API key का उपयोग करते हैं, नहीं: 127.0.0.1 पर एक gateway पर्याप्त है। OAuth के लिए, व्यवहार में हाँ। Provider ब्राउज़र को आपके callback URL पर redirect करता है, इसलिए उस URL को public internet से resolve होना चाहिए, और providers localhost के अलावा plain http:// को स्वीकार करने से मना कर देते हैं। पहली बार start करने से पहले OOMOL_CONNECT_ORIGIN को अपने https:// hostname पर set करें, और provider के OAuth app में <origin>/oauth/callback को register करें।

यदि मैं Open Connector की encryption key खो दूँ तो क्या होगा?

stored credentials को decrypt नहीं किया जा सकता है, और इसका कोई recovery विकल्प नहीं है। जानबूझकर key को कभी भी data के साथ store नहीं किया जाता है, ताकि database रखने वाला कोई भी व्यक्ति इसे न पढ़ सके, आप भी नहीं। आपका एकमात्र विकल्प एक नई key set करना और प्रत्येक provider को फिर से connect करना है। Key को password manager में और database को अपनी backup rotation में रखें, क्योंकि restore करने के लिए दोनों की आवश्यकता होती है।

क्या मेरा AI agent provider access token देख सकता है?

जब यह gateway के माध्यम से call करता है, तब नहीं। Agent oct_ से शुरू होने वाले runtime token के साथ authenticate होता है, और gateway server पर outbound request में provider credential को inject कर देता है, जिससे केवल response वापस आता है। दो चीजें इस विशेषता को तोड़ती हैं: /v1/proxy/:service endpoint, जो आपके credential के साथ raw requests को forward करता है और जिसके grants खाली शुरू होते हैं, और agent में स्वयं API key paste करना, जो gateway को पूरी तरह से छोड़ देता है।

क्या gateway public internet से reachable होना चाहिए?

केवल /oauth/callback को होना चाहिए। Container port को 127.0.0.1 पर publish करें ताकि Docker के NAT rules इसे आपके firewall के बाहर expose न कर सकें, और reverse proxy को सामने रखें। फिर बिना किसी authorization header के एक action call का परीक्षण करें। यदि यह सफल होता है, तो proxy पर /api, /v1 और /mcp को उन addresses तक सीमित करें जिनका उपयोग आपके agents करते हैं, जब तक कि केवल authenticated calls ही काम न करें।

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

यह Apache 2.0 licensed है और तेजी से विकसित हो रहा है: repository 29 June 2026 को दिखाई दी और v1.3.3 को 30 July 2026 को ship किया गया, इसलिए इस guide में प्रत्येक version number को 1 August 2026 के snapshot के रूप में मानें। इसे release tag पर pin करके चलाएं, कभी भी latest या tip पर नहीं, प्रत्येक upgrade से पहले release notes पढ़ें, और एक volume backup रखें जिसे आपने एक बार restore करके देखा हो। आपके स्वामित्व वाले box के लिए design सही है, और जोखिम version में बदलाव है, न कि architecture।