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 का एक source-available gateway है, जो वर्तमान में अतिरिक्त शर्तों के साथ एक संशोधित Apache 2.0 license के तहत उपलब्ध है। v1.9.4 तक के releases Apache 2.0 के अंतर्गत हैं; v1.9.5 में यह बदलाव पेश किया गया था। यदि आप कोई ऐसी hosted या managed service प्रदान करते हैं जिसका प्राथमिक मूल्य OpenConnector की कार्यक्षमता है, तो आपको OOMOL से commercial 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 होने से पहले चलना चाहिए। लगभग कोई भी यह कोड नहीं लिखता। वे हर service के लिए एक long-lived personal access token बनाते हैं और उसे agent config, environment file, या सीधे prompt में paste कर देते हैं। वह token फिर agent द्वारा चलाए जाने वाले हर tool के लिए readable होता है, और वह 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। यदि इसका agent वाला हिस्सा अभी भी नया है और tool call या MCP server जैसे शब्द अभी तक स्थिर नहीं हुए हैं, तो AI agents को शून्य से कैसे सीखें में दिया गया staged path उस loop, tools, और सुरक्षा आदतों को तैयार करता है, जिन्हें इस तरह का gateway पहले से मौजूद मानकर चलता है।

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

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

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

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

Open Connector अभी नया है। यह गाइड v1.3.3 को, जिसे 30 July 2026 को release किया गया था, इसके 1 August 2026 के installation snapshot के रूप में pin करके रखती है। यह अब सबसे नया release नहीं है। 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 करें।

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

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

• Docker Engine 28.0.0 या नया, Compose प्लगइन के साथ, Ubuntu 24.04 या इसके समान किसी OS पर।
• एक hostname जिसका A record आपके VPS पर पॉइंट करता हो, उदाहरण के लिए connect.example.com।
• एक reverse proxy जो उस hostname के लिए पहले से ही TLS (transport layer security) को terminate कर रहा हो।
• दो रैंडम secrets, जिन्हें नीचे जनरेट किया गया है।

Traefik reverse proxy for multiple Docker Compose apps लेख में proxy पक्ष की जानकारी दी गई है। एक सिंगल ऐप के लिए शुरू से अंत तक certificate सेटअप करने की प्रक्रिया n8n on a VPS with Docker and HTTPS गाइड में उपलब्ध है।

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

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

दोनों values को अभी अपने password manager में कॉपी कर लें, पहली बार शुरू करने से पहले। Encryption key का कोई recovery path नहीं है, और इसका कारण नीचे दी गई failure list में बताया गया है।

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

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 के बजाय एक pinned tag का उपयोग करना है। दूसरा बदलाव port है। Upstream फाइल 3000:3000 को पब्लिश करती है, जो होस्ट के हर इंटरफेस पर bind हो जाती है। Docker अपने पब्लिश किए गए ports को NAT (network address translation) टेबल में तब लिख देता है जब ufw फिल्टर चेन पैकेट को देखती भी नहीं है, इसलिए ufw deny 3000 उस port को बंद नहीं करता, जो why Docker ports bypass ufw में वर्णित एक जाल है। 127.0.0.1:3000:3000 लिखने से यह केवल loopback इंटरफेस पर पब्लिश होता है, और आपका reverse proxy उसी होस्ट से कनेक्ट होता है। Docker Engine 28.0.0 से पहले, एक ही L2 सेगमेंट पर मौजूद होस्ट localhost पर पब्लिश किए गए ports तक पहुँच सकते थे, इसीलिए इस गाइड के लिए 28.0.0 या उससे नया वर्ज़न आवश्यक है।

:? प्रत्येक variable को आवश्यक के रूप में चिह्नित करता है, इसलिए जब .env गायब होता है तो stack शुरू होने से मना कर देता है, बजाय इसके कि वह बिना एन्क्रिप्शन के शुरू हो जाए। Compose फाइल के बजाय .env में values रखना Docker Compose env files and secrets का पैटर्न है। /v1 और /mcp को reverse proxy पर तब तक private रखें जब तक आप नीचे पहला runtime token न बना लें।

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

एक बार runtime शुरू हो जाने पर /health, { "ok": true } का उत्तर देता है। ss को 127.0.0.1:3000 प्रिंट करना चाहिए। यदि लाइन में 0.0.0.0:3000 लिखा है, तो इसका मतलब है कि listener हर IPv4 इंटरफेस पर bound है, लेकिन यह इंटरनेट से पहुँच की पुष्टि नहीं करता: upstream firewalls या Docker की DOCKER-USER चेन के नियम अभी भी बाहरी traffic को ब्लॉक कर सकते हैं। Health check पर 'Connection refused' का मतलब है कि कंटेनर अभी listen नहीं कर रहा है, इसलिए proxy को छूने से पहले logs पढ़ें।

    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 callbacks के लिए सही origin की आवश्यकता क्यों है

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 करता है, इसलिए उस पते का ब्राउज़र द्वारा पहुँच योग्य होना आवश्यक है। OAuth के लिए सार्वभौमिक रूप से public hostname की आवश्यकता नहीं होती है: OpenConnector http://localhost:3000/oauth/callback पर GitHub callbacks का दस्तावेजीकरण करता है। यह VPS deployment एक hostname और certificate का उपयोग करता है ताकि ब्राउज़र gateway तक उसके HTTPS origin पर पहुँच सके। पहली बार 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 जारी (mint) करता है।

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 के माध्यम से एक्शन कॉल करता है।

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 को कॉल करता है, इसलिए बिना रनटाइम ऑथेंटिकेशन कॉन्फ़िगर किए किया गया इंस्टॉलेशन उन सभी के लिए एक्शन निष्पादित करेगा जो पोर्ट तक पहुंच सकते हैं। यदि आपकी अनऑथेंटिकेटेड कॉल सफल हो जाती है, तो आपके पास दो रास्ते हैं: रनटाइम टोकन कॉन्फ़िगर करें और पुष्टि करें कि अब अनाम (anonymous) कॉल विफल हो रही है, या रिवर्स प्रॉक्सी पर /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 के लिए भी हमेशा इसकी आवश्यकता नहीं होती: OpenConnector, GitHub के local callback को http://localhost:3000/oauth/callback के रूप में document करता है। authorization पूरा करने वाले browser को callback URL तक पहुँचने में सक्षम होना चाहिए। इस VPS deployment के लिए, पहली बार 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 से reachable होना चाहिए?

OAuth callback को authorization पूरा करने वाले browser द्वारा reachable होना चाहिए, जिसके लिए पूरे internet से access की आवश्यकता नहीं है। Docker Engine 28.0.0 या उससे नए version और default bridge networking के साथ, container port को 127.0.0.1 पर publish करें ताकि published port केवल host से ही accessible रहे, और reverse proxy को सामने रखें। पुराने Docker releases में एक ही L2 segment पर मौजूद hosts को localhost-published ports तक पहुँचने की अनुमति थी। इसके बाद बिना authorization header के एक action call का परीक्षण करें। यदि यह सफल होता है, तो proxy पर /api, /v1 और /mcp को उन addresses तक सीमित करें जिनका उपयोग आपके agents करते हैं, जब तक कि केवल authenticated calls ही काम न करें।

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

वर्तमान releases अतिरिक्त शर्तों के साथ एक संशोधित Apache 2.0 license का उपयोग करते हैं; v1.9.4 तक के releases, जिसमें pinned v1.3.3 शामिल है, Apache 2.0 ही हैं। एक hosted या managed connector service, जिसका प्राथमिक मूल्य OpenConnector की कार्यक्षमता है, के लिए वर्तमान license के तहत OOMOL से commercial license की आवश्यकता होती है। v1.3.3 के installation commands 1 August 2026 का snapshot हैं, और वह release 30 July 2026 को जारी किया गया था। इसे हमेशा release tag पर pin करके चलाएं, कभी भी latest या tip पर नहीं। प्रत्येक upgrade से पहले release notes पढ़ें, और एक volume backup रखें जिसे आपने कम से कम एक बार restore करके देखा हो। आपके द्वारा स्वामित्व वाले सर्वर के लिए यह design सुरक्षित है, और जोखिम version में होने वाले बदलावों में है, न कि architecture में।