AI agents க்காக Open Connector-ஐ self-host செய்வது எப்படி

Open Connector AI agent-க்காகச் செய்வது என்ன

Open Connector-ஐ நீங்களே host செய்தால், உங்கள் AI agents மற்றும் அவை அழைக்கும் ஒவ்வொரு software as a service (SaaS) API-க்கும் இடையில் ஒரே auth gateway இருக்கும். இதனால் agent எந்த provider token-ஐயும் வைத்திருக்காது. இது OOMOL Lab உருவாக்கிய open source gateway ஆகும். இது Apache 2.0 உரிமத்தின் கீழ் வெளியிடப்பட்டுள்ளது. இது ஒரு container ஆக இயங்கும். தனது state-ஐ ஒரே SQLite file-ல் வைத்திருக்கும். Provider actions-ஐ HTTP மற்றும் MCP (model context protocol) வழியாக வெளிப்படுத்தும்.

இரண்டாவது integration-இல் சிக்கல் தொடங்குகிறது. ஒவ்வொரு provider-க்கும் தனித்தனி OAuth (open authorization) flow, தனித்தனி refresh token lifetime, தனித்தனி scope names உள்ளன. ஐந்து providers-ஐ agent-இல் கைமுறையாக இணைக்க, ஐந்து redirect handlers, ஐந்து credential stores, மேலும் token காலாவதியாகும் முன் இயங்க வேண்டிய ஐந்து refresh loops தேவைப்படும். இந்த code-ஐ கிட்டத்தட்ட யாரும் எழுதுவதில்லை. அதற்குப் பதிலாக, ஒவ்வொரு service-க்கும் நீண்ட காலம் செல்லுபடியாகும் ஒரு personal access token-ஐ உருவாக்கி, அதை agent config, environment file அல்லது prompt-இல் ஒட்டுகின்றனர். Agent இயக்கும் ஒவ்வொரு tool-க்கும் அந்த token படிக்கக்கூடியதாக இருக்கும். அது transcript-லிலும் இடம்பெறும். இதுவே AI agents-இல் secrets-ஐ வெளியில் வைத்திருத்தல் விவரிக்கும் failure ஆகும்.

Auth gateway credential-ஐ இரண்டு பகுதிகளாகப் பிரிக்கிறது. Gateway provider credential-ஐ சேமித்து, OAuth flow-ஐ இயக்கும். Agent-க்கு gateway-க்கு எதிராக மட்டுமே செல்லுபடியாகும் runtime token கிடைக்கும். Agent ஒரு action-ஐ அழைக்கும்போது, gateway சேமித்த credential-ஐ ஏற்றி, அதை server side-ல் outbound request-இல் சேர்த்து, response body-ஐ மட்டும் திருப்பி அனுப்பும். Agent ஒருபோதும் provider access token-ஐ பெறாது. ஆகவே agent transcript கசியும்போது, உங்கள் GitHub account-ஐ இழப்பதற்குப் பதிலாக revoke செய்யக்கூடிய ஒரு runtime token மட்டுமே பாதிக்கப்படும்.

இந்த catalog 1,000-க்கும் அதிகமான providers மற்றும் 10,000 prebuilt actions-ஐ விளம்பரப்படுத்துகிறது. இது project தானே கூறும் எண்ணிக்கை. வெளியிலிருந்து இதை நீங்கள் சரிபார்க்க முடியாது. நீங்கள் சரிபார்க்கக்கூடிய அமைப்பு இதுதான்: ஒவ்வொரு action-க்கும் ஒரு HTTP endpoint, ஒவ்வொரு provider-க்கும் ஒரு stored connection, ஒவ்வொரு agent-க்கும் ஒரு token.

Hosted connector service-ஐ பயன்படுத்துவதற்குப் பதிலாக Open Connector-ஐ நீங்களே host செய்வதன் காரணம்

Hosted connector service அதே பணியைச் செய்கிறது. அதனுடன் நீங்கள் இணைக்கும் ஒவ்வொரு provider-க்குமான refresh tokens-ஐ அது வைத்திருக்கும். Google அல்லது GitHub-க்கான refresh token என்பது உங்கள் mail மற்றும் repositories-க்கான நீண்டகால cryptographic key ஆகும். இது பொதுவாக password மாற்றிய பிறகும் செல்லுபடியாக இருக்கும். அந்த service breached ஆனால், உங்கள் அணுகலும் breached ஆகும். Self-hosting மூலம் அந்த records, நீங்கள் வாடகைக்கு எடுத்து நிர்வகிக்கும் machine-இல் உள்ள SQLite-க்கு மாற்றப்படுகின்றன. அவை உங்கள் machine-ஐ விட்டு ஒருபோதும் வெளியேறாத key மூலம் பாதுகாக்கப்படுகின்றன.

தொடங்குவதற்கு முன் இதன் செலவைத் தெளிவாகக் கணக்கிடுங்கள். இந்த VPS, நீங்கள் இயக்கும் servers-களில் மிகமுக்கியமானதாக மாறும். ஒரே file-இல் ஒரு dozen services-க்கான செயல்பாட்டில் உள்ள credentials இருக்கும். எனவே password manager host-க்கு வழங்கும் அதே பாதுகாப்பை இதற்கும் வழங்க வேண்டும்: 443-ஐ மட்டும் வெளிப்படுத்தும் firewall, shared logins இல்லாமை, நீங்கள் உண்மையில் ஒருமுறை restore செய்து சரிபார்த்த backup, மேலும் அது பதிலளிப்பதை நிறுத்தும்போது alert. இந்த machine-இல் உங்கள் password vault-ஐ வைக்க மாட்டீர்கள் என்றால், connector-ஐயும் இதில் வைக்க வேண்டாம்.

நிறுவுவதற்கு முன் ஒரு version-ஐ pin செய்யவும்

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-இல் moving tags அடிக்கடி மாறும். இரண்டு releases-ஐத் தாண்டி நகரும் docker compose pull, உங்கள் agent சார்ந்திருக்கும் endpoint-ஐ மாற்றக்கூடும். பின்னர் அதை agent பிரச்சினையாகக் கருதி மாலை முழுவதும் பிழைத்திருத்தம் செய்ய வேண்டியிருக்கும். Image-ஐ release tag-க்கு pin செய்யவும். Release notes-ஐப் படித்த பிறகு, நீங்கள் தீர்மானிக்கும் நேரத்தில் upgrade செய்யவும்.

உங்கள் சொந்த VPS-இல் TLS பின்னால் Open Connector-ஐ deploy செய்யவும்

container தொடங்குவதற்கு முன் பின்வருவன தேவை:

• Ubuntu 24.04 அல்லது அதற்கு நெருக்கமான பதிப்பில் Docker மற்றும் Compose plugin
• இந்த VPS-ஐச் சுட்டும் A record கொண்ட hostname; எடுத்துக்காட்டாக connect.example.com
• அந்த hostname-க்கான TLS (transport layer security)-ஐ ஏற்கனவே நிறைவு செய்யும் reverse proxy
• கீழே உருவாக்கப்படும் இரண்டு random secrets

பல Docker Compose apps-களுக்கான Traefik reverse proxy-ல் proxy பகுதி விளக்கப்பட்டுள்ளது. ஒரே app-க்கான முழுமையான certificate அமைப்பு, தொடக்கம் முதல் முடிவு வரை, Docker மற்றும் HTTPS உடன் VPS-இல் n8n வழிகாட்டியில் உள்ளது.

முதலில் secrets-ஐ உருவாக்கவும். encryption key சேமிக்கப்பட்ட credentials-ஐப் பாதுகாக்கிறது. 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

முதல் start செய்வதற்கு முன் இரண்டு values-ஐயும் password manager-ல் இப்போது சேமிக்கவும். 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-இன் அனைத்து interfaces-க்கும் bind ஆகிறது. ufw filter chain packet-ஐப் பார்ப்பதற்கு முன்பே Docker அதன் published ports-ஐ NAT (network address translation) table-ல் எழுதுகிறது. எனவே ufw deny 3000 அந்த port-ஐ மூடாது. இது Docker ports ufw-ஐ எவ்வாறு bypass செய்கின்றன என்பதில் விளக்கப்பட்டுள்ள trap ஆகும். 127.0.0.1:3000:3000 என்று எழுதினால் loopback interface-ல் மட்டும் publish ஆகும். உங்கள் reverse proxy அதே host-இலிருந்து connect செய்யும்.

:? ஒவ்வொரு variable-ஐயும் required எனக் குறிக்கிறது. எனவே .env இல்லாதபோது credentials encryption இன்றி stack தொடங்குவதற்குப் பதிலாக தொடங்க மறுக்கும். Values-ஐ compose file-ல் வைப்பதற்குப் பதிலாக .env-ல் வைத்திருப்பது Docker Compose env files மற்றும் secrets-ல் பயன்படுத்தப்படும் pattern ஆகும்.

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 தொடங்கியதும் /health, { "ok": true }-க்கு பதிலளிக்கும். ss, 127.0.0.1:3000-ஐ print செய்ய வேண்டும். 0.0.0.0:3000 என்று காட்டும் line இருந்தால் port mapping இன்னும் upstream-இன் mapping ஆகும். அப்போது 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 என்ற வடிவில் உருவாக்குகிறது. Origin அமைக்கப்படவில்லை என்றால், அது http://localhost:3000 ஆக இயல்புநிலைக்கு மாறும். இதனால் runtime, provider-க்கு http://localhost:3000/oauth/callback என்ற redirect URI-ஐ அனுப்பும். ஆனால் உங்கள் OAuth app-ல் https://connect.example.com/oauth/callback பதிவு செய்யப்பட்டிருக்கும். இந்த இரண்டு strings வேறுபடுவதால், GitHub பின்வரும் பதிலை வழங்கும்:

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

OAuth provider, browser-ஐ அந்த URI-க்கு மீண்டும் redirect செய்கிறது. எனவே, அந்த URI-ஐ வெளிப்புற network அணுகக்கூடிய address ஆக இருக்க வேண்டும். localhost-ஐத் தவிர, providers plain http://-ஐ ஏற்காது. இந்த deployment-க்கு hostname மற்றும் certificate தேவைப்படுவதற்கான முழுக் காரணம் இதுதான். முதல் start-க்கு முன்பே origin-ஐ அமைக்கவும். ஏனெனில் இந்த 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"

ஒவ்வொரு provider-க்கும் runtime எதிர்பார்க்கும் redirect URI-ஐ அந்த listing காட்டுகிறது. எனவே உங்கள் origin பயன்படுத்தப்பட்டதா என்பதைச் சரிபார்க்க இது விரைவான வழியாகும். அதில் இன்னும் 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-ஐ exchange செய்து credential-ஐச் சேமிக்கும். உங்கள் origin-இல் உள்ள web console, அதே admin token-க்கு பின்னால், form மூலம் இதே படிகளை வழிநடத்தும். plain API key-ஐப் பயன்படுத்தும் provider-களுக்கு இவை எதுவும் தேவையில்லை: PUT /api/connections/<service> உடன் {"authType":"api_key","values":{"apiKey":"..."}} இயக்கினால் key நேரடியாகச் சேமிக்கப்படும்.

ஒவ்வொரு agent-க்கும் runtime token வழங்குங்கள்; credential-ஐ ஒருபோதும் வழங்காதீர்கள்

Agent gateway-க்கு runtime token மூலம் authenticate செய்கிறது. இந்த 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"}'

பதில் oct_-ஆல் தொடங்கும் token-ஐ கொண்டிருக்கும். ஒவ்வொரு agent-க்கும் ஒரு token வழங்கி, அந்த agent-ன் பெயரை அதற்கு வையுங்கள். அடையாளம் காண முடியாத token-ஐ revoke செய்தால், அனைத்து token-களையும் 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":{}}'

சரியான பதில் என்பது, அதன் success field-ன் மதிப்பு true ஆகவும், provider payload data-ன் கீழ் இருப்பதாகவும் அமைந்த envelope ஆகும். அந்தப் பதிலில் எங்கும் GitHub token இருக்காது. MCP client-க்கு, அதே bearer header-ஐ பயன்படுத்தி https://connect.example.com/mcp-ஐ குறிக்கவும். அப்போது gateway ஒவ்வொரு API-க்கும் தனித்தனி tool வழங்குவதற்குப் பதிலாக, search_actions மற்றும் execute_action போன்ற discovery tools-ஐ வழங்கும். இதனால் agent-ன் tool பட்டியல் சிறியதாக இருக்கும். VPS-ல் MCP servers-ஐ இயக்குதல் இந்த wiring-ன் client பகுதியை விளக்குகிறது.

இது முடிந்ததாகக் கருதுவதற்கு முன் மேலும் ஒரு சோதனையை இயக்குங்கள். authorization header-ஐ நீக்கி, action call-ஐ மீண்டும் செய்யுங்கள். திட்டத்தின் சொந்த quickstart, bearer இல்லாமலேயே /v1-ஐ அழைக்கிறது. ஆகவே runtime authentication configure செய்யப்படாத installation, அந்த port-ஐ அணுகக்கூடிய எவருக்கும் actions-ஐ execute செய்யும். உங்கள் unauthenticated call வெற்றியடைந்தால், இரண்டு தீர்வுகள் உள்ளன: runtime token-களை configure செய்து anonymous call இப்போது தோல்வியடைகிறதா என்பதை உறுதிப்படுத்துங்கள்; அல்லது reverse proxy-யில் /api, /v1 மற்றும் /mcp ஆகியவற்றை உங்கள் agents வரும் addresses-க்கு மட்டும் கட்டுப்படுத்துங்கள். /oauth/callback மட்டுமே உலகளவில் திறந்திருக்க வேண்டும். Provider-ன் browser redirect-க்கு தேவையான ஒரே path அதுவாகும்.

agent-க்கு தேவையான action பட்டியலை மட்டும் வைத்திருங்கள்

அதன் பின்னால் ஆயிரம் providers கொண்ட gateway-ஐ language model-க்கு வழங்குவது விரிவான attack surface-ஐ உருவாக்குகிறது. இரண்டு கட்டுப்பாடுகள் இதைச் சுருக்குகின்றன.

OOMOL_CONNECT_ALLOWED_ACTIONS comma-separated allowlist-ஐ ஏற்றுக்கொண்டு, service.* மற்றும் * ஆகியவற்றைப் புரிந்துகொள்கிறது. OOMOL_CONNECT_BLOCKED_ACTIONS denylist ஆகும்; denylist-க்கே முன்னுரிமை உண்டு. allowlist-ஐ github.get_current_user,github.list_issues என அமைத்தால், agent என்ன கோரினாலும் மற்ற எல்லா actions-உம் மறுக்கப்படும். இதுவே ஒரு தவறுக்கும் ஒரு incident-க்கும் இடையிலான வேறுபாடு. Runtime tokens தங்களுக்கான action விதிகளை global விதிகளுக்கு மேலாகக் கொண்டிருக்கும். அவற்றின் allowedProxies பட்டியல் ஆரம்பத்தில் காலியாக இருக்கும். எனவே, அதற்கு அனுமதி வழங்கும் வரை POST /v1/proxy/:service மறுக்கப்படும். அந்த proxy endpoint, உங்கள் credential-ஐ இணைத்து raw request-ஐ provider-க்கு அனுப்புகிறது. எனவே, ஒரு குறிப்பிட்ட agent-க்கு அது தேவைப்படாவிட்டால் இதை காலியாக விடுங்கள்.

OOMOL_CONNECT_ALLOW_PRIVATE_NETWORK-ன் இயல்புநிலை மதிப்பு false ஆகும். இது self-hosted provider connection, 169.254.169.254-ல் உள்ள cloud metadata service அல்லது அதே network-ல் உள்ள உங்கள் database போன்ற private address-ஐ நோக்கிச் செல்வதைத் தடுக்கிறது. இதை முடக்கி வைத்திருங்கள். நீங்களே host செய்யும் provider-க்கு மட்டும் இதை இயக்குங்கள்.

ஒவ்வொரு token-ஐயும் வைத்திருக்கும் box-ஐ backup எடுக்கவும்

இரண்டு விஷயங்கள் முக்கியம். இவற்றில் ஒன்று இல்லாமல் மற்றொன்று பயனற்றது. connector-data volume-க்குள் உள்ள /app/data/connect.sqlite database-ல் sealed credentials சேமிக்கப்படுகின்றன. .env-ல் உள்ள encryption key அவற்றை unseal செய்கிறது. key இல்லாமல் volume backup-ஐ restore செய்தால் எதுவும் கிடைக்காது. volume இல்லாமல் key-ஐ வைத்திருந்தாலும் எதுவும் கிடைக்காது. எனவே key-ஐ உங்கள் password manager-ல் வைத்திருக்கவும். volume-ஐ உங்கள் வழக்கமான backup rotation-ல் சேர்க்கவும்.

SQLite file-ஐ copy செய்வதற்கு முன் container-ஐ நிறுத்தவும். எழுதும் செயல்பாட்டின்போது எடுக்கப்படும் copy, restore செய்தபோது 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 வைத்திருக்கும். அதனால் எந்த agent என்ன செய்தது, எப்போது செய்தது என்பதை console காட்டும். agent எதிர்பாராத விதமாக செயல்படும்போது முதலில் படிக்க வேண்டியது அந்த log ஆகும். https://connect.example.com/health-ஐயும் Uptime Kuma status page-க்கு point செய்யவும். 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 இல்லை அல்லது அதன் spelling தவறாக உள்ளது. அந்த header Authorization: Bearer <token> ஆகும். Web console-மும் அதே token-ஐக் கேட்கிறது.

Container இயங்குகிறது, credentials plain text-ஆக உள்ளன. OOMOL_CONNECT_ENCRYPTION_KEY container-ஐ அடையாதபோது இது நிகழ்கிறது. Runtime தொடங்க மறுப்பதற்குப் பதிலாக credential records-ஐ encryption இல்லாமல் சேமிக்கிறது. உங்கள் சொந்த install-ல் இதை உறுதிப்படுத்துங்கள்: நீங்கள் அடையாளம் காணக்கூடிய API key-ஐக் கொண்டு provider-ஐ இணைத்து, பின்னர் அதற்காக 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 அமைக்கப்பட்டால், அதே search 0-ஐத் திருப்பும். காரணம், அந்த record AES-256-GCM (advanced encryption standard, 256-bit key, Galois/counter mode) மூலம் seal செய்யப்படுகிறது.

Restore செய்த பிறகு எதுவும் decrypt ஆகவில்லை. Encryption key மாறியுள்ளது அல்லது இழக்கப்பட்டுள்ளது. வடிவமைப்பின்படி, அது data-க்கு அருகில் ஒருபோதும் எழுதப்படாது. எனவே recovery path இல்லை; எந்த support ticket-உம் உதவாது. ஒவ்வொரு provider-ஐயும் மீண்டும் இணைக்கவும். Rotation-ஐத் தனி key variable மற்றும் runtime-இல் உள்ள data command மூலம் ஆதரிக்கிறது. எனவே எதையும் rotate செய்வதற்கு முன் தற்போதைய release notes-ஐப் படிக்கவும்.

Catalog-ல் காணக்கூடிய action-ஐக் குறிப்பிடும் error-ஐ agent பெறுகிறது. 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 இயக்கவும். Migration line உள்ளதா என docker compose logs -n 50 connector-ஐ monitor செய்யவும். மீண்டும் 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 ஆக வேண்டும். மேலும், localhost-க்கு வெளியே உள்ள plain http://-ஐ providers நிராகரிக்கின்றன. முதல் 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 முழுவதும் தவிர்க்கப்படும்.

Gateway-ஐ public internet-இலிருந்து அணுக முடியுமாறு வைக்க வேண்டுமா?

/oauth/callback மட்டும் அவ்வாறு இருக்க வேண்டும். Container port-ஐ 127.0.0.1-ல் publish செய்யவும். இதனால் Docker-ன் NAT rules, உங்கள் firewall-ஐத் தாண்டி அதை expose செய்ய முடியாது. Reverse proxy-ஐ அதன் முன்னால் அமைக்கவும். பின்னர் authorization header இல்லாமல் ஒரு action call-ஐ test செய்யவும். அது வெற்றி பெற்றால், authenticated calls மட்டுமே செயல்படும் வரை agents பயன்படுத்தும் addresses-க்கு proxy-ல் /api, /v1 மற்றும் /mcp ஆகியவற்றை மட்டுப்படுத்தவும்.

Open Connector production use-க்கு தயாரா?

இதற்கு Apache 2.0 license உள்ளது. மேலும் இது வேகமாக வளர்ந்து வருகிறது. 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-ஐப் படிக்கவும். ஒருமுறை restore செய்து சரிபார்த்த volume backup-ஐ வைத்திருக்கவும். நீங்கள் own செய்யும் box-க்கு இந்த design நம்பகமானது. ஆபத்து architecture-ல் இல்லை; version churn-ல்தான் உள்ளது.