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 लाइसेंस के तहत उपलब्ध है। यह एक container के रूप में चलता है, अपनी state को एक single SQLite file में रखता है, और provider actions को HTTP तथा MCP (model context protocol) के माध्यम से expose करता है।

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

एक auth gateway credential को दो भागों में विभाजित करता है। Gateway provider credential को store करता है और OAuth flow को चलाता है। Agent को एक runtime token मिलता है जो केवल gateway के विरुद्ध मान्य होता है। जब agent किसी action को कॉल करता है, तो gateway stored credential को load करता है, उसे server side पर outbound request में inject करता है, और केवल response body लौटाता है। Agent को कभी भी provider access token प्राप्त नहीं होता है, इसलिए एक लीक हुए 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।

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

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

शुरू करने से पहले इसकी लागत को स्पष्ट रूप से समझ लें। यह VPS आपके द्वारा चलाए जाने वाले सबसे महत्वपूर्ण सर्वर में बदल जाता है। इसमें एक ही file में दर्जनों सेवाओं के लिए working credentials होते हैं, इसलिए इसे वही महत्व दें जो आप एक password manager host को देते हैं: एक firewall जो केवल 443 port को expose करे, कोई shared logins न हों, एक ऐसा backup जिसे आपने वास्तव में एक बार restore करके देखा हो, और इसके बंद होने पर एक alert की व्यवस्था हो। यदि आप अपना password vault इस box पर नहीं रखेंगे, तो 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 को पार कर जाता है, वह उस 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 (ट्रांसपोर्ट लेयर सिक्योरिटी) टर्मिनेट कर रही हो
• दो रैंडम सीक्रेट्स, जिन्हें नीचे जनरेट किया गया है

Traefik reverse proxy for multiple Docker Compose apps गाइड प्रॉक्सी पक्ष को कवर करती है। एक सिंगल ऐप के लिए सर्टिफिकेट प्लंबिंग की पूरी प्रक्रिया n8n on a VPS with Docker and HTTPS गाइड में दी गई है।

सबसे पहले सीक्रेट्स जनरेट करें। एन्क्रिप्शन की (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 उस पोर्ट को बंद नहीं करता है। यह वह ट्रैप है जिसे why Docker ports bypass ufw में समझाया गया है। 127.0.0.1:3000:3000 लिखने से यह केवल लूपबैक इंटरफेस पर पब्लिश होता है, और आपकी रिवर्स प्रॉक्सी उसी होस्ट से कनेक्ट होती है।

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

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 कोड का आदान-प्रदान करता है और 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 को दुनिया के लिए खुला रहना चाहिए, क्योंकि यह एकमात्र रास्ता है जिसकी प्रदाता के ब्राउज़र रीडायरेक्ट को आवश्यकता होती है।

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

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

OOMOL_CONNECT_ALLOWED_ACTIONS एक कॉमा-सेपरेटेड अलाउलिस्ट (allowlist) लेता है और service.* तथा * को समझता है। OOMOL_CONNECT_BLOCKED_ACTIONS डेनिलिस्ट (denylist) है, और डेनिलिस्ट को प्राथमिकता मिलती है। अलाउलिस्ट को 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 होते हैं, ताकि कंसोल आपको बता सके कि किस एजेंट ने क्या और कब रन किया। जब कोई एजेंट अजीब व्यवहार करे तो वह लॉग सबसे पहले पढ़ा जाना चाहिए। https://connect.example.com/health पर एक Uptime Kuma स्टेटस पेज भी सेट करें। जब गेटवे जवाब देना बंद कर देता है, तो एजेंट भ्रमित करने वाले तरीके से फेल होते हैं, और यह जानना कि गेटवे डाउन है, एजेंट आउटपुट को पढ़ने में लगने वाले एक घंटे के समय को बचा सकता है।

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

redirect_uri_mismatch प्रदाता पर। ओरिजिन और रजिस्टर्ड कॉलबैक 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-बिट की, गैलोज़/काउंटर मोड) के साथ सील होता है।

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

एजेंट को एक ऐसी एक्शन का नाम लेने वाली एरर मिलती है जिसे वह कैटलॉग में देख सकता है। डिस्कवरी और एक्जीक्यूशन अलग-अलग हैं। एक एक्शन 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 सर्वर पर outbound request में provider credential को inject करता है, जिससे केवल response वापस मिलता है। दो स्थितियाँ इस सुरक्षा को तोड़ती हैं: /v1/proxy/:service endpoint, जो आपके credential के साथ raw requests को forward करता है (इसी कारण इसके grants खाली शुरू होते हैं), और agent में स्वयं API key paste करना, जो gateway को पूरी तरह से bypass कर देता है।

क्या gateway public internet से पहुँच योग्य होना चाहिए?

केवल /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 को release किया गया, इसलिए इस guide में प्रत्येक version number को 1 August 2026 के snapshot के रूप में देखें। इसे हमेशा release tag पर pin करके चलाएं, कभी भी latest या tip पर नहीं, प्रत्येक upgrade से पहले release notes पढ़ें, और एक volume backup रखें जिसे आपने कम से कम एक बार restore करके देखा हो। आपके द्वारा नियंत्रित सर्वर के लिए इसका design सुदृढ़ है, और जोखिम version में होने वाले बदलावों का है, न कि architecture का।