Open Connector-ஐ சொந்தமாக ஹோஸ்ட் செய்வது எப்படி?

AI agent-க்கு Open Connector என்ன செய்கிறது

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

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

ஒரு 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-க்கு பதிலாக, எளிதில் ரத்து செய்யக்கூடிய ஒரு runtime token மட்டுமே பாதிப்புக்குள்ளாகும்.

இந்த catalog 1,000-க்கும் மேற்பட்ட provider-களையும் 10,000-க்கும் மேற்பட்ட prebuilt actions-களையும் கொண்டிருப்பதாகக் கூறுகிறது; இது அந்தத் திட்டத்தின் சொந்த புள்ளிவிவரம், இதை வெளியில் இருந்து சரிபார்க்க முடியாது. ஆனால், அதன் கட்டமைப்பை நீங்கள் சரிபார்க்கலாம்: ஒவ்வொரு action-க்கும் ஒரு HTTP endpoint, ஒவ்வொரு provider-க்கும் ஒரு stored connection, ஒவ்வொரு agent-க்கும் ஒரு token. Agent சார்ந்த தொழில்நுட்பங்கள் இன்னும் புதியதாக இருப்பதால், tool call அல்லது MCP server போன்ற சொற்கள் இன்னும் முழுமையாக நிலைபெறவில்லை. AI agent-களை அடிப்படையிலிருந்து கற்றுக்கொள்வது எப்படி என்ற பகுதியில் உள்ள படிநிலைகள், இத்தகைய gateway-க்குத் தேவையான loop, tools மற்றும் பாதுகாப்புப் பழக்கங்களை உருவாக்க உதவும்.

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

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

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

எந்தவொரு மென்பொருளையும் நிறுவும் முன் ஒரு குறிப்பிட்ட version-ஐ pin செய்யவும்

Open Connector ஒரு புதிய மென்பொருள். இதன் repository 29 June 2026 அன்று முதன்முதலில் உருவாக்கப்பட்டது. 1 August 2026 நிலவரப்படி, 30 July 2026 அன்று வெளியிடப்பட்ட v1.3.3 என்பதே புதிய tagged release ஆகும். இது latest tag-ஐயும் கொண்டுள்ளது. Registry-யில் main-ன் புதிய commit-லிருந்து உருவாக்கப்பட்ட tip tag-ம் கிடைக்கிறது.

இவ்வளவு புதிய திட்டங்களில், moving tags அடிக்கடி மாறக்கூடும். இரண்டு release-களைத் தாண்டிச் செல்லும் ஒரு docker compose pull, உங்கள் agent சார்ந்திருக்கும் endpoint-ஐ மாற்றக்கூடும். இதனால், அது agent சார்ந்த சிக்கல் என்று கருதி நீங்கள் இரவு முழுவதும் பிழைதிருத்தம் (debugging) செய்ய வேண்டியிருக்கும். எனவே, image-ஐ ஒரு குறிப்பிட்ட release tag-க்கு pin செய்யவும். Release notes-ஐப் படித்த பிறகு, உங்கள் விருப்பப்படி அதை upgrade செய்யவும்.

உங்கள் சொந்த VPS-ல் TLS-க்கு பின்னால் Open Connector-ஐ நிறுவுதல்

Container தொடங்குவதற்கு முன் உங்களுக்குத் தேவையானவை:

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

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

முதலில் ரகசியங்களை உருவாக்கவும். Encryption key சேமிக்கப்பட்ட நற்சான்றிதழ்களைப் (credentials) பாதுகாக்கிறது. Admin token, web console மற்றும் முழு /api தளத்தையும் பாதுகாக்கிறது. இவற்றுக்கு default மதிப்பு கிடையாது, இவை இல்லாமலேயே 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

முதல் தொடக்கத்திற்கு முன்பே, இரண்டு மதிப்புகளையும் உங்கள் password manager-ல் நகலெடுத்துக் கொள்ளவும். Encryption key-க்கு மீட்பு வழிமுறை (recovery path) கிடையாது, இதற்கான காரணம் கீழே உள்ள தோல்விப் பட்டியலில் கொடுக்கப்பட்டுள்ளது.

இப்போது compose.yaml-ஐ உருவாக்கவும். இது upstream உதாரணத்திலிருந்து இரண்டு இடங்களில் மாறுபடுகிறது, இரண்டுமே முக்கியமானவை.

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-க்கு பதிலாக குறிப்பிட்ட tag-ஐப் பயன்படுத்துவது. இரண்டாவது மாற்றம் port ஆகும். Upstream கோப்பு 3000:3000-ஐ வெளியிடுகிறது, இது host-ன் அனைத்து interface-களிலும் இணைகிறது. Docker அதன் published ports-ஐ NAT (network address translation) அட்டவணையில் எழுதுகிறது, இது ufw filter chain-க்கு முன்பே நடக்கும். எனவே ufw deny 3000 அந்த port-ஐ மூடாது, இது Docker ports ஏன் ufw-ஐத் தவிர்க்கிறது என்பதில் விவரிக்கப்பட்டுள்ள சிக்கலாகும். 127.0.0.1:3000:3000 என்று குறிப்பிடுவது loopback interface-ல் மட்டுமே வெளியிடும், உங்கள் reverse proxy அதே host-லிருந்து இணைப்பை ஏற்படுத்தும்.

:? ஒவ்வொரு மாறியும் (variable) கட்டாயம் என்பதை உறுதிப்படுத்துகிறது. எனவே .env விடுபட்டிருந்தால், நற்சான்றிதழ்கள் குறியாக்கப்படாமல் (unencrypted) தொடங்குவதற்குப் பதிலாக, stack தொடங்குவதை நிறுத்திவிடும். Compose கோப்பில் வைப்பதற்குப் பதிலாக .env-ல் மதிப்புகளை வைத்திருப்பது Docker Compose env கோப்புகள் மற்றும் ரகசியங்கள் வழிகாட்டியில் உள்ள சிறந்த நடைமுறையாகும்.

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-ஐ அச்சிட வேண்டும். 0.0.0.0:3000 என்று ஒரு வரி வந்தால், port mapping இன்னும் upstream அமைப்பிலேயே உள்ளது என்று அர்த்தம், மேலும் gateway நேரடியாக இணையம் முழுவதற்கும் பதிலளித்துக் கொண்டிருக்கிறது. 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 என்பது பயனர்கள் தவிர்க்கும் ஒரு அமைப்பாகும். இதைத் தவிர்ப்பது OAuth-ஐச் செயலிழக்கச் செய்யும், இது பார்ப்பதற்கு provider-ன் பிழை போலத் தோன்றும். Runtime அதன் redirect URI-ஐ அந்த origin-லிருந்து <origin>/oauth/callback என்ற வடிவத்தில் உருவாக்குகிறது. இதை அமைக்காமல் விட்டால், origin இயல்பாக http://localhost:3000 என்று எடுத்துக்கொள்ளப்படும். எனவே, உங்கள் OAuth app-ல் https://connect.example.com/oauth/callback பதிவு செய்யப்பட்டிருந்தாலும், runtime provider-க்கு http://localhost:3000/oauth/callback என்ற redirect URI-ஐ அனுப்பும். இந்த இரண்டு சரங்களும் (strings) வெவ்வேறாக இருப்பதால், GitHub பின்வருமாறு பதிலளிக்கும்:

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

ஒரு OAuth provider உலாவியை (browser) மீண்டும் அந்த URI-க்குத் திருப்பிவிடும். எனவே, அது வெளி உலகத்திலிருந்து அணுகக்கூடிய முகவரியாக இருக்க வேண்டும். localhost-ஐத் தவிர மற்ற எதற்கும் plain http://-ஐ provider-கள் நிராகரித்துவிடும். இந்த deployment-க்கு hostname மற்றும் certificate தேவைப்படுவதற்கு இதுவே முழுமையான காரணம். முதல்முறை தொடங்குவதற்கு முன்பே origin-ஐ அமைக்கவும், ஏனெனில் இந்த மதிப்பு தொடக்கத்தின்போதே (startup) வாசிக்கப்படும்: .env அல்லது compose.yaml-ஐத் திருத்திய பிறகு, அதைச் செயல்படுத்த docker compose up -d-ஐ மீண்டும் இயக்கவும்.

OAuth மூலம் உங்கள் முதல் provider-ஐ இணைத்தல்

முதலில் 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 அழைப்பும் 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-ஐக் காட்டுகிறது. உங்கள் origin மாற்றங்கள் அமலுக்கு வந்துவிட்டதா என்பதைச் சரிபார்க்க இதுவே விரைவான வழியாகும். ஒருவேளை அது இன்னும் localhost என்று காட்டினால், container பழைய மதிப்பிலேயே இயங்குகிறது என்று அர்த்தம்; இதனால் 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"}'

இரண்டாவது அழைப்பு ஒரு authorizationUrl-ஐத் திருப்பித் தரும். அதை browser-ல் திறந்து, scopes-க்கு ஒப்புதல் அளிக்கவும். பின் provider உங்களை /oauth/callback-க்கு திருப்பி அனுப்பும்; அங்கு runtime அந்த code-ஐப் பெற்று, credential-ஐச் சேமிக்கும். உங்கள் origin-ல் உள்ள web console, அதே admin token-ஐப் பயன்படுத்தி ஒரு form மூலம் இதே படிகளைச் செய்கிறது. Plain API key-ஐப் பயன்படுத்தும் providers-க்கு இவை எதுவும் தேவையில்லை: PUT /api/connections/<service> உடன் {"authType":"api_key","values":{"apiKey":"..."}}-ஐப் பயன்படுத்தி key-ஐ நேரடியாகச் சேமிக்கலாம்.

ஒவ்வொரு agent-க்கும் ஒரு runtime token-ஐ வழங்கவும், credential-ஐ ஒருபோதும் வழங்க வேண்டாம்

Agent, admin API மூலம் உருவாக்கப்பட்ட runtime token-ஐப் பயன்படுத்தி gateway-ல் அங்கீகாரம் (authenticate) பெறுகிறது.

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

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

இதை முடிப்பதற்கு முன் மேலும் ஒரு சோதனையைச் செய்யவும். authorization header-ஐ நீக்கிவிட்டு, அந்தச் செயல் அழைப்பை (action call) மீண்டும் செய்யவும். இந்தத் திட்டத்தின் quickstart, எந்தவிதமான bearer-உம் இல்லாமல் /v1-ஐ அழைக்கிறது. எனவே, runtime auth அமைக்கப்படாத ஒரு நிறுவல், அந்த port-ஐ அணுகக்கூடிய எவருக்கும் செயல்களைச் செயல்படுத்த அனுமதிக்கும். உங்கள் அங்கீகரிக்கப்படாத அழைப்பு வெற்றி பெற்றால், உங்களுக்கு இரண்டு வழிகள் உள்ளன: runtime token-களை உள்ளமைத்து, anonymous அழைப்பு இப்போது தோல்வியடைகிறதா என்பதை உறுதிப்படுத்தவும், அல்லது reverse proxy-ல் /api, /v1 மற்றும் /mcp ஆகியவற்றை உங்கள் agent-கள் வரும் முகவரிகளுக்கு மட்டும் கட்டுப்படுத்தவும். /oauth/callback மட்டும் உலகிற்குத் திறந்த நிலையில் இருக்க வேண்டும், ஏனெனில் provider-ன் browser redirect-க்குத் தேவையான ஒரே பாதை அதுதான்.

ஏஜெண்டிற்குத் தேவையான செயல்களை மட்டும் கட்டுப்படுத்துங்கள்

ஆயிரக்கணக்கான providers-ஐக் கொண்ட ஒரு gateway-ஐ ஒரு language model-இடம் ஒப்படைப்பது, தாக்குதலுக்கு உள்ளாகக்கூடிய பரப்பை அதிகரிக்கிறது. அந்த model தான் எழுதாத உரையை வாசிக்கும்போது இந்த ஆபத்து இன்னும் கூடுகிறது. ஏனெனில், ஏஜெண்டின் இணையத் தேடல்களுக்குப் பதிலளிக்கும் உங்கள் சொந்த SearXNG instance வழங்கும் ஒரு பக்கம், ஏஜெண்டிற்கு வழங்கப்பட்டுள்ள எந்தவொரு செயலுக்கும் எதிரான கட்டளைகளைக் கொண்டிருக்கலாம். ஒரு coding agent மிகச்சிறிய மாற்றத்தை மட்டும் செய்யும் அதே கட்டுப்பாடு அதன் அனுமதிகளுக்கும் பொருந்தும்: அந்தப் பணிக்குத் தேவையான சில செயல்களை மட்டும் அனுமதியுங்கள், அதற்கு மேல் எதையும் வழங்காதீர்கள். இரண்டு கட்டுப்பாடுகள் இதைச் சுருக்குகின்றன.

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

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

ஒவ்வொரு டோக்கனையும் கொண்ட பெட்டியை காப்புப்பிரதி எடுத்தல்

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

SQLite கோப்பை நகலெடுக்கும்போது கன்டெய்னரை நிறுத்திவிடவும், ஏனெனில் எழுதும் செயல்பாட்டின் போது எடுக்கப்படும் நகல் சிதைந்த தரவுத்தளமாக மாறக்கூடும்.

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

வால்யூம் பெயர் என்பது உங்கள் புராஜெக்ட் டைரக்டரியுடன் _connector-data சேர்ந்ததாகும், அதனால்தான் முதல் கட்டளை அங்கு உள்ளது: உண்மையான பெயரை மூன்றாவது கட்டளையில் உள்ளிடவும். அந்த ஆவணக் காப்பகத்தை (archive) VPS-லிருந்து restic காப்புப்பிரதிகள் மூலம் VPS-லிருந்து வெளியே அனுப்பவும். இது வெளியேறும் முன்பே குறியாக்கம் செய்யப்படுவதால் பாதுகாப்பானது, ஏனெனில் அந்த ஆவணக் காப்பகம் தான் நற்சான்றிதழ் சேமிப்பகம்.

இயக்கநேரம் (runtime) சமீபத்திய செயல்பாடுகளை தணிக்கை பதிவுகளாக (audit records) வைத்திருக்கும், இயல்பாக 5,000 பதிவுகள் வரை இருக்கும். எனவே, எந்த ஏஜென்ட் எப்போது எதை இயக்கியது என்பதை கன்சோல் மூலம் தெரிந்துகொள்ளலாம். ஒரு ஏஜென்ட் வழக்கத்திற்கு மாறாகச் செயல்படும்போது, முதலில் இந்தப் பதிவைத்தான் படிக்க வேண்டும். https://connect.example.com/health-ஐ Uptime Kuma நிலை பக்கத்துடன் இணைக்கவும். கேட்வே (gateway) பதிலளிக்காதபோது, ஏஜென்ட்கள் குழப்பமான முறையில் தோல்வியடையும். கேட்வே செயலிழந்துள்ளதை முன்கூட்டியே அறிந்துகொள்வது, ஏஜென்ட் வெளியீடுகளைப் படித்து நேரத்தை வீணாக்குவதைத் தவிர்க்க உதவும்.

எவை செயலிழக்கும் மற்றும் நீங்கள் காணும் செய்தி

redirect_uri_mismatch வழங்குநரிடம் (provider). மூலமும் (origin) பதிவுசெய்யப்பட்ட callback URL-ம் வெவ்வேறாக உள்ளன. /api/oauth/configs-ல் உள்ள துல்லியமான சரத்தை (string), வழங்குநரின் app settings-ல் உள்ளவற்றுடன் ஒப்பிடவும். இதில் https மற்றும் http ஆகியவற்றுக்கு இடையிலான வேறுபாடுகள் மற்றும் இறுதியில் உள்ள slash குறியீடு ஆகியவற்றைச் சரிபார்க்கவும்.

ஒவ்வொரு /api அழைப்பும் 401 பிழையைத் தருகிறது. admin token header விடுபட்டுள்ளது அல்லது எழுத்துப் பிழையுடன் உள்ளது. அந்த header Authorization: Bearer <token> ஆகும்; web console-ம் அதே token-ஐக் கேட்கிறது.

Container இயங்குகிறது, ஆனால் நற்சான்றுகள் (credentials) plain text-ஆக உள்ளன. OOMOL_CONNECT_ENCRYPTION_KEY container-ஐ அடையாதபோது இது நிகழ்கிறது. Runtime, நற்சான்றுகளைத் தொடங்க மறுப்பதற்குப் பதிலாக, அவற்றை encrypt செய்யாமல் சேமித்து வைக்கிறது. உங்கள் சொந்த நிறுவலிலேயே இதை உறுதிப்படுத்தலாம்: உங்களுக்குத் தெரிந்த ஒரு API key-ஐக் கொண்டு ஒரு வழங்குநரை இணைக்கவும், பின்னர் 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-க்கு மேல் எண்ணிக்கை இருந்தால், அந்த key செயல்பாட்டில் இல்லை என்று பொருள். எனவே, .env ஆனது compose.yaml இருக்கும் அதே directory-ல் உள்ளதா என்பதையும், docker compose config அந்த மதிப்பைக் காட்டுகிறதா என்பதையும் சரிபார்க்கவும். key சரியாக அமைக்கப்பட்டிருந்தால், அதே தேடல் 0 என்ற முடிவைத் தரும். ஏனெனில், அந்தப் பதிவு AES-256-GCM (advanced encryption standard, 256-bit key, Galois/counter mode) மூலம் பாதுகாக்கப்பட்டுள்ளது.

மீட்டெடுப்புக்குப் (restore) பிறகு எதுவும் decrypt ஆகவில்லை. encryption key மாற்றப்பட்டிருக்கலாம் அல்லது தொலைந்திருக்கலாம். வடிவமைப்பின்படி, இது தரவுகளுடன் சேர்த்து எழுதப்படுவதில்லை. எனவே, இதை மீட்டெடுக்க வழியில்லை, எந்த support ticket-உம் உதவாது. ஒவ்வொரு வழங்குநரையும் மீண்டும் இணைக்கவும். ஒரு தனி key variable மற்றும் runtime-ல் உள்ள data command மூலம் rotation ஆதரிக்கப்படுகிறது. எனவே, எதையும் rotate செய்வதற்கு முன் தற்போதைய release notes-ஐப் படிக்கவும்.

Catalog-ல் உள்ள ஒரு செயலை (action) agent குறிப்பிடும்போது பிழை ஏற்படுகிறது. கண்டறிதலும் (discovery) செயல்படுத்துதலும் (execution) வெவ்வேறானவை. ஒரு செயல் search_actions-ல் தோன்றினாலும், OOMOL_CONNECT_ALLOWED_ACTIONS, denylist அல்லது அந்த runtime token-ன் சொந்த விதிகளின்படி அது நிராகரிக்கப்படலாம்.

மேம்படுத்தல்கள் (upgrades). volume-ஐ backup எடுக்கவும், image tag-ஐ புதிய release-க்கு மாற்றவும், பின்னர் docker compose pull && docker compose up -d-ஐ இயக்கவும். migration வரி உள்ளதா என docker compose logs -n 50 connector-ஐக் கவனிக்கவும். மீண்டும் நம்பகமானதாக மாற்றுவதற்கு முன், health check-ஐயும் ஒரு உண்மையான செயலையும் மீண்டும் இயக்கவும். பழைய நிலைக்குத் திரும்புவது (rolling back) என்பது பழைய tag-ஐ மீண்டும் பயன்படுத்துவதாகும்; நீங்கள் அதைத் துல்லியமாகக் குறிப்பிட்டிருந்தால் (pinned) மட்டுமே இது வேலை செய்யும்.

FAQ

Open Connector-ஐ self-host செய்ய எனக்கு public domain தேவையா?

API key-ஐப் பயன்படுத்தும் providers-க்கு, இது தேவையில்லை: 127.0.0.1-ல் உள்ள gateway போதுமானது. ஆனால் OAuth-க்கு, நடைமுறையில் இது அவசியம். Provider உங்கள் browser-ஐ callback URL-க்கு திருப்பிவிடும், எனவே அந்த URL public internet-ல் இருந்து அணுகக்கூடியதாக இருக்க வேண்டும். மேலும், localhost-ஐத் தவிர மற்ற இடங்களுக்கு plain http://-ஐப் பயன்படுத்த providers அனுமதிப்பதில்லை. முதல்முறை தொடங்குவதற்கு முன்பே OOMOL_CONNECT_ORIGIN-ஐ உங்கள் https:// hostname-க்கு அமைத்து, provider-ன் OAuth app-ல் <origin>/oauth/callback-ஐப் பதிவு செய்யவும்.

Open Connector encryption key தொலைந்துவிட்டால் என்னவாகும்?

சேமிக்கப்பட்ட credentials-ஐ decrypt செய்ய முடியாது, இதை மீட்டெடுக்க வழியும் இல்லை. பாதுகாப்பு கருதி, இந்த key தரவுகளுடன் சேர்த்துச் சேமிக்கப்படுவதில்லை. எனவே, database-ஐ வைத்திருப்பவர் யாராலும் (நீங்களும் உட்பட) அதை வாசிக்க முடியாது. புதிய key-ஐ அமைத்து, ஒவ்வொரு provider-உடனும் மீண்டும் இணைப்பதே ஒரே வழி. Key-ஐ ஒரு password manager-லும், database-ஐ உங்கள் backup சுழற்சியிலும் வைத்திருக்கவும்; ஏனெனில் restore செய்வதற்கு இவை இரண்டுமே தேவை.

எனது AI agent-ஆல் provider access token-ஐப் பார்க்க முடியுமா?

Gateway வழியாக அழைக்கும்போது பார்க்க முடியாது. Agent, oct_ என்று தொடங்கும் runtime token மூலம் அங்கீகாரம் பெறுகிறது. Gateway, server-ல் உள்ள outbound request-ல் provider credential-ஐச் சேர்த்து, பதிலை மட்டும் திருப்பி அனுப்பும். இரண்டு சூழல்களில் இது மாறலாம்: /v1/proxy/:service endpoint, இது உங்கள் credential-உடன் raw requests-ஐ அனுப்பும் (இதன் grants காலியாக இருப்பதற்கு ஒரு காரணம் உண்டு), மற்றும் API key-ஐ நீங்களே நேரடியாக agent-ல் உள்ளீடு செய்வது; இது gateway-ஐத் தவிர்த்துவிடும்.

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

/oauth/callback மட்டும் அணுகக்கூடியதாக இருந்தால் போதும். Container port-ஐ 127.0.0.1-ல் publish செய்யவும், இதனால் Docker-ன் NAT விதிகள் உங்கள் firewall-ஐத் தாண்டி அதை வெளிப்படுத்தாது. அதற்கு முன்னால் reverse proxy-ஐ அமைக்கவும். பிறகு authorization header இல்லாமல் ஒரு action call-ஐச் சோதிக்கவும். அது வெற்றி பெற்றால், அங்கீகரிக்கப்பட்ட அழைப்புகள் மட்டுமே செயல்படும் வரை, proxy-ல் /api, /v1 மற்றும் /mcp ஆகியவற்றை உங்கள் agent-கள் பயன்படுத்தும் முகவரிகளுக்கு மட்டும் கட்டுப்படுத்தவும்.

Open Connector production பயன்பாட்டிற்குத் தயாரா?

இது Apache 2.0 உரிமம் பெற்றது மற்றும் வேகமாக வளர்ந்து வருகிறது: இதன் repository 29 June 2026 அன்று வெளியானது மற்றும் v1.3.3 பதிப்பு 30 July 2026 அன்று வெளியானது. எனவே, இந்த வழிகாட்டியில் உள்ள ஒவ்வொரு பதிப்பு எண்ணையும் 1 August 2026-ன் ஒரு snapshot-ஆகக் கருதவும். எப்போதும் ஒரு release tag-ஐப் பயன்படுத்தி இயக்கவும், ஒருபோதும் latest அல்லது tip-ல் இயக்க வேண்டாம். ஒவ்வொரு upgrade-க்கு முன்பும் release notes-ஐ வாசிக்கவும், ஒருமுறை restore செய்து சரிபார்க்கப்பட்ட volume backup-ஐ வைத்திருக்கவும். நீங்கள் சொந்தமாக வைத்திருக்கும் server-க்கு இதன் வடிவமைப்பு சரியானது, இதில் உள்ள ஆபத்து architecture-ல் இல்லை, பதிப்புகளின் வேகமான மாற்றத்தில் மட்டுமே உள்ளது.