Jihost Open Connector kwa AI agents bila SaaS token

Kazi ya Open Connector kwa ajili ya AI agent

Self-hosting ya Open Connector huweka lango moja la uthibitishaji (auth gateway) kati ya AI agents zako na kila API ya software as a service (SaaS) wanayoiita, ili agent asiwahi kushikilia token ya mtoa huduma. Hili ni lango lenye source-available kutoka OOMOL Lab, ambalo kwa sasa lina leseni chini ya Apache 2.0 iliyorekebishwa yenye masharti ya ziada. Matoleo (releases) hadi v1.9.4 yanasalia kuwa Apache 2.0; toleo la v1.9.5 lilianzisha mabadiliko hayo. Kutoa huduma iliyohostiwa au kusimamiwa ambayo thamani yake kuu ni utendaji wa OpenConnector kunahitaji leseni ya kibiashara kutoka OOMOL. Inafanya kazi kama container moja, huhifadhi hali yake (state) kwenye faili moja la SQLite, na hufichua vitendo vya mtoa huduma kupitia HTTP na kupitia MCP (model context protocol).

Changamoto huanza kwenye integration ya pili. Kila mtoa huduma ana mtiririko wake wa OAuth (open authorization), muda wake wa kuishi wa refresh token, na majina yake ya scope. Kuunganisha watoa huduma watano kwenye agent kwa mikono inamaanisha kuwa na redirect handlers tano, hifadhi za vitambulisho (credential stores) tano, na mizunguko ya refresh tano ambayo lazima iendeshwe kabla token haijaisha muda wake. Karibu hakuna mtu anayeandika code hiyo. Wao hutengeneza personal access token moja ya muda mrefu kwa kila huduma na kuiweka kwenye config ya agent, faili la environment, au kwenye prompt yenyewe. Token hiyo kisha inaweza kusomwa na kila zana (tool) inayotumiwa na agent, na huishia kwenye transcript, jambo ambalo ni kosa linaloelezewa katika kuzuia siri zisivuje kwenye AI agents.

Lango la uthibitishaji hugawanya kitambulisho katika sehemu mbili. Lango huhifadhi kitambulisho cha mtoa huduma na kuendesha mtiririko wa OAuth. Agent hupata runtime token ambayo ni halali tu dhidi ya lango hilo. Wakati agent anapoiita hatua (action), lango hupakia kitambulisho kilichohifadhiwa, hukiingiza kwenye ombi la nje (outbound request) upande wa seva, na kurudisha mwili wa jibu pekee. Agent hawahi kupokea access token ya mtoa huduma, kwa hivyo transcript ya agent iliyovuja inakugharimu runtime token moja inayoweza kufutwa badala ya akaunti yako ya GitHub.

Katalogi inatangaza zaidi ya watoa huduma 1,000 na vitendo 10,000 vilivyotengenezwa awali, ambayo ni takwimu ya mradi wenyewe na si kitu unachoweza kukithibitisha kutoka nje. Unachoweza kuthibitisha ni muundo wake: HTTP endpoint moja kwa kila hatua, connection moja iliyohifadhiwa kwa kila mtoa huduma, na token moja kwa kila agent. Ikiwa upande wa agent wa jambo hili bado ni mpya na istilahi kama tool call au MCP server bado hazijatulia, njia iliyopangwa katika jinsi ya kujifunza AI agents kuanzia mwanzo hujenga mzunguko, zana, na tabia za usalama ambazo lango kama hili huchukulia kuwa tayari unazo.

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 unayemwunganisha. Refresh token ya Google au GitHub ni ufunguo wa muda mrefu wa kufikia barua pepe na hazina zako za code. Kuvamiwa kwa huduma hiyo kunamaanisha kuvamiwa kwa akaunti zako. 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 unayotoa kwa mwenyeji wa password manager: firewall inayofungua port 443 pekee, kutotumia logins za pamoja, backup ambayo umewahi kuijaribu kuirejesha, na tahadhari wakati seva inapoacha kujibu. Ikiwa huwezi kuweka vault yako ya password kwenye mashine hii, usiiweke pia connector hiyo.

Funga toleo kabla ya kusakinisha chochote

Open Connector bado ni changa. Mwongozo huu unatumia v1.3.3, iliyochapishwa tarehe 30 Julai 2026, kama snapshot ya usakinishaji wa tarehe 1 Agosti 2026. Hili si toleo jipya zaidi tena. 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 agent wako anategemea, na utatumia jioni nzima kutatua tatizo hilo ukidhani ni tatizo la agent. 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 mwenyewe

Kabla ya container kuanza unahitaji:

• Docker Engine 28.0.0 au mpya zaidi ikiwa na Compose plugin, kwenye Ubuntu 24.04 au mfumo unaofanana na huo
• 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, zilizozalishwa 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, upo kwenye mwongozo wa n8n kwenye VPS yenye Docker na HTTPS.

Zalisha siri hizo kwanza. Encryption key hufunga vitambulisho vilivyohifadhiwa. Admin token hulinda dashibodi ya wavuti na eneo lote la /api. Hakuna thamani chaguo-msingi kwa yoyote kati ya hizi, 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. Encryption key haina njia ya kurejesha data, na sababu ya hilo iko kwenye orodha ya makosa hapo chini.

Sasa compose.yaml. Inatofautiana na mfano wa asili katika sehemu mbili, na zote 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 asili huchapisha 3000:3000, ambayo huunganisha kila interface kwenye host. Docker huandika ports zilizochapishwa kwenye jedwali la NAT (network address translation) kabla ya mnyororo wa kichujio cha ufw kuona pakiti hiyo, kwa hivyo ufw deny 3000 haifungi port hiyo, mtego ulioelezwa katika 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 kwa host hiyohiyo. Kabla ya Docker Engine 28.0.0, hosts kwenye L2 segment moja zingeweza kufikia ports zilizochapishwa kwenye localhost, ndiyo sababu mwongozo huu unahitaji toleo la 28.0.0 au jipya zaidi.

:? huashiria kila variable kuwa ni ya lazima, kwa hivyo stack hukataa kuanza wakati .env haipo badala ya kuanza na vitambulisho visivyolindwa. Kuhifadhi thamani katika .env badala ya faili ya compose ni mbinu inayotoka kwenye Docker Compose env files na secrets. Weka /v1 na /mcp zikiwa za siri kwenye reverse proxy hadi utakapounda token ya kwanza ya runtime hapa chini.

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 } mara tu runtime inapokuwa tayari. ss lazima ichapishe 127.0.0.1:3000. Mstari unaosomeka 0.0.0.0:3000 unamaanisha kuwa msikilizaji amefungwa kwenye kila IPv4 interface, lakini haithibitishi kama inafikika kutoka Internet: firewalls za nje au sheria katika mnyororo wa DOCKER-USER wa Docker bado zinaweza kuzuia trafiki ya nje. "Connection refused" kwenye health check inamaanisha kuwa container bado haijasikiliza, 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 callback za OAuth zinahitaji origin sahihi

OOMOL_CONNECT_ORIGIN ni mpangilio ambao watu huuruka, na kuuruka huko kunavunja OAuth kwa namna inayoonekana kama hitilafu ya mtoa huduma. Runtime hujenga redirect URI yake kutoka kwa origin hiyo, katika mfumo wa <origin>/oauth/callback. Ikiachwa bila kuwekwa, origin huwa http://localhost:3000 kwa chaguo-msingi, 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 zinatofautiana, 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, kwa hivyo anwani lazima iweze kufikiwa na kivinjari hicho. OAuth haihitaji hostname ya umma kila wakati: OpenConnector inaelezea callback za GitHub kwenye http://localhost:3000/oauth/callback. Deployment hii ya VPS hutumia hostname na cheti ili kivinjari kifike kwenye gateway katika origin yake ya HTTPS. Weka origin kabla ya kuanza kwa mara ya kwanza, kwa sababu thamani hiyo husomwa wakati wa kuanzisha mfumo: baada ya kuhariri .env au compose.yaml, endesha docker compose up -d tena ili kuitekeleza.

Unganisha provider wako wa kwanza kupitia OAuth

Kwanza, unda OAuth app kwenye provider. Kwenye GitHub, fuata Settings, kisha Developer settings, kisha OAuth Apps, halafu New OAuth App. Weka authorization callback URL iwe https://connect.example.com/oauth/callback. Hifadhi client ID na client secret.

Kila ombi la /api hubeba admin token, kwa hiyo i-export mara moja kwa 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 provider. Hii ndiyo njia ya haraka zaidi ya kuthibitisha kuwa origin yako imetumika. Ikiwa bado inaonyesha localhost, container inaendesha kwa value ya zamani na OAuth flow itashindwa kwenye hatua ya mwisho.

Hifadhi client credentials, kisha uanzishe 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"}'

Ombi la pili linarudisha authorizationUrl. Ifungue kwenye browser, kubali scopes, na provider itairudisha browser kwenye /oauth/callback, ambako runtime hubadilisha code na kuhifadhi credential. Web console kwenye origin yako hupitia hatua hizo hizo kwa kutumia form, chini ya admin token hiyo hiyo. Providers wanaotumia API key ya kawaida huruka hatua hizi zote: PUT /api/connections/<service> kwa {"authType":"api_key","values":{"apiKey":"..."}} huhifadhi key moja kwa moja.

Mpe kila wakala token ya muda wa utekelezaji, usimpe kamwe kitambulisho cha siri

Wakala hujitambulisha kwenye gateway kwa kutumia token ya muda wa utekelezaji, 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 huyo, kwa sababu kufuta token usiyoweza kuitambua kunamaanisha kufuta token zote. Wakala kisha hupiga hatua za utekelezaji 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 ukiwa na bearer header ileile, na gateway hutoa zana za ugunduzi kama vile 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 kusema umemaliza. Rudia wito wa utekelezaji huku header ya authorization ikiwa imefutwa. Mwongozo wa kuanza haraka wa mradi huu hupiga /v1 bila bearer yoyote, kwa hivyo usakinishaji ambao haujasanidiwa uthibitishaji wa muda wa utekelezaji utatekeleza hatua kwa yeyote anayeweza kufikia port hiyo. Ikiwa wito wako usio na uthibitishaji utafanikiwa, una njia mbili za kutatua: sanidi token za muda wa utekelezaji na uthibitishe kuwa wito wa bila utambulisho sasa unashindwa, au zuia /api, /v1 na /mcp kwenye reverse proxy kwa anwani ambazo mawakala wako wanatokea. /oauth/callback lazima iweze kufikiwa na kivinjari kinachokamilisha uthibitishaji; si lazima iwe wazi kwa Internet nzima.

Punguza orodha ya vitendo hadi vile wakala anavyohitaji

Gateway yenye providers elfu moja nyuma yake ina sehemu kubwa ya mashambulizi unapoiunganisha na language model. Sehemu hiyo huwa kubwa zaidi model inapoanza kusoma maandishi ambayo haikuandika, kwa sababu ukurasa unaorejeshwa na SearXNG instance yako yenyewe inayojibu utafutaji wa wavuti wa wakala unaweza kuwa na maagizo yanayolenga vitendo vyovyote ambavyo wakala inaruhusiwa kufanya. Udhibiti huohuo unaomfanya coding agent afanye mabadiliko madogo zaidi yanayotosha unapaswa kutumika kwenye permissions zake: ruhusu vitendo vichache ambavyo kazi inahitaji, na usiruhusu vingine. Controls mbili hupunguza wigo huo.

OOMOL_CONNECT_ALLOWED_ACTIONS hupokea allowlist iliyotenganishwa kwa koma na inaelewa service.* na *. OOMOL_CONNECT_BLOCKED_ACTIONS ni denylist, na denylist huwa na kipaumbele. Kuweka allowlist kuwa github.get_current_user,github.list_issues kunamaanisha kila action nyingine inakataliwa bila kujali wakala anaomba nini. Hii ndiyo tofauti kati ya kosa na tukio la usalama. Runtime tokens huwa na action rules zao juu ya rules za jumla, na orodha yao ya allowedProxies huanza ikiwa tupu. Kwa hiyo, POST /v1/proxy/:service inakataliwa hadi uiruhusu. Proxy endpoint hiyo hupeleka raw request kwa provider ikiwa na credential yako. Iache ikiwa tupu isipokuwa agent mmoja mahususi anaihitaji.

OOMOL_CONNECT_ALLOW_PRIVATE_NETWORK huwa false kwa chaguo-msingi. Hii huzuia muunganisho wa self-hosted provider kuelekezwa kwenye anwani ya faragha kama cloud metadata service iliyo kwenye 169.254.169.254, au database yako iliyo kwenye network hiyo hiyo. Iache ikiwa imezimwa. Iwashe tu kwa provider unayohost mwenyewe.

Hifadhi nakala ya seva inayohifadhi tokeni zote

Mambo mawili ni muhimu, na kila moja haliwezi kutumika bila jingine. Database iliyo kwenye /app/data/connect.sqlite ndani ya volume ya connector-data huhifadhi credentials zilizofungwa kwa usimbaji. Key ya usimbaji iliyo kwenye .env huzifungua. Backup ya volume bila key haiwezi kurejesha chochote, na key bila volume haiwezi kurejesha chochote. Kwa hiyo, weka key kwenye password manager yako, na ujumuishe volume katika mzunguko wako wa kawaida wa backup.

Simamisha container unapokopi faili ya SQLite, kwa sababu nakala inayochukuliwa wakati wa uandishi inaweza kurejeshwa ikiwa database imeharibika.

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 directory ya project yako pamoja na _connector-data. Ndiyo sababu command ya kwanza ipo hapo: bandika jina halisi kwenye command ya tatu. Tuma archive nje ya VPS kwa kutumia backups za restic kutoka VPS, ambayo huisimba kabla haijaondoka, kwa sababu archive hiyo ndiyo credential store.

Runtime huhifadhi recent action runs kama audit records, 5,000 kwa chaguo-msingi. Hivyo, console inaweza kukuonyesha agent gani iliendesha kitendo gani na wakati gani. Log hiyo ndiyo kitu cha kwanza kusoma agent inapofanya kazi kwa njia isiyo ya kawaida. Elekeza status page ya Uptime Kuma kwenye https://connect.example.com/health pia. Gateway inapoacha kujibu, agents hushindwa kwa njia zinazochanganya. Kujua kwamba gateway iko chini kunaweza kuokoa saa moja ya kusoma agent output.

Kinachoharibika, na ujumbe utakaoona

redirect_uri_mismatch kwa mtoa huduma. Origin na URL ya callback iliyosajiliwa hazilingani. Linganisha mfuatano kamili kutoka /api/oauth/configs na mipangilio ya programu kwa mtoa huduma, ukijumuisha https dhidi ya http pamoja na slash yoyote ya mwisho.

Kila mwito wa /api unarudisha 401. Kichwa cha tokeni ya msimamizi hakipo au kimeandikwa vibaya. Kichwa hicho ni Authorization: Bearer <token>, na web console inaomba tokeni hiyo hiyo.

Container inaendelea, na credentials ziko kwenye plain text. Hili hutokea wakati OOMOL_CONNECT_ENCRYPTION_KEY haifiki kwenye container, kwa sababu runtime huhifadhi rekodi za credentials bila encryption badala ya kukataa kuanza. Thibitisha hili kwenye installation yako mwenyewe: unganisha provider kwa kutumia API key unayoweza kuitambua, kisha itafute 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 key haitumiki, kwa hiyo hakikisha .env iko kwenye directory moja na compose.yaml na kwamba docker compose config inaonyesha value hiyo. Key ikiwekwa, utafutaji huohuo hurudisha 0, kwa sababu rekodi imefungwa kwa AES-256-GCM (advanced encryption standard, key ya bits 256, Galois/counter mode).

Hakuna kinachoweza kufanya decryption baada ya restore. Encryption key imebadilika au imepotea. Haiandikwi kamwe karibu na data, kwa muundo wa mfumo, kwa hiyo hakuna njia ya recovery wala support ticket inayoweza kusaidia. Unganisha tena kila provider. Rotation inatumia variable tofauti ya key na data command ndani ya runtime, kwa hiyo soma release notes za release ya sasa kabla ya kufanya rotation yoyote.

Agent inapata error inayotaja action ambayo inaweza kuona kwenye catalog. Discovery na execution ni hatua tofauti. Action inaweza kuonekana kwenye search_actions na bado ikakataliwa na OOMOL_CONNECT_ALLOWED_ACTIONS, na denylist, au na rules za tokeni hiyo ya runtime.

Upgrades. Fanya backup ya volume, badilisha image tag iwe release mpya, kisha docker compose pull && docker compose up -d. Monitor docker compose logs -n 50 connector uone mstari wa migration, halafu endesha tena health check na action moja halisi kabla ya kuanza kuiamini tena. Kurudisha toleo la zamani kunamaanisha kuweka tena tag ya zamani, jambo linalowezekana kwa sababu uliipin.

FAQ

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

Kwa watoa huduma wanaotumia API key, hapana: gateway kwenye 127.0.0.1 inatosha. OAuth pia haihitaji domain ya umma kila wakati: OpenConnector inaelekeza callback ya ndani ya GitHub kama http://localhost:3000/oauth/callback. Kivinjari kinachokamilisha uthibitishaji lazima kifike kwenye URL ya callback. Kwa deployment hii ya VPS, weka OOMOL_CONNECT_ORIGIN kwenye hostname yako ya https:// kabla ya kuanza mara ya kwanza, na usajili <origin>/oauth/callback katika OAuth app ya mtoa huduma.

Nini kitatokea nikipoteza encryption key ya Open Connector?

Credentials zilizohifadhiwa haziwezi kusomwa, na hakuna njia ya kuzirejesha. Ufunguo huu hauhifadhiwi kamwe pamoja na data kwa makusudi, ili mtu yeyote anayeshikilia database asiweze kuusoma, 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 urejeshaji unahitaji vyote viwili.

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

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

Je, gateway inapaswa kufikika kutoka kwenye mtandao wa umma?

OAuth callback lazima ifikike na kivinjari kinachokamilisha uthibitishaji, jambo ambalo halihitaji ufikiaji kutoka kwa mtandao mzima. Kwa Docker Engine 28.0.0 au mpya zaidi na default bridge networking, chapisha (publish) port ya container kwenye 127.0.0.1 ili kuweka port iliyochapishwa ifikike kutoka kwa host pekee, na uweke reverse proxy mbele. Matoleo ya zamani ya Docker yaliruhusu hosts kwenye L2 segment moja kufikia port zilizochapishwa kwenye localhost. Kisha jaribu action call moja bila header ya authorization. Ikiwa itafanikiwa, zuia /api, /v1 na /mcp kwenye proxy kwa anwani zinazotumiwa na agents wako hadi pale simu zilizothibitishwa pekee ndizo zitakazofanya kazi.

Je, Open Connector iko tayari kwa matumizi ya production?

Matoleo ya sasa yanatumia leseni ya Apache 2.0 iliyorekebishwa yenye masharti ya ziada; matoleo hadi v1.9.4, ikiwemo v1.3.3 iliyopiniwa, yanasalia kuwa Apache 2.0. Huduma ya connector inayohudumiwa au kusimamiwa ambayo thamani yake kuu ni utendaji wa OpenConnector inahitaji leseni ya kibiashara kutoka OOMOL chini ya leseni ya sasa. Amri za usakinishaji za v1.3.3 zinasalia kuwa snapshot ya 1 Agosti 2026, na toleo hilo lilitolewa tarehe 30 Julai 2026. Iendeshe ikiwa imepiniwa kwenye release tag, kamwe usiiendeshe kwenye latest au tip, soma maelezo ya toleo kabla ya kila upgrade, na uweke backup ya volume ambayo umewahi kuirejesha mara moja. Usanifu huu ni thabiti kwa seva unayomiliki, na hatari ni mabadiliko ya matoleo, si usanifu wenyewe.