AI agents کے لیے Open Connector خود 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 ایک SQLite فائل میں محفوظ رکھتا ہے، اور 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 چلانا ہے، جنہیں token کے expire ہونے سے پہلے کام کرنا ہوتا ہے۔ تقریباً کوئی بھی یہ code نہیں لکھتا۔ اس کے بجائے ہر service کے لیے ایک طویل مدت والا personal access token بناتے ہیں اور اسے agent config، environment file، یا خود prompt میں paste کر دیتے ہیں۔ اس token کو agent کے چلائے ہوئے ہر tool کے ذریعے پڑھا جا سکتا ہے، اور یہ transcript میں بھی شامل ہو جاتا ہے۔ یہی وہ failure ہے جسے AI agents سے secrets باہر رکھنے میں بیان کیا گیا ہے۔

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

catalog میں 1,000 سے زیادہ providers اور 10,000 prebuilt actions کا ذکر ہے۔ یہ project کا اپنا دعویٰ ہے، ایسی چیز نہیں جس کی آپ باہر سے تصدیق کر سکیں۔ جس چیز کی آپ تصدیق کر سکتے ہیں وہ اس کا ڈھانچہ ہے: ہر action کے لیے ایک HTTP endpoint، ہر provider کے لیے ایک stored connection، اور ہر agent کے لیے ایک token۔ اگر agent کا یہ حصہ ابھی نیا ہے اور tool call یا MCP server جیسی اصطلاحات ابھی واضح نہیں ہوئی ہیں، تو شروع سے AI agents سیکھنے کا طریقہ میں دیا گیا مرحلہ وار راستہ loop، tools اور safety habits کو سمجھاتا ہے، جنہیں اس طرح کا gateway پہلے سے موجود سمجھتا ہے۔

ہوسٹڈ connector service استعمال کرنے کے بجائے Open Connector کو خود کیوں host کریں

ہوسٹڈ connector service یہی کام کرتی ہے، اور آپ سے منسلک ہر provider کے refresh tokens اپنے پاس رکھتی ہے۔ Google یا GitHub کا refresh token آپ کی mail اور repositories تک طویل مدتی رسائی دینے والی cryptographic key ہوتا ہے، اور عموماً password تبدیل کرنے کے بعد بھی فعال رہتا ہے۔ اگر ان کی سروس breach ہو جائے تو آپ کا access بھی خطرے میں پڑ جاتا ہے۔ Self-hosting ان records کو آپ کے کرائے کے زیرانتظام machine پر موجود SQLite میں منتقل کرتی ہے۔ یہ records ایسی key سے محفوظ ہوتے ہیں جو آپ کے box سے کبھی باہر نہیں جاتی۔

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

انسٹالیشن سے پہلے version مقرر کریں

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

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

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

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

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

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

پہلے secrets generate کریں۔ encryption key محفوظ شدہ credentials کو encrypt کرتی ہے۔ admin token web console اور پورے /api surface کو محفوظ بناتا ہے۔ دونوں کی کوئی default value نہیں ہے، اور runtime ان کے بغیر بھی کامیابی سے start ہو جاتا ہے۔

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

پہلی بار start کرنے سے پہلے دونوں values اپنے password manager میں محفوظ کر لیں۔ encryption key بحال نہیں کی جا سکتی، اور اس کی وجہ نیچے 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 packet کے 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 missing ہونے پر stack start ہونے سے انکار کر دیتا ہے، بجائے اس کے کہ credentials کے بغیر encrypted کیے start ہو جائے۔ 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

Runtime کے up ہونے کے بعد /health { "ok": true } کا جواب دیتا ہے۔ ss کو 127.0.0.1:3000 print کرنا چاہیے۔ 0.0.0.0:3000 والی line کا مطلب ہے کہ port mapping اب بھی upstream والی ہے، اور gateway پورے internet کو براہ راست جواب دے رہا ہے۔ Health check پر connection refused کا مطلب ہے کہ container ابھی listening نہیں کر رہا، اس لیے 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 ہوتی ہے۔ اگر یہ unset ہو تو origin کی default قدر http://localhost:3000 رہتی ہے۔ اس صورت میں 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 configuration مؤثر ہوئی یا نہیں۔ اگر یہاں اب بھی localhost دکھائی دے تو container پرانی value کے ساتھ چل رہا ہے، اور 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 براہِ راست محفوظ ہو جاتی ہے۔

ہر agent کو runtime token دیں، credential کبھی نہیں

agent gateway کے ساتھ runtime token کے ذریعے authentication کرتا ہے، جسے 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"}'

response میں oct_ سے شروع ہونے والا token شامل ہوتا ہے۔ ہر agent کے لیے ایک token جاری کریں اور اسے اسی agent کے نام سے نامزد کریں، کیونکہ جس token کی شناخت نہ ہو اسے revoke کرنے کا مطلب تمام tokens revoke کرنا ہے۔ اس کے بعد agent عام HTTP کے ذریعے actions کو call کرتا ہے۔

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":{}}'

صحت مند response ایک envelope ہوتا ہے جس کے success field کی قدر true ہوتی ہے، جبکہ provider payload data کے تحت موجود ہوتا ہے۔ GitHub token اس response میں کہیں بھی شامل نہیں ہوتا۔ MCP client کے لیے اسے اسی bearer header کے ساتھ https://connect.example.com/mcp پر point کریں۔ gateway ہر API کے لیے الگ tool دینے کے بجائے search_actions اور execute_action جیسے discovery tools فراہم کرتا ہے، جس سے agent کی tool list مختصر رہتی ہے۔ VPS پر MCP servers چلانا اس wiring کے client حصے کی وضاحت کرتا ہے۔

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

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

ایک gateway کے پیچھے ہزار providers ہوں تو language model کے سامنے بڑا attack surface آ جاتا ہے۔ یہ اس وقت مزید وسیع ہو جاتا ہے جب model اپنے تخلیق نہ کیے ہوئے متن کو پڑھنا شروع کرتا ہے، کیونکہ آپ کی اپنی SearXNG instance جو ایجنٹ کی web searches کا جواب دیتی ہے کی واپس کردہ page میں ایجنٹ کے دستیاب actions کو متاثر کرنے والی instructions شامل ہو سکتی ہیں۔ یہی احتیاط، جو coding agent کو کام کرنے والی سب سے چھوٹی تبدیلی کرنے پر مجبور کرتی ہے، اس کی permissions میں بھی ہونی چاہیے: صرف وہ چند actions دیں جن کی کام کو واقعی ضرورت ہے، اور اس سے زیادہ کچھ نہیں۔ دو controls اس دائرے کو محدود کرتے ہیں۔

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

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

اس سرور کا بیک اپ لیں جس میں ہر token محفوظ ہے

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

SQLite file نقل کرتے وقت 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 سے restic backups کے ذریعے VPS سے باہر بھیجیں۔ یہ archive کے باہر جانے سے پہلے اسے encrypt کرتا ہے، کیونکہ اس archive میں credentials store موجود ہے۔

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

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

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

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

Container چلتا ہے، اور credentials plain text میں موجود رہتے ہیں۔ ایسا اس وقت ہوتا ہے جب OOMOL_CONNECT_ENCRYPTION_KEY container تک نہیں پہنچتا، کیونکہ runtime start ہونے سے انکار کرنے کے بجائے credential records کو unencrypted محفوظ کرتا ہے۔ اپنی installation پر اس کی تصدیق کریں: ایسے 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 اسی directory میں موجود ہے جس میں compose.yaml ہے، اور docker compose config value دکھاتا ہے۔ Key set کرنے کے بعد یہی search 0 واپس کرتی ہے، کیونکہ record AES-256-GCM (advanced encryption standard، 256-bit key، Galois/counter mode) سے seal ہوتا ہے۔

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 میں تبدیل کریں، پھر docker compose pull && docker compose up -d چلائیں۔ docker compose logs -n 50 connector میں migration line دیکھیں، اور دوبارہ health check اور ایک حقیقی action چلانے کے بعد ہی اسے قابل اعتماد سمجھیں۔ Rollback کے لیے پرانا tag واپس رکھنا ہوتا ہے۔ یہ صرف اس لیے کام کرتا ہے کہ آپ نے اسے pin کیا تھا۔

FAQ

کیا Open Connector کو self-host کرنے کے لیے public domain ضروری ہے؟

API key استعمال کرنے والے providers کے لیے نہیں: 127.0.0.1 پر gateway کافی ہے۔ OAuth کے لیے عملی طور پر ہاں۔ Provider browser کو آپ کے 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 کھو جائے تو کیا ہوگا؟

محفوظ credentials decrypt نہیں کیے جا سکیں گے، اور recovery کا کوئی طریقہ نہیں ہوگا۔ یہ key جان بوجھ کر data کے ساتھ ذخیرہ نہیں کی جاتی، اس لیے 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 شامل کرتا ہے، پھر صرف response واپس کرتا ہے۔ دو صورتیں اس تحفظ کو ختم کرتی ہیں: /v1/proxy/:service endpoint، جو آپ کے credential کے ساتھ raw requests آگے بھیجتا ہے اور جس کے 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 test کریں۔ اگر یہ کامیاب ہو جائے تو proxy پر /api، /v1 اور /mcp کو ان addresses تک محدود کریں جہاں سے آپ کے agents استعمال ہوتے ہیں، یہاں تک کہ صرف authenticated calls کام کریں۔

کیا Open Connector production استعمال کے لیے تیار ہے؟

اس کا license Apache 2.0 ہے اور development تیزی سے جاری ہے: 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 کر چکے ہوں۔ اپنے زیر انتظام server کے لیے design قابل اعتماد ہے؛ خطرہ architecture نہیں بلکہ version churn ہے۔