Jinsi ya kujiendeshea Open Connector kwa mawakala wa AI

Kazi ya Open Connector kwa wakala wa AI

Kujiendeshea Open Connector kunakuwekea lango moja la uthibitishaji (auth gateway) kati ya mawakala wako wa AI na kila API ya programu kama huduma (SaaS) wanayoiita, ili wakala asishike kamwe token ya mtoa huduma. Hili ni lango la chanzo huria kutoka OOMOL Lab, lenye leseni ya Apache 2.0. Huendeshwa kama kontena moja, huhifadhi hali yake kwenye faili moja ya SQLite, na hutoa vitendo vya mtoa huduma kupitia HTTP na MCP (model context protocol).

Maumivu huanza kwenye muunganisho wa pili. Kila mtoa huduma ana mtiririko wake wa OAuth (open authorization), muda wake wa uhai wa refresh token, na majina yake ya scope. Kuunganisha watoa huduma watano kwenye wakala kwa mkono kunamaanisha vishikiliaji vitano vya redirect, hifadhi tano za vitambulisho, na mizunguko mitano ya refresh ambayo lazima iendeshwe kabla token haijaisha muda wake. Karibu hakuna mtu anayeandika msimbo huo. Wao hutengeneza token moja ya muda mrefu ya ufikiaji wa kibinafsi kwa kila huduma na kuibandika kwenye usanidi wa wakala, faili ya mazingira, au kwenye prompt yenyewe. Token hiyo kisha inaweza kusomeka na kila zana inayotumiwa na wakala, na huishia kwenye transcript, jambo ambalo ni kosa linaloelezwa katika kuepuka siri katika mawakala wa AI.

Lango la uthibitishaji hugawanya kitambulisho katika sehemu mbili. Lango huhifadhi kitambulisho cha mtoa huduma na kuendesha mtiririko wa OAuth. Wakala hupata token ya wakati wa utekelezaji (runtime token) ambayo ni halali tu dhidi ya lango. Wakati wakala anapoiita hatua fulani, lango hupakia kitambulisho kilichohifadhiwa, hukiingiza kwenye ombi la nje upande wa seva, na kurudisha mwili wa jibu pekee. Wakala hapokei kamwe token ya ufikiaji ya mtoa huduma, kwa hivyo transcript ya wakala iliyovuja inakugharimu token moja ya wakati wa utekelezaji inayoweza kubatilishwa badala ya akaunti yako ya GitHub.

Katalogi inatangaza zaidi ya watoa huduma 1,000 na vitendo 10,000 vilivyojengwa awali, ambayo ni takwimu ya mradi wenyewe na si kitu unachoweza kukithibitisha kutoka nje. Unachoweza kuthibitisha ni umbo lake: endpoint moja ya HTTP kwa kila hatua, muunganisho mmoja ulihifadhiwa kwa kila mtoa huduma, na token moja kwa kila wakala.

Kwa nini uweke Open Connector kwenye seva yako badala ya kutumia huduma ya nje

Huduma ya nje ya connector hufanya kazi ileile, na huhifadhi refresh tokens kwa kila mtoa huduma unayemuunganisha. Refresh token ya Google au GitHub ni ufunguo wa muda mrefu wa kufikia barua pepe na hazina zako za msimbo (repositories), na kwa kawaida haufutiki hata ukibadilisha nenosiri. Uvunjifu wa usalama kwao unakuwa ni uvunjifu kwako. Kujiwekea huduma hii mwenyewe huhamishia rekodi hizo kwenye SQLite ndani ya mashine unayokodisha na kuisimamia, ikiwa imefungwa kwa ufunguo ambao hautoki kamwe kwenye seva yako.

Taja gharama zake kwa sauti kabla ya kuanza. VPS hii inakuwa seva yenye thamani zaidi unayoiendesha. Inashikilia vitambulisho vya huduma nyingi katika faili moja, kwa hivyo inastahili matunzo unayopea seva ya kuhifadhi nenosiri: firewall inayofungua mlango wa 443 pekee, hakuna akaunti za pamoja, nakala rudufu (backup) ambayo umewahi kuirejesha angalau mara moja, na tahadhari pale inapoacha kujibu. Ikiwa huwezi kuweka vault yako ya nenosiri kwenye mashine hii, basi usiweke pia connector hii.

Funga toleo kabla ya kusakinisha chochote

Open Connector bado ni mpya. Hifadhi hii ilionekana kwa mara ya kwanza tarehe 29 Juni 2026, na kufikia tarehe 1 Agosti 2026 toleo jipya zaidi lililowekewa tag ni v1.3.3, lililochapishwa tarehe 30 Julai 2026 na pia likiwa na tag ya latest. Rejesta huchapisha pia tag ya tip, iliyojengwa kutoka kwa commit mpya zaidi kwenye main.

Katika mradi mpya kama huu, tag zinazobadilika hubadilika mara kwa mara. docker compose pull inayoruka matoleo mawili inaweza kubadilisha endpoint ambayo wakala wako anategemea, na utatumia jioni nzima kutatua tatizo hilo ukidhani ni tatizo la wakala. Funga image kwenye tag ya toleo husika, na ufanye upgrade wakati unapoamua, baada ya kusoma maelezo ya toleo (release notes).

Kuweka Open Connector nyuma ya TLS kwenye VPS yako

Kabla ya container kuanza, unahitaji:

• Docker yenye Compose plugin, kwenye Ubuntu 24.04 au toleo linalofanana na hilo
• hostname ambayo A record yake inaelekeza kwenye VPS hii, kwa mfano connect.example.com
• reverse proxy ambayo tayari inashughulikia TLS (transport layer security) kwa hostname hiyo
• siri mbili (secrets) nasibu, zilizotengenezwa hapa chini

Mwongozo wa Traefik reverse proxy kwa programu nyingi za Docker Compose unaelezea upande wa proxy. Usanidi kamili wa cheti, kuanzia mwanzo hadi mwisho kwa programu moja, unapatikana kwenye mwongozo wa n8n kwenye VPS yenye Docker na HTTPS.

Tengeneza siri hizo kwanza. Ufunguo wa encryption (encryption key) hufunga vitambulisho vilivyohifadhiwa. Token ya admin hulinda console ya wavuti na eneo zima la /api. Hakuna thamani chaguo-msingi, na runtime huanza bila matatizo hata kama hazijawekwa.

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

Nakili thamani zote mbili kwenye kidhibiti chako cha nywila sasa, kabla ya kuanza kwa mara ya kwanza. Ufunguo wa encryption hauna njia ya kurejesha data, na sababu ya hilo iko kwenye orodha ya makosa hapa chini.

Sasa compose.yaml. Inatofautiana na mfano wa upstream katika maeneo mawili, na yote ni muhimu.

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:

Mabadiliko ya kwanza ni kutumia tag maalum badala ya latest. La pili ni port. Faili ya upstream huchapisha 3000:3000, ambayo hufungua interface zote kwenye host. Docker huandika ports zilizochapishwa kwenye jedwali la NAT (network address translation) kabla ya mnyororo wa kichujio wa ufw kuona pakiti, kwa hivyo ufw deny 3000 haifungi port hiyo, mtego ulioelezwa kwenye kwa nini ports za Docker hupita ufw. Kuandika 127.0.0.1:3000:3000 huchapisha kwenye loopback interface pekee, na reverse proxy yako huunganisha kutoka kwenye host hiyo hiyo.

:? huashiria kila variable kuwa ni ya lazima, kwa hivyo stack hukataa kuanza wakati .env haipo badala ya kuanza na vitambulisho visivyolindwa. Kuhifadhi thamani kwenye .env badala ya faili ya compose ni utaratibu kutoka kwenye faili za Docker Compose env na siri.

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 hujibu { "ok": true } pindi runtime inapokuwa tayari. ss lazima ichapishe 127.0.0.1:3000. Mstari unaosomeka 0.0.0.0:3000 unamaanisha kuwa ramani ya port bado ni ile ya upstream, na gateway inajibu Internet nzima moja kwa moja. "Connection refused" kwenye ukaguzi wa afya (health check) inamaanisha kuwa container haijasikiliza bado, kwa hivyo soma logi kabla ya kugusa proxy.

    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"

Kwa nini OAuth inakulazimisha uwe na hostname halisi

OOMOL_CONNECT_ORIGIN ni mpangilio ambao watu huuruka, na kuuruka huko huvunja OAuth kwa namna inayoonekana kama hitilafu ya mtoa huduma. Runtime hujenga redirect URI yake kutoka kwa asili hiyo, katika mfumo wa <origin>/oauth/callback. Ikiachwa bila kuwekwa, asili hiyo huwa http://localhost:3000, kwa hivyo runtime hutuma kwa mtoa huduma redirect URI ya http://localhost:3000/oauth/callback wakati programu yako ya OAuth imesajili https://connect.example.com/oauth/callback. Kamba hizo mbili ni tofauti, kwa hivyo GitHub hujibu:

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

Mtoa huduma wa OAuth huelekeza kivinjari kurudi kwenye URI hiyo, jambo linalomaanisha kuwa lazima iwe anwani ambayo ulimwengu wa nje unaweza kuifikia, na watoa huduma hukataa http:// ya kawaida kwa chochote isipokuwa localhost. Hiyo ndiyo sababu nzima kwa nini deployment hii inahitaji hostname na cheti. Weka asili (origin) kabla ya kuanza kwa mara ya kwanza, kwa sababu thamani hiyo husomwa wakati wa kuanza: baada ya kuhariri .env au compose.yaml, endesha docker compose up -d tena ili kuitekeleza.

Unganisha mtoa huduma wako wa kwanza kupitia OAuth

Unda programu ya OAuth kwa mtoa huduma kwanza. Kwenye GitHub, njia ni Settings, kisha Developer settings, kisha OAuth Apps, kisha New OAuth App. Weka URL ya callback ya idhini kuwa https://connect.example.com/oauth/callback. Hifadhi client ID na client secret.

Kila wito wa /api hubeba token ya admin, kwa hivyo i-export mara moja kwa ajili ya session ya shell.

export ADMIN_TOKEN='paste-the-admin-token'
curl -s https://connect.example.com/api/oauth/configs \
  -H "authorization: Bearer $ADMIN_TOKEN"

Orodha hiyo inaonyesha redirect URI ambayo runtime inatarajia kwa kila mtoa huduma, jambo linaloifanya kuwa njia ya haraka zaidi ya kuhakikisha kuwa origin yako imefanya kazi. Ikiwa bado inasema localhost, container inaendeshwa kwa kutumia thamani ya zamani na mchakato wa OAuth utafeli katika hatua ya mwisho.

Hifadhi vitambulisho vya client, kisha anza idhini.

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

Wito wa pili unarudisha authorizationUrl. Ifungue kwenye kivinjari, kubali scopes, na mtoa huduma atarudisha kivinjari kwenye /oauth/callback, ambapo runtime hubadilishana code na kuhifadhi kitambulisho. Web console kwenye origin yako hupitia hatua zilezile kwa kutumia fomu, nyuma ya token ileile ya admin. Watoa huduma wanaotumia API key ya kawaida huruka hatua hizi zote: PUT /api/connections/<service> pamoja na {"authType":"api_key","values":{"apiKey":"..."}} huhifadhi key moja kwa moja.

Mpe kila wakala token ya runtime, usitumie kamwe kitambulisho cha siri

Wakala hujitambulisha kwenye gateway kwa kutumia token ya runtime, ambayo admin API hutengeneza.

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

Jibu hubeba token inayoanza na oct_. Toa token moja kwa kila wakala na uipe jina la wakala husika, kwa sababu kufuta token usiyoweza kuitambua inamaanisha kufuta token zote. Wakala kisha hupiga simu za vitendo (actions) kupitia HTTP ya kawaida.

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

Jibu sahihi ni bahasha ambayo uwanja wake wa success ni true, ikiwa na payload ya mtoa huduma chini ya data. Token ya GitHub haipo popote kwenye jibu hilo. Kwa mteja wa MCP, ielekeze kwenye https://connect.example.com/mcp ukitumia bearer header ileile, na gateway hutoa zana za ugunduzi kama search_actions na execute_action badala ya zana moja kwa kila API, jambo linalofanya orodha ya zana za wakala kuwa ndogo. Kuendesha seva za MCP kwenye VPS inashughulikia nusu ya mteja ya muunganisho huo.

Fanya ukaguzi mmoja zaidi kabla ya kuhitimisha kazi hii. Rudia simu ya kitendo huku header ya authorization ikiwa imeondolewa. Quickstart ya mradi huu huita /v1 bila bearer yoyote, kwa hivyo usakinishaji ambao haujasanidiwa uthibitishaji wa runtime utatekeleza vitendo kwa yeyote anayeweza kufikia port hiyo. Ikiwa simu yako isiyo na uthibitishaji itafanikiwa, una njia mbili za kutatua: sanidi token za runtime na uthibitishe kuwa simu isiyojulikana (anonymous call) sasa inafeli, au zuia /api, /v1 na /mcp kwenye reverse proxy kwa anwani ambazo mawakala wako wanatoka. /oauth/callback pekee ndiyo inapaswa kubaki wazi kwa ulimwengu, kwa sababu hiyo ndiyo njia pekee ambayo redirect ya kivinjari cha mtoa huduma inahitaji.

Punguza orodha ya vitendo kulingana na mahitaji ya wakala

Lango lenye watoa huduma elfu moja nyuma yake ni eneo pana la kumpa mfano wa lugha (language model). Vidhibiti viwili hupunguza eneo hili.

OOMOL_CONNECT_ALLOWED_ACTIONS huchukua orodha ya kuruhusiwa (allowlist) iliyotenganishwa kwa koma na inaelewa service.* na *. OOMOL_CONNECT_BLOCKED_ACTIONS ni orodha ya kuzuia (denylist), na orodha ya kuzuia ndiyo yenye nguvu zaidi. Kuweka orodha ya kuruhusiwa kuwa github.get_current_user,github.list_issues inamaanisha kila kitendo kingine kitakataliwa bila kujali wakala anaomba nini, jambo ambalo ndilo tofauti kati ya kosa la kawaida na tukio la kiusalama (incident). Tokeni za wakati wa utekelezaji (runtime tokens) hubeba sheria zao za vitendo juu ya zile za kimataifa, na orodha yao ya allowedProxies huanza ikiwa tupu, kwa hivyo POST /v1/proxy/:service hukataliwa hadi utakapoiruhusu. Endpoint hiyo ya proksi husambaza ombi ghafi kwa mtoa huduma ikiwa na kitambulisho chako kimeambatishwa, kwa hivyo iache ikiwa tupu isipokuwa kama wakala mmoja mahususi anaihitaji.

OOMOL_CONNECT_ALLOW_PRIVATE_NETWORK kwa kawaida huwa false, ambayo huzuia muunganisho wa mtoa huduma aliyejiwekea mwenyewe (self-hosted) kuelekeza kwenye anwani ya kibinafsi kama vile huduma ya metadata ya wingu kwenye 169.254.169.254, au hifadhidata yako kwenye mtandao uleule. Iache ikiwa imezimwa. Iwashe tu kwa mtoa huduma unayejiwekea mwenyewe.

Hifadhi nakala ya seva inayoshikilia kila token

Mambo mawili ni muhimu, na kila moja halina faida bila lingine. Hifadhidata iliyo kwenye /app/data/connect.sqlite ndani ya volume ya connector-data inashikilia vitambulisho vilivyofungwa (sealed credentials). Ufunguo wa usimbaji (encryption key) uliopo kwenye .env ndio unaovifungua. Nakala ya volume bila ufunguo hairejeshi chochote, na ufunguo bila volume haurejeshi chochote; kwa hivyo, ufunguo unapaswa kuhifadhiwa kwenye password manager yako na volume iingizwe kwenye utaratibu wako wa kawaida wa kuhifadhi nakala (backup rotation).

Simamisha container wakati unanakili faili ya SQLite, kwa sababu nakala inayochukuliwa wakati wa uandishi inaweza kurejeshwa kama hifadhidata iliyoharibika.

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

Jina la volume ni saraka ya mradi wako ikijumuisha _connector-data, ndiyo maana amri ya kwanza iko hapo: bandika jina halisi kwenye amri ya tatu. Tuma kumbukumbu (archive) nje ya VPS kwa kutumia restic backups from a VPS, ambayo inaisimba kwa njia fiche kabla haijaondoka, kwa sababu kumbukumbu hiyo ndiyo hifadhi ya vitambulisho.

Runtime huhifadhi matendo ya hivi karibuni kama rekodi za ukaguzi (audit records), 5,000 kwa chaguo-msingi, ili console iweze kukuambia ni agent yupi aliyefanya nini na lini. Logi hiyo ndiyo kitu cha kwanza kusoma wakati agent anafanya kazi kwa njia isiyo ya kawaida. Elekeza an Uptime Kuma status page kwenye https://connect.example.com/health pia. Lango (gateway) linapoacha kujibu, agents hushindwa kufanya kazi kwa njia zinazochanganya, na kujua kuwa lango limezimika huokoa saa nzima ya kusoma matokeo ya agent.

Nini kinaharibika, na ujumbe utakaouona

redirect_uri_mismatch kwa mtoa huduma. Origin na URL ya callback iliyosajiliwa hazilingani. Linganisha mfuatano kamili wa herufi kutoka /api/oauth/configs dhidi ya mipangilio ya programu ya mtoa huduma, ikijumuisha https dhidi ya http na alama yoyote ya mkwaju (trailing slash) mwishoni.

Kila wito wa /api unarudisha 401. Header ya admin token haipo au imeandikwa vibaya. Header husika ni Authorization: Bearer <token>, na dashibodi ya wavuti huomba token hiyo hiyo.

Container inafanya kazi, na vitambulisho vipo katika maandishi ya kawaida (plain text). Hivi ndivyo hutokea wakati OOMOL_CONNECT_ENCRYPTION_KEY haifiki kwenye container, kwa sababu runtime huhifadhi rekodi za vitambulisho bila kusimbwa badala ya kukataa kuanza. Thibitisha hili kwenye usakinishaji wako: unganisha mtoa huduma ukiwa na API key unayoweza kuitambua, kisha tafuta kwenye database.

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

Hesabu iliyo juu ya 0 inamaanisha kuwa ufunguo (key) haufanyi kazi, kwa hivyo hakikisha .env ipo kwenye saraka (directory) moja na compose.yaml na kwamba docker compose config inaonyesha thamani hiyo. Ufunguo ukiwa umewekwa, utafutaji huo huo utarudisha 0, kwa sababu rekodi imefungwa kwa kutumia AES-256-GCM (advanced encryption standard, 256-bit key, Galois/counter mode).

Hakuna kinachoweza kusomwa (decrypt) baada ya kurejesha data (restore). Ufunguo wa usimbaji (encryption key) ulibadilika au ulipotea. Kwa usanifu wake, hauhifadhiwi kamwe karibu na data, kwa hivyo hakuna njia ya kurejesha na hakuna tiketi ya msaada inayoweza kusaidia. Unganisha upya kila mtoa huduma. Mzunguko wa funguo (rotation) unaruhusiwa kupitia variable tofauti ya ufunguo na amri ya data kwenye runtime, kwa hivyo soma maelezo ya toleo (release notes) la sasa kabla ya kuzungusha chochote.

Agent anapata kosa linalotaja kitendo anachoweza kukiona kwenye catalog. Ugunduzi (discovery) na utekelezaji (execution) ni vitu viwili tofauti. Kitendo kinaweza kuonekana kwenye search_actions na bado kikakataliwa na OOMOL_CONNECT_ALLOWED_ACTIONS, na denylist, au na sheria za token hiyo ya runtime.

Uboreshaji (upgrades). Hifadhi nakala ya volume, hariri image tag kwenda kwenye toleo jipya, kisha docker compose pull && docker compose up -d. Fuatilia docker compose logs -n 50 connector kwa mstari wa uhamiaji (migration line), na uendeshe tena ukaguzi wa afya (health check) na kitendo kimoja halisi kabla ya kuiamini tena. Kurudisha nyuma (rolling back) kunamaanisha kurudisha tag ya zamani, jambo linalofanya kazi kwa sababu uliifunga (pinned) hapo awali.

FAQ

Je, ninahitaji domain ya umma ili ku-self-host Open Connector?

Kwa watoa huduma wanaotumia API key, hapana: gateway iliyo kwenye 127.0.0.1 inatosha. Kwa OAuth, kwa vitendo ni ndiyo. Mtoa huduma huelekeza kivinjari kwenye callback URL yako, kwa hivyo URL hiyo lazima iweze kutatuliwa (resolve) kutoka kwenye Internet ya umma, na watoa huduma hukataa http:// ya kawaida nje ya localhost. Weka OOMOL_CONNECT_ORIGIN kwenye hostname yako ya https:// kabla ya kuanza mara ya kwanza, na usajili <origin>/oauth/callback kwenye OAuth app ya mtoa huduma.

Nini kitatokea nikipoteza encryption key ya Open Connector?

Credentials zilizohifadhiwa haziwezi kusomwa (decrypt), na hakuna njia ya kuzirejesha. Ufunguo huo kwa makusudi hauhifadhiwi kamwe pamoja na data, ili mtu yeyote anayeshikilia database asiweze kuisoma, ikiwemo wewe mwenyewe. Chaguo lako pekee ni kuweka ufunguo mpya na kuunganisha kila mtoa huduma upya. Hifadhi ufunguo kwenye password manager na database kwenye backup rotation yako, kwa sababu restore inahitaji vyote viwili.

Je, AI agent wangu anaweza kuona access token ya mtoa huduma?

Hapana, anapopiga simu kupitia gateway. Agent hujitambulisha kwa runtime token inayoanza na oct_, na gateway huingiza credential ya mtoa huduma kwenye ombi linalotoka (outbound request) kwenye seva, ikirudisha majibu pekee. Mambo mawili huvunja sifa hiyo: endpoint ya /v1/proxy/:service, ambayo husambaza maombi mabichi (raw requests) yakiwa na credential yako imeambatishwa na ambayo grants zake huanza zikiwa tupu kwa sababu maalum, na kuweka API key kwenye agent mwenyewe, jambo ambalo hupita gateway kabisa.

Je, gateway inapaswa kufikika kutoka kwenye Internet ya umma?

/oauth/callback pekee ndiyo inapaswa kufikika. Chapisha container port kwenye 127.0.0.1 ili sheria za NAT za Docker zisiweze kuifichua nje ya firewall yako, na uweke reverse proxy mbele. Kisha jaribu kufanya action call moja bila header ya authorization. Ikiwa itafanikiwa, zuia /api, /v1 na /mcp kwenye proxy kwa anwani zinazotumiwa na agents wako hadi pale ambapo simu zilizothibitishwa (authenticated calls) ndizo pekee zinazofanya kazi.

Je, Open Connector iko tayari kwa matumizi ya production?

Ina leseni ya Apache 2.0 na inakua kwa kasi: repository ilionekana tarehe 29 Juni 2026 na v1.3.3 ilitolewa tarehe 30 Julai 2026, kwa hivyo chukulia kila namba ya version katika mwongozo huu kama snapshot ya tarehe 1 Agosti 2026. Iendeshe ikiwa imefungwa kwenye release tag, kamwe usitumie latest au tip, soma maelezo ya toleo (release notes) kabla ya kila upgrade, na uweke backup ya volume ambayo umewahi kuifanyia restore mara moja. Usanifu wake ni imara kwa seva unayomiliki, na hatari iliyopo ni mabadiliko ya haraka ya version, si usanifu wenyewe.