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 کا source-available gateway ہے، جسے فی الحال اضافی شرائط کے ساتھ modified Apache 2.0 license کے تحت جاری کیا گیا ہے۔ v1.9.4 تک کی releases Apache 2.0 کے تحت رہتی ہیں؛ v1.9.5 میں یہ تبدیلی متعارف ہوئی۔ ایسی hosted یا managed service فراہم کرنے کے لیے جس کی بنیادی قدر OpenConnector کی functionality ہو، OOMOL سے commercial license درکار ہے۔ یہ ایک container کے طور پر چلتا ہے، اپنی state ایک 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 کے ذریعے پڑھا جا سکتا ہے، اور یہ 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 میں inject کرتا ہے، اور صرف response body واپس کرتا ہے۔ agent کو provider access token کبھی نہیں ملتا۔ اس لیے اگر agent کا transcript leak ہو جائے تو نقصان آپ کے 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 سیکھنے کا طریقہ میں دیا گیا مرحلہ وار راستہ loop، tools، اور safety habits کی بنیاد فراہم کرتا ہے، جنہیں ایسا gateway یہ فرض کرتا ہے کہ آپ پہلے سے جانتے ہیں۔

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

میزبان کردہ connector سروس یہی کام کرتی ہے، اور ہر اس provider کے refresh tokens اپنے پاس رکھتی ہے جس سے آپ اسے connect کرتے ہیں۔ Google یا GitHub کا refresh token آپ کی mail اور repositories تک طویل مدتی رسائی کی کلید ہوتا ہے۔ اگر وہ breach ہو جائیں تو آپ بھی breached تصور ہوں گے۔ Self-hosting ان records کو SQLite میں اس machine پر منتقل کرتی ہے جسے آپ rent اور administer کرتے ہیں۔ یہ records ایسی key سے محفوظ رہتے ہیں جو کبھی آپ کے box سے باہر نہیں جاتی۔

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

انسٹال کرنے سے پہلے ورژن pin کریں

Open Connector نیا سافٹ ویئر ہے۔ اس گائیڈ میں v1.3.3 کو 1 اگست 2026 کے installation snapshot کے طور پر pin کیا گیا ہے۔ یہ ورژن 30 July 2026 کو جاری ہوا تھا۔ اب یہ تازہ ترین release نہیں ہے۔ registry میں tip tag بھی موجود ہے، جو main پر موجود تازہ ترین commit سے build کیا گیا ہے۔

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

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

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

• Ubuntu 24.04 یا اس سے ملتے جلتے نظام پر Docker Engine 28.0.0 یا اس کے بعد کا ورژن، جس میں 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 کا حصہ بیان کیا گیا ہے۔ ایک ہی ایپ کے لیے ابتدا سے آخر تک certificate plumbing، Docker اور HTTPS کے ساتھ VPS پر n8n گائیڈ میں موجود ہے۔

پہلے secrets generate کریں۔ Encryption key محفوظ شدہ credentials کو seal کرتی ہے۔ 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 میں copy کریں۔ Encryption key کے لیے recovery path موجود نہیں ہے، اور اس کی وجہ نیچے 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 اپنے published ports کو NAT (network address translation) table میں اس سے پہلے لکھ دیتا ہے کہ packet ufw filter chain تک پہنچے، اس لیے ufw deny 3000 اس port کو بند نہیں کرتا۔ یہ وہی مسئلہ ہے جسے Docker ports کے ufw کو bypass کرنے کی وجہ میں بیان کیا گیا ہے۔ 127.0.0.1:3000:3000 لکھنے سے port صرف loopback interface پر publish ہوتی ہے، اور آپ کا reverse proxy اسی host سے connect کرتا ہے۔ Docker Engine 28.0.0 سے پہلے، اسی L2 segment پر موجود hosts localhost پر publish کیے گئے ports تک پہنچ سکتے تھے، اسی لیے اس گائیڈ کے لیے 28.0.0 یا اس کے بعد کا ورژن درکار ہے۔

:? ہر variable کو required قرار دیتا ہے، اس لیے .env missing ہونے پر stack credentials کو unencrypted حالت میں start کرنے کے بجائے start ہونے سے انکار کر دیتا ہے۔ Values کو compose file کے بجائے .env میں رکھنا Docker Compose env files اور secrets میں بیان کردہ طریقہ ہے۔ نیچے پہلا runtime token بنانے تک /v1 اور /mcp کو reverse proxy پر private رکھیں۔

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 کے up ہونے کے بعد ایک مرتبہ { "ok": true } کا جواب دیتا ہے۔ ss کو 127.0.0.1:3000 print کرنا چاہیے۔ 0.0.0.0:3000 پڑھنے والی line کا مطلب ہے کہ listener ہر IPv4 interface پر bound ہے، لیکن اس سے internet reachability ثابت نہیں ہوتی: upstream firewalls یا Docker کی DOCKER-USER chain میں موجود rules اب بھی external traffic کو block کر سکتے ہیں۔ 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 callbacks کے لیے درست origin کیوں ضروری ہے

OOMOL_CONNECT_ORIGIN وہ setting ہے جسے لوگ نظرانداز کر دیتے ہیں، اور اسے نظرانداز کرنے سے OAuth اس طرح ناکام ہوتا ہے جیسے خرابی provider میں ہو۔ runtime اسی origin کی بنیاد پر redirect URI بناتا ہے، جس کی شکل <origin>/oauth/callback ہوتی ہے۔ اگر اسے set نہ کیا جائے تو 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 کرتا ہے، اس لیے یہ URI اس browser کے لیے قابل رسائی ہونا چاہیے۔ OAuth کے لیے ہر صورت public hostname ضروری نہیں ہے: OpenConnector، GitHub callbacks کے لیے http://localhost:3000/oauth/callback document کرتا ہے۔ اس VPS deployment میں hostname اور certificate استعمال ہوتے ہیں، تاکہ browser gateway تک اس کے HTTPS origin کے ذریعے پہنچ سکے۔ پہلی بار 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 کرتا ہے۔ یہ token 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 کال کرتا ہے۔

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 کے لیے اسے https://connect.example.com/mcp پر اسی bearer header کے ساتھ 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 اب ناکام ہوتی ہے، یا reverse proxy پر /api، /v1 اور /mcp کو ان addresses تک محدود کریں جہاں سے آپ کے agents آتے ہیں۔ authorization مکمل کرنے والے browser کے لیے /oauth/callback قابل رسائی ہونا ضروری ہے؛ اسے پورے internet کے لیے کھلا رکھنا ضروری نہیں۔

ایجنٹ کے لیے ضروری 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 کے لیے بھی ہر صورت میں public domain ضروری نہیں؛ OpenConnector GitHub کے لیے local callback کو http://localhost:3000/oauth/callback کے طور پر دستاویز کرتا ہے۔ Authorization مکمل کرنے والے browser کو callback URL تک رسائی حاصل ہونی چاہیے۔ اس VPS deployment کے لیے پہلی بار 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 forward کرتا ہے اور جس کے grants کا خالی ہونا ایک وجہ سے ہے؛ اور خود agent میں API key paste کرنا، جس سے gateway مکمل طور پر bypass ہو جاتا ہے۔

کیا gateway public internet سے قابل رسائی ہونا چاہیے؟

Authorization مکمل کرنے والے browser کے لیے OAuth callback تک رسائی ضروری ہے، لیکن پورے internet سے access دینا ضروری نہیں۔ Docker Engine 28.0.0 یا اس کے بعد کے ورژن اور default bridge networking کے ساتھ container port کو 127.0.0.1 پر publish کریں تاکہ published port صرف host سے قابل رسائی رہے، اور reverse proxy کو اس کے سامنے رکھیں۔ پرانے Docker releases میں اسی L2 segment پر موجود hosts localhost-published ports تک پہنچ سکتے تھے۔ اس کے بعد authorization header کے بغیر ایک action call test کریں۔ اگر یہ کامیاب ہو جائے تو proxy پر /api، /v1 اور /mcp کو ان addresses تک محدود کریں جو آپ کے agents استعمال کرتے ہیں، یہاں تک کہ صرف authenticated calls کامیاب ہوں۔

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

موجودہ releases اضافی شرائط کے ساتھ modified Apache 2.0 license استعمال کرتے ہیں؛ v1.9.4 تک کے releases، جن میں pinned v1.3.3 بھی شامل ہے، Apache 2.0 کے تحت رہتے ہیں۔ موجودہ license کے تحت ایسا hosted یا managed connector service جس کی بنیادی قدر OpenConnector کی functionality ہو، OOMOL سے commercial license کا تقاضا کرتا ہے۔ v1.3.3 کی installation commands 1 August 2026 کی snapshot ہیں، اور یہ release 30 July 2026 کو جاری ہوا تھا۔ اسے release tag پر pinned حالت میں چلائیں، کبھی بھی latest یا tip پر نہیں، ہر upgrade سے پہلے release notes پڑھیں، اور volume کا ایسا backup رکھیں جسے آپ نے ایک بار restore کر کے جانچا ہو۔ یہ design آپ کی ملکیت والے server کے لیے مناسب ہے؛ خطرہ architecture نہیں بلکہ version churn ہے۔