איך לארח את Open Connector לסוכני AI בשרת VPS

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

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

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

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

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

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

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

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

הצמדת גרסה לפני התקנת דבר כלשהו

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

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

פריסת Open Connector מאחורי TLS ב-VPS שבבעלותכם

לפני שהמכולה מופעלת, נדרשים:

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

המדריך Traefik reverse proxy עבור כמה יישומי Docker Compose עוסק בצד של ה-proxy. אותו תהליך להגדרת האישורים, מתחילתו ועד סופו עבור יישום יחיד, מתואר במדריך n8n ב-VPS עם Docker ו-HTTPS.

תחילה יש ליצור את הסודות. מפתח ההצפנה מגן על פרטי הגישה המאוחסנים. אסימון מנהל המערכת מגן על מסוף האינטרנט ועל כל משטח /api. לאף אחד מהם אין ערך ברירת מחדל, וה-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

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

כעת 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:

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

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

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 } לאחר שה-runtime פעיל. ss חייב להדפיס 127.0.0.1:3000. שורה שמכילה 0.0.0.0:3000 פירושה שמיפוי היציאה עדיין זהה לזה שבמעלה הזרם, והשער עונה ישירות לכל האינטרנט. שגיאת Connection refused בבדיקת התקינות פירושה שהמכולה עדיין אינה מאזינה, לכן קראו את הלוגים לפני שתשנו את ה-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 מחייב שימוש בשם מארח אמיתי

OOMOL_CONNECT_ORIGIN היא ההגדרה שאנשים מדלגים עליה, ודילוג עליה גורם ל-OAuth להיכשל באופן שנראה כמו באג אצל הספק. סביבת זמן הריצה בונה את כתובת ההפניה מחדש מהמקור הזה, בתבנית <origin>/oauth/callback. כאשר ההגדרה אינה מוגדרת, המקור מוגדר כברירת מחדל ל-http://localhost:3000. לכן סביבת זמן הריצה שולחת לספק כתובת הפניה מחדש 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 מפנה את הדפדפן בחזרה לכתובת הזו. לכן הכתובת חייבת להיות נגישה מהעולם החיצון, וספקים דוחים כתובות http:// רגילות בכל מקרה שאינו localhost. זו הסיבה היחידה לכך שהפריסה הזו זקוקה לשם מארח ולתעודה. הגדר את המקור לפני ההפעלה הראשונה, משום שהערך נקרא בעת האתחול. לאחר עריכת .env או compose.yaml, הפעל שוב את docker compose up -d כדי להחיל את ההגדרה.

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

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

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

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

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

שמרו את פרטי הכניסה של הלקוח, ולאחר מכן התחילו תהליך הרשאה.

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

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

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

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

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

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

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

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

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

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

עצור את הקונטיינר בזמן העתקת קובץ 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. לכן הפקודה הראשונה מופיעה כאן: הדבק את השם בפועל בפקודה השלישית. שלח את הארכיון אל מחוץ ל-VPS באמצעות גיבויי restic מ-VPS, שמצפין אותו לפני העברתו, מכיוון שהארכיון הוא מאגר פרטי האימות.

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

מה מתקלקל, ואיזו הודעה תופיע

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

כל קריאה אל /api מחזירה 401. כותרת האסימון של מנהל המערכת חסרה או מאויתת באופן שגוי. הכותרת היא Authorization: Bearer <token>, וגם מסוף האינטרנט מבקש את אותו אסימון.

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

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).

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

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

שדרוגים. גבו את אמצעי האחסון, ערכו את תגית התמונה לגרסה החדשה, ולאחר מכן docker compose pull && docker compose up -d. עקבו אחר docker compose logs -n 50 connector וחפשו שורת העברה, ולאחר מכן הריצו מחדש את בדיקת התקינות ופעולה אמיתית אחת לפני שתסמכו שוב על המערכת. כדי לחזור לגרסה קודמת, יש להחזיר את התגית הישנה. הדבר פועל רק משום שהתגית הוצמדה לגרסה מסוימת.

FAQ

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

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

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

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

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

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

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

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

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

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