AI agents کے لیے Open Connector خود host کریں

AI agent کے لیے Open Connector کیا کرتا ہے

Open Connector کو خود host کرنے سے آپ کے AI agents اور ان کے استعمال کردہ ہر software as a service (SaaS) API کے درمیان ایک auth gateway قائم ہو جاتا ہے۔ اس طرح agent کے پاس کبھی بھی provider token نہیں ہوتا۔ یہ OOMOL Lab کا open source gateway ہے اور Apache 2.0 کے تحت licensed ہے۔ یہ ایک container کے طور پر چلتا ہے، اپنی state ایک SQLite file میں محفوظ رکھتا ہے، اور provider actions کو HTTP اور MCP (model context protocol) کے ذریعے فراہم کرتا ہے۔

اصل مسئلہ دوسری integration سے شروع ہوتا ہے۔ ہر provider کا اپنا OAuth (open authorization) flow، refresh token کی اپنی مدت، اور scope names کا اپنا مجموعہ ہوتا ہے۔ کسی agent میں پانچ providers کو دستی طور پر شامل کرنے کے لیے پانچ redirect handlers، پانچ credential stores، اور پانچ refresh loops درکار ہوتے ہیں۔ ان loops کو token کی میعاد ختم ہونے سے پہلے چلنا ہوتا ہے۔ تقریباً کوئی بھی یہ code نہیں لکھتا۔ اس کے بجائے ہر service کے لیے ایک طویل مدت والا personal access token بنایا جاتا ہے اور اسے agent config، environment file، یا خود prompt میں paste کر دیا جاتا ہے۔ اس token کو agent کے چلائے گئے ہر tool کے ذریعے پڑھا جا سکتا ہے۔ یہ transcript میں بھی شامل ہو جاتا ہے۔ یہی وہ خرابی ہے جسے AI agents سے secrets کو دور رکھنا بیان کرتا ہے۔

Auth gateway credential کو دو حصوں میں تقسیم کرتا ہے۔ Gateway provider credential محفوظ کرتا ہے اور OAuth flow چلاتا ہے۔ Agent کو ایک runtime token ملتا ہے جو صرف gateway کے خلاف کارآمد ہوتا ہے۔ جب agent کسی action کو call کرتا ہے تو gateway محفوظ credential لوڈ کرتا ہے، اسے server side پر outbound request میں شامل کرتا ہے، اور صرف response body واپس کرتا ہے۔ Agent کو provider access token کبھی نہیں ملتا۔ اس لیے اگر agent کا transcript افشا ہو جائے تو آپ کو اپنے GitHub account کے بجائے صرف ایک ایسا runtime token منسوخ کرنا پڑتا ہے جسے revoke کیا جا سکتا ہے۔

Catalog میں 1,000 سے زیادہ providers اور 10,000 prebuilt actions درج ہیں۔ یہ project کا اپنا اعداد و شمار ہے، ایسی چیز نہیں جس کی باہر سے تصدیق کی جا سکے۔ جس چیز کی تصدیق کی جا سکتی ہے وہ اس کا ڈھانچہ ہے: ہر action کے لیے ایک HTTP endpoint، ہر provider کے لیے ایک stored connection، اور ہر agent کے لیے ایک token۔

میزبان کردہ کنیکٹر سروس استعمال کرنے کے بجائے Open Connector کو خود میزبان بنانے کی وجوہات

میزبان کردہ کنیکٹر سروس یہی کام کرتی ہے، اور جن فراہم کنندگان سے آپ اسے مربوط کرتے ہیں، ان سب کے refresh tokens اپنے پاس رکھتی ہے۔ Google یا GitHub کا refresh token آپ کی ای میل اور repositories تک طویل مدتی رسائی کی cryptographic key ہوتا ہے، اور یہ عموماً password تبدیل کرنے کے بعد بھی فعال رہتا ہے۔ اگر ان کی سروس breach ہو جائے تو آپ کا نظام بھی breach ہو جاتا ہے۔ خود میزبانی کرنے سے یہ records اس مشین پر SQLite میں منتقل ہو جاتے ہیں جسے آپ کرائے پر لیتے اور administer کرتے ہیں، اور انہیں ایسی key سے محفوظ کیا جاتا ہے جو آپ کے box سے کبھی باہر نہیں جاتی۔

شروع کرنے سے پہلے لاگت واضح طور پر سمجھ لیں۔ یہ VPS آپ کے زیر انتظام سب سے قیمتی server بن جائے گا۔ اس میں ایک file میں درجن بھر services کے working credentials موجود ہوں گے، اس لیے اسے password manager host جیسا تحفظ دیں: firewall صرف 443 کو expose کرے، shared logins نہ ہوں، ایسا backup موجود ہو جسے آپ کم از کم ایک بار restore کر چکے ہوں، اور جب یہ جواب دینا بند کرے تو alert موصول ہو۔ اگر آپ اس box پر اپنا password vault نہیں رکھیں گے تو connector بھی اس پر نہ رکھیں۔

کچھ بھی انسٹال کرنے سے پہلے ورژن مقرر کریں

Open Connector نیا پروجیکٹ ہے۔ اس کی repository پہلی بار 29 June 2026 کو ظاہر ہوئی، اور 1 August 2026 تک تازہ ترین tagged release v1.3.3 ہے، جو 30 July 2026 کو شائع ہوئی اور اس پر latest tag بھی موجود ہے۔ registry ایک tip tag بھی شائع کرتی ہے، جو main کی تازہ ترین commit سے بنایا گیا ہے۔

اتنے نئے پروجیکٹ میں متحرک tags اکثر تبدیل ہوتے ہیں۔ اگر کوئی docker compose pull دو releases آگے بڑھ جائے تو یہ آپ کے agent پر منحصر endpoint تبدیل کر سکتا ہے، اور آپ پوری شام اسے agent کے مسئلے کے طور پر debug کرتے رہیں گے۔ image کو کسی release tag پر مقرر کریں، اور upgrade اسی وقت کریں جب آپ فیصلہ کریں، release notes پڑھنے کے بعد۔

اپنے VPS پر TLS کے پیچھے Open Connector تعینات کریں

کنٹینر شروع ہونے سے پہلے آپ کو یہ چیزیں درکار ہیں:

• Ubuntu 24.04 یا اس کے قریب کسی ورژن پر Docker اور Compose plugin
• ایسا hostname جس کا A record اس VPS کی طرف اشارہ کرتا ہو، مثلاً connect.example.com
• ایسا reverse proxy جو پہلے ہی اس hostname کے لیے TLS (transport layer security) ختم کرتا ہو
• دو بے ترتیب secrets، جو نیچے بنائے جائیں گے

متعدد Docker Compose apps کے لیے Traefik reverse proxy میں proxy کا حصہ شامل ہے۔ ایک ہی app کے لیے ابتدا سے انتہا تک certificate کی ترتیب Docker اور HTTPS کے ساتھ VPS پر n8n گائیڈ میں موجود ہے۔

پہلے secrets بنائیں۔ encryption key محفوظ شدہ credentials کو encrypt کرتی ہے۔ admin token web console اور پورے /api surface کی حفاظت کرتا ہے۔ دونوں کی کوئی default value نہیں ہے، اور 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 کا کوئی طریقہ نہیں ہے، جس کی وجہ نیچے failure list میں بیان کی گئی ہے۔

اب compose.yaml۔ یہ upstream example سے دو جگہ مختلف ہے، اور دونوں تبدیلیاں اہم ہیں۔

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 file 3000:3000 publish کرتی ہے، جو host کے ہر interface پر bind ہوتی ہے۔ Docker پیکٹ کے ufw filter chain تک پہنچنے سے پہلے اپنے published ports کو NAT (network address translation) table میں لکھ دیتا ہے، اس لیے ufw deny 3000 اس port کو بند نہیں کرتا۔ اس مسئلے کی وضاحت Docker ports کے ufw کو bypass کرنے کی وجہ میں ہے۔ 127.0.0.1:3000:3000 لکھنے سے port صرف loopback interface پر publish ہوتی ہے، اور آپ کا reverse proxy اسی host سے connect کرتا ہے۔

:? ہر variable کو required قرار دیتا ہے، اس لیے .env غائب ہونے پر stack شروع ہونے کے بجائے رک جاتا ہے اور credentials غیر محفوظ حالت میں استعمال نہیں ہوتے۔ values کو compose file کے بجائے .env میں رکھنا Docker Compose env files اور 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 runtime کے چلنے کے بعد { "ok": true } کا جواب دیتا ہے۔ ss کو 127.0.0.1:3000 دکھانا چاہیے۔ 0.0.0.0:3000 والی line کا مطلب ہے کہ port mapping اب بھی upstream والی ہے اور gateway پورے internet کو براہ راست جواب دے رہا ہے۔ health check پر connection refused کا مطلب ہے کہ container ابھی 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 کے لیے حقیقی hostname کیوں ضروری ہے

OOMOL_CONNECT_ORIGIN وہ setting ہے جسے لوگ نظرانداز کر دیتے ہیں۔ اسے نظرانداز کرنے سے OAuth اس طرح ناکام ہوتا ہے جیسے خرابی provider میں ہو۔ runtime اسی origin سے redirect URI بناتا ہے، جس کی شکل <origin>/oauth/callback ہوتی ہے۔ اگر origin set نہ ہو تو یہ http://localhost:3000 پر default ہو جاتا ہے۔ اس صورت میں runtime provider کو http://localhost:3000/oauth/callback بطور redirect URI بھیجتا ہے، جبکہ آپ کی OAuth app میں https://connect.example.com/oauth/callback registered ہے۔ دونوں strings مختلف ہیں، اس لیے GitHub یہ جواب دیتا ہے:

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

OAuth provider browser کو اسی URI پر واپس redirect کرتا ہے۔ اس لیے یہ ایسا address ہونا چاہیے جس تک بیرونی دنیا رسائی حاصل کر سکے۔ Providers localhost کے علاوہ plain http:// کو مسترد کرتے ہیں۔ اسی لیے اس deployment کے لیے hostname اور certificate ضروری ہیں۔ پہلی بار start کرنے سے پہلے origin set کریں، کیونکہ یہ value startup کے وقت پڑھی جاتی ہے۔ .env یا compose.yaml میں ترمیم کے بعد اسے لاگو کرنے کے لیے دوبارہ docker compose up -d چلائیں۔

اپنے پہلے provider کو OAuth کے ذریعے مربوط کریں

پہلے provider پر OAuth app بنائیں۔ GitHub میں راستہ Settings، پھر Developer settings، پھر OAuth Apps، اور پھر New OAuth App ہے۔ authorization callback URL کو https://connect.example.com/oauth/callback پر سیٹ کریں۔ client ID اور client secret محفوظ رکھیں۔

ہر /api call میں 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"

اس listing میں ہر provider کے لیے runtime کو درکار 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"}'

دوسری call ایک authorizationUrl واپس کرتی ہے۔ اسے browser میں کھولیں، scopes منظور کریں، اور provider browser کو واپس /oauth/callback پر بھیج دیتا ہے۔ وہاں runtime code کا تبادلہ کرتا ہے اور credential محفوظ کرتا ہے۔ آپ کے origin پر موجود web console اسی admin token کے پیچھے ایک form کے ذریعے یہی مراحل مکمل کراتا ہے۔ جو providers سادہ 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 کے ذریعے ایکشنز کال کرتا ہے۔

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 ہو، جبکہ provider کا payload data کے تحت موجود ہو۔ اس جواب میں کہیں بھی GitHub token شامل نہیں ہوتا۔ MCP کلائنٹ کے لیے اسے اسی bearer header کے ساتھ https://connect.example.com/mcp کی طرف بھیجیں۔ اس صورت میں gateway ہر API کے لیے الگ tool دینے کے بجائے search_actions اور execute_action جیسے discovery tools فراہم کرتا ہے، جس سے ایجنٹ کی tool فہرست مختصر رہتی ہے۔ VPS پر MCP servers چلانا کلائنٹ کی طرف کی اس ترتیب کی وضاحت کرتا ہے۔

اسے مکمل سمجھنے سے پہلے ایک اور جانچ کریں۔ authorization header حذف کر کے action call دوبارہ چلائیں۔ پروجیکٹ کا اپنا quickstart /v1 کو کسی bearer کے بغیر کال کرتا ہے، اس لیے رن ٹائم تصدیق کے بغیر کی گئی تنصیب ہر اس شخص کے لیے actions چلا دے گی جو اس port تک پہنچ سکتا ہو۔ اگر آپ کی غیر مصدقہ کال کامیاب ہو جائے تو دو راستے ہیں: رن ٹائم tokens ترتیب دیں اور تصدیق کریں کہ anonymous call اب ناکام ہو جاتی ہے، یا reverse proxy پر /api، /v1 اور /mcp کو ان addresses تک محدود کریں جہاں سے آپ کے agents آتے ہیں۔ صرف /oauth/callback کو دنیا کے لیے کھلا رہنا ضروری ہے، کیونکہ provider کے browser redirect کے لیے یہی واحد راستہ درکار ہے۔

ایجنٹ کے لیے ضروری کارروائیوں تک فہرست محدود کریں

اس کے پیچھے ایک ہزار providers والے gateway کو language model کے سامنے رکھنا وسیع attack surface پیدا کرتا ہے۔ دو controls اسے محدود کرتے ہیں۔

OOMOL_CONNECT_ALLOWED_ACTIONS comma-separated allowlist لیتا ہے اور service.* اور * کو سمجھتا ہے۔ OOMOL_CONNECT_BLOCKED_ACTIONS denylist ہے، اور denylist کو ترجیح حاصل ہوتی ہے۔ allowlist کو github.get_current_user,github.list_issues پر سیٹ کرنے کا مطلب ہے کہ agent کی درخواست سے قطع نظر ہر دوسری action مسترد کر دی جائے گی۔ یہی غلطی اور security incident کے درمیان فرق ہے۔ Runtime tokens عالمی rules کے علاوہ اپنے action rules بھی رکھتے ہیں، اور ان کی allowedProxies list ابتدا میں خالی ہوتی ہے، اس لیے POST /v1/proxy/:service اس وقت تک مسترد رہے گا جب تک آپ اسے اجازت نہ دیں۔ یہ proxy endpoint آپ کے credential کے ساتھ raw request کو provider کو forward کرتا ہے، اس لیے اسے خالی رکھیں، الا یہ کہ کسی مخصوص agent کو اس کی ضرورت ہو۔

OOMOL_CONNECT_ALLOW_PRIVATE_NETWORK کی default قدر false ہے۔ یہ self-hosted provider connection کو کسی نجی address، مثلاً 169.254.169.254 پر cloud metadata service یا اسی network پر موجود آپ کے database، کی طرف اشارہ کرنے سے روکتا ہے۔ اسے بند رکھیں۔ اسے صرف ایسے provider کے لیے فعال کریں جسے آپ خود host کرتے ہیں۔

ہر token رکھنے والے box کا بیک اپ لیں

دو چیزیں اہم ہیں، اور ایک دوسری کے بغیر دونوں بے فائدہ ہیں۔ connector-data volume کے اندر موجود /app/data/connect.sqlite database میں محفوظ credentials رکھے جاتے ہیں۔ .env میں موجود encryption key انہیں کھولتی ہے۔ key کے بغیر volume کا بیک اپ بحال کرنے سے کچھ حاصل نہیں ہوتا، اور volume کے بغیر key بھی بے فائدہ ہے۔ اس لیے key کو اپنے password manager میں رکھیں، جبکہ volume کو اپنے معمول کے backup rotation میں شامل کریں۔

SQLite file کو copy کرتے وقت container کو روک دیں، کیونکہ write کے دوران بنائی گئی copy بحال ہونے پر corrupt database بن سکتی ہے۔

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

volume کا نام آپ کی project directory کے ساتھ _connector-data جوڑ کر بنتا ہے۔ اسی لیے پہلا command موجود ہے: اصل نام کو تیسرے command میں paste کریں۔ archive کو VPS سے VPS سے restic backups کے ذریعے باہر بھیجیں۔ یہ archive کے باہر جانے سے پہلے اسے encrypt کرتا ہے، کیونکہ اس archive میں credential store موجود ہے۔

runtime حالیہ action runs کو audit records کے طور پر محفوظ رکھتا ہے، اور بطورِ ڈیفالٹ 5,000 records رکھتا ہے۔ اس سے console یہ بتا سکتا ہے کہ کس agent نے کیا کام اور کب کیا۔ جب کوئی agent غیر معمولی رویہ دکھائے تو سب سے پہلے یہی log پڑھیں۔ https://connect.example.com/health کی طرف Uptime Kuma status page بھی متوجہ کریں۔ جب gateway جواب دینا بند کر دے تو agents الجھن پیدا کرنے والے طریقوں سے fail ہوتے ہیں، اور gateway کے down ہونے کا علم agent output پڑھنے میں ضائع ہونے والا ایک گھنٹہ بچا لیتا ہے۔

کیا خراب ہوتا ہے، اور آپ کو کون سا پیغام نظر آئے گا

فراہم کنندہ پر redirect_uri_mismatch۔ Origin اور رجسٹرڈ callback URL مختلف ہیں۔ /api/oauth/configs سے حاصل کردہ عین string کا فراہم کنندہ کی app settings سے موازنہ کریں۔ اس میں https کا http سے موازنہ اور آخر میں موجود slash بھی شامل ہے۔

ہر /api call کا نتیجہ 401 آتا ہے۔ Admin token header موجود نہیں ہے یا اس کے نام میں غلطی ہے۔ Header Authorization: Bearer <token> ہے، اور web console بھی یہی token مانگتا ہے۔

Container چلتا ہے، اور credentials plain text میں موجود رہتے ہیں۔ یہ اس وقت ہوتا ہے جب OOMOL_CONNECT_ENCRYPTION_KEY container تک نہیں پہنچتا، کیونکہ runtime شروع ہونے سے انکار کرنے کے بجائے credential records کو غیر encrypted حالت میں محفوظ کرتا ہے۔ اپنے install پر اس کی تصدیق کریں: ایسے API key کے ساتھ provider connect کریں جسے آپ پہچان سکیں، پھر database میں اسے تلاش کریں۔

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

0 سے زیادہ count کا مطلب ہے کہ key مؤثر نہیں ہے۔ اس لیے جانچیں کہ .env، compose.yaml والی ہی directory میں موجود ہے اور docker compose config value دکھاتا ہے۔ Key set کرنے کے بعد یہی search 0 واپس کرتا ہے، کیونکہ record AES-256-GCM (advanced encryption standard، 256-bit key، Galois/counter mode) سے محفوظ ہوتا ہے۔

Restore کے بعد کچھ بھی decrypt نہیں ہوتا۔ Encryption key تبدیل ہو گئی یا ضائع ہو گئی ہے۔ Design کے مطابق یہ data کے ساتھ کبھی نہیں لکھی جاتی، اس لیے recovery path موجود نہیں ہے اور کوئی support ticket بھی مدد نہیں کرے گا۔ ہر provider کو دوبارہ connect کریں۔ Rotation ایک الگ key variable اور runtime میں data command کے ذریعے supported ہے، اس لیے کسی بھی rotation سے پہلے موجودہ release notes پڑھیں۔

Agent کو ایسے action کا error ملتا ہے جو catalog میں نظر آتا ہے۔ Discovery اور execution الگ مراحل ہیں۔ کوئی action search_actions میں ظاہر ہو سکتا ہے، لیکن OOMOL_CONNECT_ALLOWED_ACTIONS، denylist، یا اس runtime token کے اپنے rules کی وجہ سے اسے مسترد کیا جا سکتا ہے۔

Upgrades۔ Volume کا backup بنائیں، image tag کو نئی release پر edit کریں، پھر docker compose pull && docker compose up -d چلائیں۔ docker compose logs -n 50 connector کو migration line کے لیے monitor کریں، اور دوبارہ اعتماد کرنے سے پہلے health check اور ایک حقیقی action دوبارہ چلائیں۔ Rollback کے لیے پرانا tag واپس رکھنا ہوتا ہے۔ یہ صرف اس لیے کام کرتا ہے کہ آپ نے اسے pin کیا تھا۔

FAQ

کیا مجھے Open Connector کو خود ہوسٹ کرنے کے لیے عوامی ڈومین درکار ہے؟

جو providers API key استعمال کرتے ہیں، ان کے لیے نہیں: 127.0.0.1 پر gateway کافی ہے۔ OAuth کے لیے عملی طور پر ہاں۔ provider browser کو آپ کے callback URL پر redirect کرتا ہے، اس لیے یہ URL عوامی انٹرنیٹ سے resolve ہونا چاہیے، اور providers localhost کے علاوہ سادہ http:// کو مسترد کرتے ہیں۔ پہلی بار start کرنے سے پہلے OOMOL_CONNECT_ORIGIN کو اپنے https:// hostname پر سیٹ کریں، اور provider کی OAuth app میں <origin>/oauth/callback رجسٹر کریں۔

اگر Open Connector کی encryption key کھو جائے تو کیا ہوگا؟

محفوظ شدہ credentials کو decrypt نہیں کیا جا سکے گا، اور recovery کا کوئی طریقہ نہیں ہے۔ یہ key جان بوجھ کر data کے ساتھ ذخیرہ نہیں کی جاتی، اس لیے database رکھنے والا کوئی بھی شخص اسے پڑھ نہیں سکتا، آپ بھی نہیں۔ آپ کا واحد اختیار نئی key سیٹ کرنا اور ہر 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 شامل کرتا ہے، جبکہ صرف response واپس کرتا ہے۔ دو صورتوں میں یہ تحفظ ختم ہو جاتا ہے: /v1/proxy/:service endpoint، جو آپ کے credential کے ساتھ raw requests forward کرتا ہے اور جس کے grants کا ابتدا میں خالی ہونا ایک وجہ سے ہے؛ اور API key کو خود agent میں paste کرنا، جس سے gateway مکمل طور پر bypass ہو جاتا ہے۔

کیا gateway عوامی انٹرنیٹ سے قابل رسائی ہونا چاہیے؟

صرف /oauth/callback کو قابل رسائی ہونا چاہیے۔ Container port کو 127.0.0.1 پر publish کریں تاکہ Docker کے NAT rules اسے firewall سے آگے expose نہ کر سکیں، اور reverse proxy کو اس کے سامنے رکھیں۔ پھر بغیر authorization header کے ایک action call test کریں۔ اگر یہ کامیاب ہو، تو 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 پر pinned رکھیں، کبھی latest یا tip پر نہ چلائیں، ہر upgrade سے پہلے release notes پڑھیں، اور volume backup رکھیں جسے آپ کم از کم ایک بار restore کر چکے ہوں۔ اپنے زیرِ انتظام server کے لیے design مضبوط ہے؛ خطرہ architecture نہیں بلکہ version churn ہے۔