אירוח עצמי של Open Connector עבור סוכני AI

מה עושה Open Connector עבור סוכן AI

אירוח עצמי של Open Connector מציב שער אימות (auth gateway) יחיד בין סוכני ה-AI שלכם לבין כל ממשק API של תוכנה כשירות (SaaS) שהם קוראים לו, כך שהסוכן לעולם אינו מחזיק ב-token של ספק השירות. זהו שער בקוד פתוח מבית OOMOL Lab, המופץ תחת רישיון Apache 2.0. הוא רץ כמכולה (container) אחת, שומר את מצבו בקובץ SQLite יחיד, וחושף פעולות של ספקים באמצעות HTTP ו-MCP (פרוטוקול הקשר למודל).

הקושי מתחיל באינטגרציה השנייה. לכל ספק יש תהליך OAuth (אימות פתוח) משלו, אורך חיים שונה ל-refresh token, ושמות scope ייחודיים. חיבור ידני של חמישה ספקים לסוכן משמעו חמישה מטפלי הפניות (redirect handlers), חמישה מאגרי הרשאות, וחמישה לולאות רענון שחייבות לרוץ לפני ש-token פג תוקף. כמעט אף אחד לא כותב קוד כזה. במקום זאת, יוצרים personal access token אחד בעל תוקף ארוך לכל שירות ומדביקים אותו בהגדרות הסוכן, בקובץ סביבה, או ב-prompt עצמו. ה-token הזה הופך לקריא עבור כל כלי שהסוכן מריץ, והוא מגיע לתמלול השיחה, מה שמוביל לכשל שמתואר ב-שמירה על סודות מחוץ לסוכני AI.

שער אימות מפצל את פרטי ההזדהות לשניים. השער מאחסן את פרטי ההזדהות של הספק ומריץ את תהליך ה-OAuth. הסוכן מקבל token לזמן ריצה שתקף רק מול השער. כאשר הסוכן קורא לפעולה, השער טוען את פרטי ההזדהות השמורים, מזריק אותם לבקשה היוצאת בצד השרת, ומחזיר רק את גוף התגובה. הסוכן לעולם אינו מקבל את ה-access token של הספק, כך שדליפה של תמלול הסוכן תעלה לכם ב-token זמן ריצה שניתן לביטול, במקום בחשיפת חשבון ה-GitHub שלכם.

הקטלוג מפרסם יותר מ-1,000 ספקים ו-10,000 פעולות מוכנות מראש; אלו נתונים של הפרויקט עצמו ולא משהו שניתן לאמת מבחוץ. מה שכן ניתן לאמת הוא המבנה: נקודת קצה (endpoint) אחת ב-HTTP לכל פעולה, חיבור שמור אחד לכל ספק, ו-token אחד לכל סוכן.

מדוע לארח עצמית את Open Connector במקום להשתמש בשירות connector מנוהל

שירות connector מנוהל מבצע את אותה עבודה, אך הוא מחזיק ב־refresh tokens עבור כל ספק שאליו אתם מתחברים. refresh token עבור Google או GitHub הוא מפתח בעל תוקף ארוך לתיבת הדואר ולמאגרים שלכם, והוא בדרך כלל נשאר תקף גם לאחר שינוי סיסמה. פריצה אליהם הופכת לפריצה אליכם. אירוח עצמי מעביר את הרשומות הללו לקובץ SQLite על מכונה שאתם שוכרים ומנהלים, כשהן חתומות במפתח שלעולם לא עוזב את השרת שלכם.

אמרו את העלות בקול לפני שתתחילו. ה־VPS הזה הופך לשרת החשוב ביותר שאתם מריצים. הוא מחזיק אישורי גישה פעילים עבור תריסר שירותים בקובץ אחד, ולכן הוא ראוי ליחס שאתם מעניקים למארח של מנהל סיסמאות: firewall שחושף רק את פורט 443, ללא כניסות משותפות, גיבוי שבאמת שחזרתם פעם אחת, והתראה כאשר הוא מפסיק להגיב. אם לא הייתם מציבים את כספת הסיסמאות שלכם על המכונה הזו, אל תציבו עליה גם את ה־connector.

קבעו גרסה לפני התקנה של כל רכיב

Open Connector הוא פרויקט חדש. המאגר הופיע לראשונה ב-29 ביוני 2026, ונכון ל-1 באוגוסט 2026, הגרסה המתויגת העדכנית ביותר היא v1.3.3, שפורסמה ב-30 ביולי 2026 ונושאת גם את התג latest. ה-registry מפרסם גם תג tip, שנבנה מה-commit העדכני ביותר ב-main.

בפרויקט חדש כל כך, תגים משתנים מתעדכנים לעיתים קרובות. תג docker compose pull שקופץ בין שתי גרסאות עלול לשנות endpoint שהסוכן (agent) שלכם מסתמך עליו, ואתם תבזבזו את הערב בניסיון לאתר את התקלה כבעיה בסוכן. קבעו (pin) את ה-image לתג גרסה ספציפי, ושדרגו רק כאשר תחליטו לעשות זאת, לאחר קריאת הערות השחרור (release notes).

פריסת Open Connector מאחורי TLS על ה-VPS שלך

לפני הפעלת ה-container, עליך לוודא שברשותך:

• Docker עם תוסף Compose, על Ubuntu 24.04 או הפצה דומה.
• שם מתחם (hostname) שרשומת ה-A שלו מצביעה על ה-VPS הזה, למשל connect.example.com.
• Reverse proxy שכבר מבצע TLS termination עבור שם המתחם הזה.
• שני סודות אקראיים, שיופקו בהמשך.

המדריך Traefik reverse proxy for multiple Docker Compose apps מכסה את צד ה-proxy. תהליך הגדרת התעודות המלא עבור יישום בודד מופיע במדריך n8n on a VPS with Docker and HTTPS.

תחילה, צור את הסודות. מפתח ההצפנה מאבטח את פרטי ההתחברות השמורים. ה-admin token מגן על ממשק הניהול ועל כל משטח ה-/api. לאף אחד מהם אין ערך ברירת מחדל, והמערכת תעלה גם בלעדיהם.

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

העתק את שני הערכים למנהל הסיסמאות שלך כעת, לפני ההפעלה הראשונה. למפתח ההצפנה אין מנגנון שחזור, והסיבה לכך מפורטת ברשימת הכשלים בהמשך.

כעת, הגדר את compose.yaml. הוא שונה מהדוגמה הרשמית בשני מקומות, ושניהם קריטיים.

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:

השינוי הראשון הוא שימוש ב-tag קבוע במקום latest. השינוי השני הוא הפורט. הקובץ המקורי מפרסם את 3000:3000, שמאזין לכל ממשקי הרשת במארח. Docker כותב את הפורטים המפורסמים לטבלת ה-NAT (network address translation) לפני ששרשרת ה-ufw רואה את החבילה, לכן ufw deny 3000 לא חוסם את הפורט הזה – זהו המלכוד המתואר ב-why Docker ports bypass ufw. כתיבת 127.0.0.1:3000:3000 מפרסמת את השירות על ממשק ה-loopback בלבד, וה-reverse proxy שלך מתחבר מאותו מארח.

ה-:? מסמן כל משתנה כנדרש, כך שה-stack יסרב לעלות אם .env חסר, במקום לעלות עם פרטי התחברות לא מוצפנים. שמירת הערכים ב-.env במקום בקובץ ה-compose היא התבנית המומלצת ב-Docker Compose env files and secrets.

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 עונה ל-{ "ok": true } ברגע שהמערכת עלתה. ss חייב להדפיס 127.0.0.1:3000. שורה המציגה 0.0.0.0:3000 מעידה על כך שמיפוי הפורטים נותר כפי שהיה במקור, וה-gateway חשוף ישירות לכל האינטרנט. שגיאת Connection refused בבדיקת התקינות (health check) אומרת שה-container עדיין לא מאזין, לכן קרא את הלוגים לפני שתשנה את הגדרות ה-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"

מדוע OAuth מחייב שם מארח (hostname) אמיתי

OOMOL_CONNECT_ORIGIN היא ההגדרה שאנשים נוטים לדלג עליה, ודילוג עליה גורם ל־OAuth להיכשל באופן שנראה כמו באג אצל ספק השירות. סביבת הריצה בונה את ה-redirect URI שלה מתוך ה-origin הזה, במבנה של <origin>/oauth/callback. אם לא מגדירים אותו, ה-origin כברירת מחדל הוא http://localhost:3000, ולכן סביבת הריצה שולחת לספק כתובת redirect URI של http://localhost:3000/oauth/callback, בעוד שאפליקציית ה-OAuth שלכם רשמה את https://connect.example.com/oauth/callback. מכיוון שהמחרוזות אינן זהות, GitHub משיב בשגיאה:

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

ספק OAuth מפנה את הדפדפן בחזרה לכתובת ה-URI הזו, מה שאומר שהיא חייבת להיות כתובת שהעולם החיצון יכול להגיע אליה, וספקים דוחים שימוש ב-http:// פשוט עבור כל דבר שאינו localhost. זו הסיבה המלאה לכך שהפריסה הזו דורשת שם מארח ותעודה. הגדירו את ה-origin לפני ההפעלה הראשונה, כיוון שהערך נקרא בעת העלייה: לאחר עריכת .env או compose.yaml, הריצו שוב את docker compose up -d כדי להחיל את השינויים.

חיבור ספק השירות הראשון שלך באמצעות OAuth

תחילה, צור את אפליקציית ה-OAuth אצל ספק השירות. ב-GitHub הנתיב הוא Settings, לאחר מכן Developer settings, לאחר מכן OAuth Apps, ולבסוף New OAuth App. הגדר את ה-URL של ה-callback לאימות כ-https://connect.example.com/oauth/callback. שמור את ה-client ID ואת ה-client secret.

כל קריאת /api נושאת את ה-admin token, לכן בצע לו export פעם אחת עבור סשן ה-shell הנוכחי.

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

רשימה זו מציגה את ה-redirect URI שה-runtime מצפה לו עבור כל ספק, מה שהופך אותה לבדיקה המהירה ביותר לכך שהגדרת ה-origin שלך נכנסה לתוקף. אם עדיין מופיע localhost, המכולה פועלת עם הערך הישן ותהליך ה-OAuth ייכשל בשלב האחרון.

אחסן את פרטי ה-client, ולאחר מכן התחל תהליך אימות.

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. פתח אותו בדפדפן, אשר את ה-scopes, וספק השירות יפנה את הדפדפן בחזרה ל-/oauth/callback, שם ה-runtime מחליף את ה-code ומאחסן את ה-credential. ה-web console ב-origin שלך מבצעת את אותם השלבים באמצעות טופס, מאחורי אותו ה-admin token. ספקים המשתמשים ב-API key פשוט מדלגים על כל זה: PUT /api/connections/<service> עם {"authType":"api_key","values":{"apiKey":"..."}} מאחסן את המפתח ישירות.

הקצאת token זמן-ריצה לכל סוכן, לעולם לא את פרטי ההזדהות

הסוכן מאמת את זהותו מול ה-gateway באמצעות 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"}'

התגובה מכילה token המתחיל ב-oct_. הנפיקו token אחד לכל סוכן ותנו לו שם על פי שם הסוכן, כיוון שביטול token שאינכם יכולים לזהות משמעו ביטול של כולם. לאחר מכן, הסוכן מבצע פעולות באמצעות HTTP רגיל.

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 הוא true, כאשר ה-payload של ה-provider נמצא תחת data. ה-token של GitHub אינו מופיע בשום מקום בתגובה זו. עבור לקוח MCP, הפנו אותו ל-https://connect.example.com/mcp עם אותו bearer header, וה-gateway יציע כלי גילוי כגון search_actions ו-execute_action במקום כלי אחד לכל API, מה ששומר על רשימת הכלים של הסוכן מצומצמת. המדריך הרצת שרתי MCP על גבי VPS מכסה את הצד של הלקוח בחיבור זה.

בצעו בדיקה נוספת לפני שתסיימו. חזרו על קריאת הפעולה כאשר ה-header authorization מחוק. ה-quickstart של הפרויקט עצמו מפעיל את /v1 ללא bearer כלל, לכן התקנה ללא הגדרת אימות זמן-ריצה תבצע פעולות עבור כל מי שיכול להגיע לפורט. אם הקריאה הלא-מאומתת שלכם מצליחה, עומדות בפניכם שתי דרכים לפתרון: הגדירו tokens זמן-ריצה וודאו שהקריאה האנונימית נכשלת כעת, או הגבילו את /api, /v1 ו-/mcp ב-reverse proxy לכתובות מהן מגיעים הסוכנים שלכם. רק /oauth/callback חייב להישאר פתוח לעולם, כיוון שזהו הנתיב היחיד לו זקוק ה-browser redirect של ה-provider.

צמצום רשימת הפעולות למינימום הנדרש לסוכן

Gateway עם אלפי ספקים מאחוריו מהווה שטח פנים רחב מדי עבור מודל שפה. השטח הזה מתרחב ברגע שהמודל מתחיל לקרוא טקסט שהוא לא כתב בעצמו, כיוון שדף שמוחזר על ידי מופע SearXNG עצמאי שמשיב לחיפושי האינטרנט של הסוכן עלול להכיל הוראות המכוונות לכל פעולה שהסוכן מורשה לבצע. אותה ריסון שגורם ל-סוכן כתיבת קוד לבצע את השינוי הקטן ביותר שעובד צריך לחול גם על ההרשאות שלו: העניקו לו רק את קומץ הפעולות שהמשימה באמת דורשת, ולא מעבר לכך. שני בקרים מצמצמים זאת.

OOMOL_CONNECT_ALLOWED_ACTIONS מקבל רשימת היתרים (allowlist) מופרדת בפסיקים ומבין את service.* ו-*. OOMOL_CONNECT_BLOCKED_ACTIONS הוא רשימת החסימות (denylist), והוא בעל העדיפות העליונה. הגדרת רשימת ההיתרים ל-github.get_current_user,github.list_issues משמעותה שכל פעולה אחרת תסורב ללא קשר לבקשת הסוכן, וזהו ההבדל בין טעות לבין אירוע אבטחה. אסימוני זמן ריצה (runtime tokens) נושאים כללי פעולה משלהם בנוסף לכללים הגלובליים, ורשימת ה-allowedProxies שלהם מתחילה כריקה, לכן POST /v1/proxy/:service מסורב עד שתעניקו לו הרשאה. נקודת הקצה של ה-proxy מעבירה בקשה גולמית לספק עם פרטי הזיהוי שלכם מצורפים, לכן השאירו אותה ריקה אלא אם סוכן ספציפי זקוק לה.

OOMOL_CONNECT_ALLOW_PRIVATE_NETWORK מוגדר כברירת מחדל ל-false, מה שמונע מחיבור לספק שמתארח באופן עצמי להצביע על כתובת פרטית, כגון שירות המטא-דאטה של הענן ב-169.254.169.254, או מסד הנתונים שלכם באותה רשת. השאירו זאת כבוי. הפעילו זאת רק עבור ספק שאתם מארחים בעצמכם.

גיבוי השרת המכיל את כל האסימונים

שני דברים הם בעלי חשיבות, וכל אחד מהם חסר תועלת ללא השני. מסד הנתונים ב-/app/data/connect.sqlite בתוך ה-volume ששמו connector-data מכיל את פרטי הזיהוי המוצפנים. מפתח ההצפנה ב-.env משמש לפענוח שלהם. גיבוי של ה-volume ללא המפתח לא יאפשר שחזור, והמפתח ללא ה-volume לא יאפשר שחזור; לכן, יש לשמור את המפתח במנהל הסיסמאות שלכם ואת ה-volume בסבב הגיבויים הרגיל שלכם.

עצרו את ה-container לפני העתקת קובץ ה-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

שם ה-volume מורכב משם תיקיית הפרויקט שלכם בצירוף _connector-data, וזו הסיבה שהפקודה הראשונה מופיעה שם: העתיקו את השם האמיתי לתוך הפקודה השלישית. שלחו את הארכיון אל מחוץ ל-VPS באמצעות גיבויי restic מ-VPS, פעולה המצפינה את המידע לפני יציאתו מהשרת, שכן ארכיון זה הוא מאגר פרטי הזיהוי.

זמן הריצה שומר הרצות פעולה אחרונות כרשומות ביקורת, 5,000 במספר כברירת מחדל, כך שה-console יכול להציג לכם איזה agent הריץ מה ומתי. לוג זה הוא הדבר הראשון שיש לקרוא כאשר agent מתנהג בצורה חריגה. כוונו גם דף סטטוס של Uptime Kuma אל https://connect.example.com/health. כאשר ה-gateway מפסיק להגיב, ה-agents נכשלים בדרכים מבלבלות, והידיעה שה-gateway אינו זמין חוסכת שעה של קריאת פלטי ה-agents.

מה משתבש, ואיזו הודעה תראה

redirect_uri_mismatch אצל הספק. יש הבדל בין ה-origin לבין ה-callback URL הרשום. השווה את המחרוזת המדויקת מתוך /api/oauth/configs מול הגדרות היישום אצל הספק, כולל https מול http וכל לוכסן (trailing slash) בסוף.

כל קריאת /api מחזירה 401. ה-header של ה-admin token חסר או שגוי. ה-header הוא Authorization: Bearer <token>, והקונסולה מול הדפדפן דורשת את אותו ה-token.

המכולה רצה, והפרטים נשמרים בטקסט גלוי. זה מה שקורה כאשר OOMOL_CONNECT_ENCRYPTION_KEY לא מגיע למכולה, כיוון שסביבת הריצה שומרת את רשומות פרטי ההתחברות ללא הצפנה במקום לסרב לעלות. הוכח זאת בהתקנה שלך: חבר ספק עם API key שניתן לזהות, ולאחר מכן חפש אותו בבסיס הנתונים.

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

ספירה הגבוהה מ-0 משמעותה שהמפתח אינו פעיל, לכן ודא ש-.env נמצא באותה תיקייה כמו compose.yaml ושהערך ב-docker compose config מוצג. כאשר המפתח מוגדר, אותה חיפוש יחזיר 0, כיוון שהרשומה חתומה ב-AES-256-GCM (תקן הצפנה מתקדם, מפתח 256-ביט, מצב Galois/counter).

שום דבר לא מתפענח לאחר שחזור. מפתח ההצפנה השתנה או אבד. הוא לעולם לא נכתב לצד הנתונים, כחלק מהתכנון, לכן אין נתיב שחזור ואין כרטיס תמיכה שיכול לעזור. חבר מחדש כל ספק. החלפת מפתחות (rotation) נתמכת באמצעות משתנה מפתח נפרד ופקודת נתונים בסביבת הריצה, לכן קרא את ה-release notes הנוכחיים לפני שתבצע החלפה כלשהי.

הסוכן מקבל שגיאה המציינת פעולה שהוא יכול לראות בקטלוג. גילוי (discovery) וביצוע הם תהליכים נפרדים. פעולה יכולה להופיע ב-search_actions ועדיין להיחסם על ידי OOMOL_CONNECT_ALLOWED_ACTIONS, על ידי ה-denylist, או על ידי הכללים של אותו ה-token של סביבת הריצה.

שדרוגים. גבה את ה-volume, ערוך את ה-image tag ל-release החדש, ולאחר מכן בצע docker compose pull && docker compose up -d. עקוב אחר docker compose logs -n 50 connector עבור שורת הגירה (migration), והרצ מחדש את בדיקת התקינות ופעולה אחת אמיתית לפני שתסמוך עליו שוב. חזרה לגרסה קודמת (rollback) משמעותה החזרת ה-tag הישן, מה שעובד רק בזכות העובדה שביצעת לו pinning.

FAQ

האם אני זקוק לדומיין ציבורי כדי לארח את Open Connector בעצמי?

עבור ספקים המשתמשים ב-API key, התשובה היא לא: gateway ב-127.0.0.1 מספיק. עבור OAuth, התשובה היא כן בפועל. הספק מפנה את הדפדפן ל-callback URL שלך, לכן הכתובת הזו חייבת להיות נגישה מהאינטרנט הציבורי, וספקים מסרבים לעבוד עם http:// רגיל מחוץ ל-localhost. הגדירו את OOMOL_CONNECT_ORIGIN לשם המארח (hostname) שלכם ב-https:// לפני ההפעלה הראשונה, ורשמו את <origin>/oauth/callback באפליקציית ה-OAuth של הספק.

מה קורה אם אאבד את מפתח ההצפנה של Open Connector?

לא ניתן לפענח את פרטי ההתחברות המאוחסנים, ואין אפשרות שחזור. המפתח אינו נשמר לעולם לצד הנתונים בכוונה תחילה, כך שאף אחד שמחזיק במסד הנתונים לא יכול לקרוא אותם, כולל אתם. האפשרות היחידה שלכם היא להגדיר מפתח חדש ולחבר מחדש כל ספק. שמרו את המפתח במנהל סיסמאות ואת מסד הנתונים בסבב הגיבויים שלכם, כיוון ששחזור דורש את שניהם.

האם סוכן ה-AI שלי יכול לראות את ה-access token של הספק?

לא כאשר הוא מבצע קריאות דרך ה-gateway. הסוכן מבצע אימות מול ה-runtime token שמתחיל ב-oct_, וה-gateway מחדיר את פרטי ההתחברות של הספק לבקשה היוצאת בשרת, ומחזיר רק את התגובה. שני דברים מפרים את ההפרדה הזו: ה-endpoint של /v1/proxy/:service, שמעביר בקשות גולמיות עם פרטי ההתחברות שלכם מצורפים (ושההרשאות שלו מתחילות ריקות מסיבה טובה), והדבקה ידנית של API key לתוך הסוכן, מה שעוקף את ה-gateway לחלוטין.

האם ה-gateway צריך להיות נגיש מהאינטרנט הציבורי?

רק /oauth/callback צריך להיות נגיש. פרסמו את פורט המכולה ב-127.0.0.1 כדי שחוקי ה-NAT של Docker לא יחשפו אותו מעבר ל-firewall שלכם, והציבו reverse proxy בחזית. לאחר מכן, בדקו קריאת פעולה אחת ללא ה-header של authorization. אם היא מצליחה, הגבילו את /api, /v1 ו-/mcp ב-proxy לכתובות שמהן הסוכנים שלכם פועלים, עד שרק קריאות מאומתות יעבדו.

האם Open Connector מוכן לשימוש בסביבת ייצור?

הוא מופץ תחת רישיון Apache 2.0 ומתפתח במהירות: המאגר הופיע ב-29 ביוני 2026 וגרסה v1.3.3 שוחררה ב-30 ביולי 2026, לכן התייחסו לכל מספר גרסה במדריך זה כאל תמונת מצב של ה-1 באוגוסט 2026. הריצו אותו כשהוא מקובע ל-release tag, לעולם לא על latest או tip, קראו את הערות השחרור לפני כל שדרוג, ושמרו גיבוי של ה-volume שביצעתם לו שחזור לפחות פעם אחת. התכנון איתן עבור שרת שבבעלותכם, והסיכון טמון בקצב השינויים של הגרסאות, לא בארכיטקטורה.