מאת Matt Connor 2026-08-07 · עודכן 2026-09-01

אירוח עצמי של Octop: עוזר AI מרובה משתמשים ב-Docker

למדו כיצד להריץ את Octop על שרת VPS באמצעות Docker Compose. המדריך כולל הגדרת גרסה קבועה, הפרדת משתמשים, תמיכה ב-OpenAI API ופתרון בעיות אבטחה ב-TLS ללא שימוש ב-curl installer.

מהו Octop ומדוע כדאי לארח אותו באופן עצמי

Octop הוא עוזר AI המיועד לאירוח עצמי עבור משק בית או צוות קטן. הסיבה לארח את Octop באופן עצמי, במקום להשתמש בממשק צ'אט פשוט, היא היכולת שלו להפריד בין משתמשים. בעוד ש-Open WebUI מספק ממשק דפדפן מול מודל, Octop מוסיף ניהול חשבונות עם הרשאות מנהל, סביבת עבודה פרטית וסט הרשאות ייחודי לכל משתמש, לצד ספריית סוכנים מומחים שכל משתמש יכול להחליף ביניהם בהתאם למשימה. זהו ההבדל המאפשר לשרת VPS אחד לשרת חמישה אנשים במקום אדם אחד בלבד.

הפרויקט נמצא בכתובת github.com/TencentCloud/Octop. מדובר בתהליך יחיד המספק לוח בקרה מבוסס דפדפן, ממשק שורת פקודה, ערוצי צ'אט (Feishu, DingTalk, QQ, Discord, WeCom) ומשימות מתוזמנות, כאשר הכל מגובה במסד נתונים יחיד מסוג SQLite תחת ~/.octop/. כל המדריך להלן נכתב עבור גרסה v0.9.19, ששוחררה ב-5 באוגוסט 2026. אם אתם עדיין מתלבטים בין פלטפורמות, ה-השוואה בין חלופות ל-Open WebUI שניתן להריץ על VPS מכסה את התחום הרחב יותר.

נקודה אחת שחשוב להבהיר לפני שמשקיעים בכך ערב שלם: Octop היא תוכנה שטרם הגיעה לגרסה 1.0, והיא מפורסמת על ידי ארגון GitHub של ספקית, עם כ-900 כוכבים נכון לאוגוסט 2026. הפרויקט מתקדם במהירות, כפי שמעידים מספרי הגרסאות, ואין כאן הבטחה למסלול שדרוג יציב. קבעו גרסה (pin), קראו את יומן השינויים (changelog) ושמרו גיבויים.

מה נדרש לפני שמתחילים

שרת VPS המריץ את Ubuntu 24.04 עם Docker Engine ותוסף Compose. חדשים ל-Compose? התחילו עם יסודות Docker Compose עבור VPS.
git, מכיוון שתבצעו checkout ל-release tag במקום לבצע pull לתמונה (image).
שם מתחם המצביע אל ה-VPS, מכיוון שנדרש TLS (אבטחת שכבת תעבורה) לפני השירות.
Backend של מודל התומך ב-OpenAI API: התקנת Ollama מקומית, gateway באירוח עצמי, או מפתח בתשלום.

Octop עצמו הוא שירות קל משקל. הוא מורכב מתהליך Python וקובץ SQLite. המשקל נובע מה-backend של המודל, לכן אם בכוונתכם להריץ את המודל על אותו השרת, התאימו את גודל השרת לדרישות המודל.

מדוע איננו ממליצים על מתקין ה-curl

ה-README פותח בהוראת התקנה בשורה אחת:

curl -fsSL https://finnie-1258344699.cos.ap-guangzhou.myqcloud.com/octop/install.sh | bash

איננו ממליצים על שיטה זו בשרת שחשוב לכם, מסיבה קונקרטית אחת: הסקריפט אינו נמצא במאגר הקוד (repository). הוא מוגש מתוך bucket של Tencent Cloud Object Storage. דבר בו אינו מכוסה על ידי git tag או commit, לכן לא ניתן לבצע diff בין הסקריפט של היום לזה של השבוע שעבר, ואין היסטוריה המתעדת שינויים. ה-bucket יכול להגיש תוכן שונה מחר, ושום דבר בפרויקט לא יתעד זאת. העברת הפלט ישירות ל-bash משמעותה גם שהמכונה מריצה את הסקריפט לפני שקראתם שורה אחת ממנו.

המתקין גם כותב ישירות למערכת ההפעלה המארחת במקום למכולה. הוא משתמש ב-uv כדי להוריד את Python 3.12 ולבנות סביבה שמנהל החבילות שלכם אינו מכיר, כך שהסרתה לאחר מכן היא משימה ידנית.

קיימות שתי אפשרויות טובות יותר. הורידו את הסקריפט, קראו אותו, ורק אז הריצו אותו; זה יגזול מכם שלושים שניות: curl -fsSL <url> -o install.sh, לאחר מכן less install.sh, ולבסוף bash install.sh. לחלופין, השתמשו ב-Docker, המהווה את המשך המדריך הזה. חבילת ה-PyPI (pip install octop) היא לפחות תוצר בעל גרסה שניתן להצמיד (pin) ל-release מסוים.

פריסת Octop באמצעות Docker Compose, בגרסה v0.9.19

נכון לאוגוסט 2026, לא קיימת תמונת Docker רשמית להורדה. קובץ ה-Compose המצורף בונה את התמונה ישירות ממאגר הקוד, לכן קיבוע גרסה מחייב ביצוע checkout לתגית ה-git המתאימה. זהו שלב נוסף מעבר למה שנדרש ברוב הפרויקטים לאירוח עצמי, שכן פרויקטים כמו סביבת עבודה עצמית של AFFiNE מסתמכים על תגית תמונה מפורסמת ולא דורשים בנייה על ה-VPS שלכם. תהליך ה-clone, ה-checkout והבנייה להלן זהה לזה שמתואר ב-מדריך הפריסה של openGym, כך שאם כבר ביצעתם זאת בעבר, המבנה ייראה לכם מוכר.

git clone https://github.com/TencentCloud/Octop.git
cd Octop
git checkout v0.9.19

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

services:
  octop:
    build:
      context: ..
      dockerfile: docker/Dockerfile
    image: octop:latest
    container_name: octop
    restart: unless-stopped
    ports:
      - "${OCTOP_PORT:-8088}:${OCTOP_PORT:-8088}"
    volumes:
      - ${OCTOP_DATA:-~/.octop}:/data/.octop
    environment:
      - HOME=/data
      - OCTOP_BIND_HOST=0.0.0.0
      - OCTOP_PORT=${OCTOP_PORT:-8088}
      - OCTOP_DEFAULT_PASSWORD=${OCTOP_DEFAULT_PASSWORD:-octop}
      - OCTOP_ADMIN_USERNAME=${OCTOP_ADMIN_USERNAME:-admin}
      - OPENAI_API_KEY=${OPENAI_API_KEY:-}

שימו לב לבלוק build:. הערך image: octop:latest הוא השם שניתן לבנייה המקומית שלכם, ולא הפניה ל-registry, לכן latest כאן מתייחס למה שקומפל לאחרונה. הגדירו נתיב נתונים מפורש במקום להסתמך על ברירת המחדל, וקבעו סיסמה חזקה לחשבון ה-admin לפני העלייה הראשונה. הכניסו זאת לתוך docker/.env:

OCTOP_PORT=8088
OCTOP_ADMIN_USERNAME=admin
OCTOP_DEFAULT_PASSWORD=<a long random password>
OCTOP_DATA=/srv/octop-data

מלכודת אחת כאן חשובה יותר מכל שאר הקובץ. Docker Compose קורא את docker/.env רק כדי להציב ערכים במקומי ה-${...} בתוך ה-YAML. מפתח שתוסיפו לקובץ זה לא יגיע למכולה אלא אם הוא מופיע גם תחת environment: בקובץ ה-Compose. הוספת OCTOP_ACCESS_TOKEN_TTL ל-.env בלבד לא תבצע דבר, ללא כל התראה. החלופה היא כתיבת אותם מפתחות לתוך ~/.octop/env בתוך תיקיית הנתונים הממופה, ש-Octop טוען בעת העלייה. ה-מדריך לקובצי env וסודות ב-Docker Compose מסביר מדוע שני המנגנונים הללו אינם זהים.

בנו והפעילו את השירות:

docker compose -f docker/docker-compose.yml up -d --build
docker compose -f docker/docker-compose.yml ps
curl http://127.0.0.1:8088/api/health

מופע תקין משיב לבדיקת הבריאות (health check) ב-{"status":"ok","version":"..."}. בכל מקרה אחר, קראו את docker compose -f docker/docker-compose.yml logs -f octop לפני שתנסו לגשת דרך הדפדפן.

כעת, תנו לתמונה שבניתם שם בעל משמעות, שכן ה---build הבא ידרוס את octop:latest ולא תוכלו להבדיל ביניהן:

docker image tag octop:latest octop:0.9.19

העלייה הראשונה מריצה את octop init וכותבת את פרטי ההתחברות הראשוניים לתוך ה-volume של הנתונים:

docker exec -it octop cat /data/.octop/credential.txt

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

אל תפרסמו את פורט 8088

השורה ports: לעיל מבצעת binding לכל ממשקי הרשת ב-VPS. ברגע שה-container עולה, לוח הבקרה חשוף באינטרנט הציבורי בטקסט גלוי, עם סיסמת ברירת מחדל. ברירת המחדל של OCTOP_BIND_HOST ב-Octop היא 127.0.0.1; קובץ ה-Compose דורס אותה ל-0.0.0.0 כיוון שהתהליך חייב לקבל תעבורה מחוץ ל-network namespace של עצמו. הדריסה הזו תקינה. החלק שחושף אתכם הוא ה-published port.

ערכו את השורה ports: בתוך docker/docker-compose.yml כך שהמיפוי יאזין ל-loopback בלבד:

    ports:
      - "127.0.0.1:${OCTOP_PORT:-8088}:${OCTOP_PORT:-8088}"

אל תנסו לתקן זאת באמצעות קובץ override פשוט. Compose משרשר את רשימות ה-ports מקבצים מרובים במקום להחליף אותן, כך שתמצאו את עצמכם מפרסמים את שני המיפויים והשני ייכשל ב-binding. אם ברצונכם להשאיר את קובץ ה-upstream ללא שינוי, השתמשו בתגית !override על הרצף, שזו הדרך המתועדת להחלפה במקום הוספה. ה-הסבר על האופן שבו Compose ממזג קבצים מרובים מכסה את שאר חוקי המיזוג הללו.

ביצוע binding ל-loopback פותר גם בעיה שבה הייתם נתקלים מול ה-firewall. ‏Docker כותב את חוקי ה-published-port שלו לטבלת ה-nat לפני ה-chains ש-ufw מנהל, לכן ufw deny 8088 לא עוצר פורט של container שפורסם. פורט שמבצע binding ל-127.0.0.1 לעולם לא יהיה נגיש מבחוץ, ללא קשר למה ש-ufw "חושב", וזו הסיבה שמדובר בפתרון הנכון ולא בפתרון משני.

הצבת TLS בחזית באמצעות reverse proxy

Caddy הוא הדרך הקצרה ביותר, כיוון שהוא מבקש את התעודה באופן עצמאי דרך ACME (סביבת ניהול תעודות אוטומטית) ומבצע proxy ל-WebSockets ללא צורך בהגדרה נוספת:

octop.example.com {
    reverse_proxy 127.0.0.1:8088
}

nginx דורש תשומת לב רבה יותר, כיוון ש-Octop מעביר צ'אט ב-WebSocket:

server {
    listen 443 ssl;
    server_name octop.example.com;

    ssl_certificate     /etc/letsencrypt/live/octop.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/octop.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8088;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_buffering off;
        proxy_read_timeout 3600s;
    }
}

כל שורה שם מבצעת תפקיד. הצ'אט פועל על גבי WS /agents/{id}/chat/ws, לכן ללא proxy_http_version 1.1 ושני ה-headers של ה-upgrade, ה-nginx משיב לניסיון ה-upgrade בשגיאת 400 Bad Request: לוח הבקרה נטען כרגיל, אך כל הודעה שאתם שולחים נתקעת לנצח ללא שגיאה בדף. proxy_buffering off חשוב כיוון שנקודת הקצה של ה-human-in-the-loop resume מחזירה text/event-stream, ואירועי SSE (אירועים שנשלחים מהשרת) שמוחזקים ב-buffer של ה-proxy מגיעים כגוש אחד בסוף במקום להגיע בסטרימינג. proxy_read_timeout מכסה הרצות ארוכות של כלים, שכן ברירת המחדל של 60 שניות קוטעת סוכן באמצע משימה ומתעדת upstream timed out (110: Connection timed out).

כיצד אימות JWT מתנהג מאחורי ה-proxy

Octop מבצע אימות באמצעות bearer token, ולא באמצעות cookie. ה-POST /api/auth/login מחזיר {access_token, role, user, ...} וקריאות מאוחרות יותר נושאות את Authorization: Bearer <access_token>. עבור reverse proxy אלו חדשות טובות: אין דומיין של cookie, אין דגל Secure ואין כלל SameSite שניתן לטעות בהם, לכן session שעבד ב-http://127.0.0.1:8088 יתנהג באותו אופן ב-https://octop.example.com.

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

ה-WebSocket נושא את ה-token בתוך ה-URL. נקודת הקצה היא WS /agents/{id}/chat/ws?token=<jwt>, כיוון ש-JavaScript בדפדפן אינו יכול להגדיר Authorization header במהלך ה-handshake של ה-WebSocket. הצפנת TLS מגנה על ה-token בזמן המעבר. היא אינה מגנה עליו מפני הלוגים שלכם: כברירת מחדל, nginx כותב את שורת הבקשה המלאה, כולל ה-query string, ל-access_log, כך ש-token תקין של משתמש אמיתי עלול להגיע לקובץ טקסט גלוי על השרת. רשמו בלוג את הנתיב ללא הארגומנטים. $uri הוא הנתיב המנורמל לאחר הסרת ה-query string, לכן הציבו אותו בבלוק http והפנו אליו מה-server:

log_format octop_noargs '$remote_addr [$time_local] '
                        '"$request_method $uri $server_protocol" '
                        '$status $body_bytes_sent';
access_log /var/log/nginx/octop.log octop_noargs;

אין אפשרות ל-logout פר-session. ברירת המחדל של OCTOP_ACCESS_TOKEN_TTL היא 86400, כך ש-token נשאר תקף ל-24 שעות מרגע ההתחברות. הדרך המתועדת היחידה לבטל תוקף של token היא octop admin rotate-jwt-secret, אשר מחליף את מפתח החתימה השמור ב-~/.octop/secrets/jwt_secret ומבטל מיידית את כל ה-tokens הפעילים עבור כולם. לכן, כאשר מישהו עוזב את הצוות, סדר הפעולות הוא: מחיקת המשתמש, החלפת ה-secret, ולאחר מכן הנחיה לשאר המשתמשים להתחבר מחדש. אם זה נשמע כבד מדי, קצרו את משך החיים, וזכרו להוסיף את המשתנה לרשימת environment: וגם ל-.env:

OCTOP_ACCESS_TOKEN_TTL=28800

הגנה מפני brute force מובנית: ברירת המחדל של OCTOP_LOGIN_MAX_ATTEMPTS היא 5 ניסיונות כושלים ושל OCTOP_LOGIN_LOCKOUT_SECONDS היא 900 שניות, כך שמשתמש שנחסם פשוט ממתין חמש-עשרה דקות במקום להיתקל בהתקנה שבורה. ל-Octop יש מאגר משתמשים משלו ואין תמיכה מתועדת ב-OIDC בגרסה v0.9.19, לכן אם אתם זקוקים ל-single sign-on אמיתי, עליכם להציב לפניו proxy מאמת, וזה בדיוק הייעוד של שרת Authentik בהתקנה עצמית.

הפניית Octop ל־backend של מודל

ספקי מודלים מוגדרים עבור כל סוכן בלוח הבקרה, ו־octop provider list מציג את ההגדרות הנוכחיות. Octop מגיע עם הגדרות מראש עבור ממשקי API תואמי OpenAI, עבור DashScope (Qwen) ועבור Ollama. פרטי ההתחברות נשמרים בטבלה providers בתוך מסד הנתונים SQLite שלכם. הבחירה משפיעה על העלויות שלכם ועל המידע שיוצא מהשרת.

מודל מקומי עם Ollama. שום מידע לא עוזב את השרת, ואתם משלמים ב־RAM במקום ב־tokens. פרט טכני שגורם לבעיות: מכולה (container) לא יכולה לגשת ל־Ollama של המארח בכתובת 127.0.0.1:11434, כיוון שכתובת זו היא ה־loopback של המכולה עצמה. הוסיפו הגדרת host gateway לשירות:

    extra_hosts:
      - "host.docker.internal:host-gateway"

לאחר מכן, הגדירו את ה־base URL של הספק ל־http://host.docker.internal:11434/v1, שהוא הנתיב התואם ל־OpenAI ב־Ollama. הזינו מחרוזת כלשהי בשדה ה־API key; Ollama מתעלם ממנו, אך לקוחות OpenAI מסרבים לשלוח בקשה ללא מפתח. כדי שזה יעבוד, Ollama חייב להאזין גם מחוץ ל־loopback, מה שאומר להגדיר OLLAMA_HOST=0.0.0.0:11434 בקובץ ה־systemd unit שלו. זהו החלק המסוכן: ל־Ollama אין מנגנון אימות, לכן פורט 11434 פתוח בכתובת IP ציבורית הופך את השרת שלכם לזמין לכל מי שסורק אותו. אפשרו גישה רק מטווח הכתובות הפרטי של Docker, sudo ufw allow from 172.16.0.0/12 to any port 11434 proto tcp, וחסמו את השאר. המדריך הרצת Ollama על גבי VPS מכסה את דרישות המשאבים למודלים, והמדריך השוואה בין Ollama ל־vLLM מסביר מתי Ollama מפסיק להיות הפתרון המתאים.

אזהרה נוספת לגבי מודלים מקומיים, שכן היא נראית כמו באג ב־Octop אך אינה כזו: סוכנים פועלים על ידי קריאה לכלים (tools), וה־prompt המערכתי יחד עם הגדרות הכלים וההיסטוריה יוצרים prompt ארוך. Ollama מגיש מודלים עם חלון הקשר (context window) ברירת מחדל צנוע, ולכן תחילת ה־prompt, שבה נמצאות הגדרות הכלים, יוצאת מהחלון. כתוצאה מכך, המודל מפסיק להשתמש בכלים או ממציא כלים שלא קיימים. העלו את num_ctx ל־16k או 32k ובחרו מודל שמסוגל לבצע קריאות לפונקציות (function calling) בצורה טובה. תשובה שנעצרת באמצע משפט היא בעיה הפוכה עם הגדרה שונה, num_predict; אם התשובות מגיעות קטועות, כדאי לבדוק היכן מוגדר num_predict ומה done_reason מציג לפני שמאשימים את הסוכן. אם אתם מעדיפים להתחיל עם מודל ספציפי במקום רשימה קצרה, כדאי לנסות את Nemotron 3.5 Lightning; המדריך שם מספק את ה־tag המדויק למשיכה, את דרישות ה־RAM, והאם הרצה על CPU בלבד מספיקה.

Gateway בניהול עצמי. הציבו Gateway מסוג LiteLLM בניהול עצמי בין Octop לכל השאר. כך תקבלו base URL אחד, מפתח נפרד לכל משתמש, הגבלות תקציב ולוג מרכזי. תוכלו גם להחליף את המודל שמאחורי ה־gateway מבלי לערוך הגדרות בתוך Octop.

API בתשלום. האיכות הגבוהה ביותר, עם פשרה ברורה: תוכן השיחה עוזב את השרת שלכם ומגיע לספק, מה שסותר את המטרה העיקרית של אירוח עצמי. המפתח מוזן ב־docker/.env כ־OPENAI_API_KEY, שקובץ ה־Compose כבר מעביר הלאה.

בכל אפשרות שתבחרו, קובץ ה־Compose כולל גם את OCTOP_LANGFUSE_ENABLED, LANGFUSE_PUBLIC_KEY, LANGFUSE_SECRET_KEY ו־LANGFUSE_BASE_URL, כך שתוכלו לשלוח עקבות (traces) ל-מופע Langfuse משלכם ולראות מה הסוכנים עושים בפועל, במקום לנחש מתוך חלון הצ'אט.

משתמשים, תפקידים וספריית הסוכנים המשותפת

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

יש לנהוג בזהירות עם הכלים. Octop מציעה אישור כלים ומנגנוני הגנה (guardrails) לפקודות shell, ושניהם אכן קיימים, אך סוכן שמריץ פקודות shell מריץ אותן בתוך ה-container של Octop כאשר ה-data volume שלכם מותקן בו. מנגנוני ההגנה מצמצמים את הנזק שעלול להיגרם מ-prompt לא זהיר. הם אינם מהווים גבול של sandbox, לכן השאירו את אישור הכלים פעיל עבור כל מי שלא הייתם נותנים לו גישה ישירה ל-shell. אם אתם שוקלים זאת מול אפשרויות אחרות, סקירת סוכני ה-AI ב-self-hosting משווה כיצד כל אחד מהם מטפל בכך.

שדרוג פרויקט שמשחרר גרסאות בתדירות גבוהה

ChartDays between Octop releases, v0.9.16 to v0.9.19 (repository tags, 7 August 2026)

version

days_since_previous_release

v0.9.16

v0.9.17

v0.9.18

v0.9.19

The data behind this chart

[
  {
    "version": "v0.9.16",
    "days_since_previous_release": 2
  },
  {
    "version": "v0.9.17",
    "days_since_previous_release": 3
  },
  {
    "version": "v0.9.18",
    "days_since_previous_release": 1
  },
  {
    "version": "v0.9.19",
    "days_since_previous_release": 3
  }
]

אלו הם תאריכי התיוג מהמאגר, נכון ל־7 באוגוסט 2026. 4 גרסאות מתויגות שוחררו בתוך תשעה ימים, עם מרווח זמן קצר של 1 יום, וגרסת v0.9.19 הגיעה 3 ימים לאחר התג הקודם לה. קצב זה הוא סימן חיובי עבור הפרויקט, אך סיבה גרועה להריץ את latest. קראו את השינויים לפני שאתם מטמיעים אותם:

cd Octop
git fetch --tags
git tag --sort=-creatordate | head
NEW_TAG=$(git tag --sort=-creatordate | head -1)
git log --oneline "v0.9.19..$NEW_TAG"

בצעו גיבוי תחילה, בכל פעם, כיוון שהעברות מסד נתונים (migrations) רצות בעת העלייה, וכישלון בהעברה בפרויקט שטרם הגיע לגרסה 1.0 הוא בעיה שאתם תצטרכו לפתור בעצמכם:

docker compose -f docker/docker-compose.yml stop
sudo tar czf octop-backup-$(date +%F).tgz -C /srv octop-data
docker compose -f docker/docker-compose.yml start

לאחר מכן, בצעו checkout לתג החדש ובנו מחדש בעזרת docker compose -f docker/docker-compose.yml up -d --build. אם משהו משתבש, חזרה לתג הישן ובנייה מחדש תחזיר את הקוד למצבו הקודם, אך רק קובץ ה-tarball יחזיר את מסד הנתונים.

קובץ ה-tarball מכיל את octop.db, config.json, את ה-secret לחתימת JWT ואת credential.txt, לכן הוא רגיש בדיוק כמו השרת עצמו. שמרו עליו בהרשאות 600 ושמרו עותק מחוץ לשרת. עבור התקנות גדולות יותר, הפרויקט מספק גם את docker/docker-compose.postgres.yml, שמריץ PostgreSQL עם pgvector במקום SQLite.

מצבי כשל והודעות שגיאה נפוצות

בדיקת התקינות (health check) אינה מגיבה. curl http://127.0.0.1:8088/api/health נתקע או מסרב להתחבר. עיינו ב-docker compose -f docker/docker-compose.yml logs -f octop. מכולה שקורסת במהלך האתחול הראשוני לרוב אינה מצליחה לכתוב לספריית הנתונים; בדקו את הרשאות הבעלות על הנתיב שהגדרתם ב-OCTOP_DATA.

לוח הבקרה נטען אך הצ'אט נתקע. אין שגיאה בדף, אך אין תגובה. פתחו את מסוף המפתחים (console) בדפדפן וחפשו חיבור שנכשל ל-wss://octop.example.com/agents/.../chat/ws. ה-proxy אינו מעביר את בקשת ה-upgrade. הוסיפו את proxy_http_version 1.1 ואת ה-headers מסוג Upgrade ו-Connection.

כל התגובה מופיעה בבת אחת, בעיכוב של מספר שניות. הזרמת הנתונים (streaming) עובדת, אך מנגנון ה-buffering פעיל. הגדירו את proxy_buffering off.

bind: address already in use. תהליך אחר כבר תופס את פורט 8088. הפקודה sudo ss -tlnp | grep 8088 תציג את שם התהליך. זו השגיאה שתקבלו גם אם הוספתם כניסת ports שנייה בקובץ override במקום לערוך את הקובץ המקורי.

הסיסמה הנכונה נדחית. חמישה ניסיונות כושלים מפעילים חסימה של 900 שניות. המתינו לסיום זמן החסימה במקום לבצע התקנה מחדש.

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

הסוכן (agent) מגיב אך אינו מריץ כלי. כמעט תמיד מדובר בבעיה מקומית של המודל: חלון ההקשר (context window) קטן מדי עבור הגדרות הכלים, או שהמודל חלש בביצוע קריאות לפונקציות (function calling). הגדילו את num_ctx ונסו מודל המותאם לשימוש בכלים.

FAQ

האם Octop מהווה תחליף ל-Open WebUI?

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

מדוע לא כדאי להשתמש בסקריפט ההתקנה ב-curl של Octop?

הסקריפט מוגש מתוך דלי (bucket) של Tencent Cloud Object Storage ולא מתוך המאגר (repository), לכן הוא אינו מכוסה על ידי אף תגית git או commit. לא ניתן להשוות בין מה שהוא עושה היום לבין מה שעשה בשבוע שעבר, והזרמתו ל-bash מריצה אותו לפני שקראתם אותו. בנוסף, הוא מותקן על המארח (host) עם סביבת Python 3.12 משלו, מחוץ למנהל החבילות שלכם. הורידו אותו וקראו אותו תחילה, או בצעו פריסה באמצעות Docker Compose מתגית שנבדקה.

האם Octop יכול להשתמש במודל מקומי במקום ב-API בתשלום?

כן. Octop תומך ב-API תואם OpenAI ומגיע עם הגדרה מוקדמת ל-Ollama, לכן הפנייתו ל-http://host.docker.internal:11434/v1 תעבוד ברגע שתוסיפו את extra_hosts: ["host.docker.internal:host-gateway"] למכולה ותגדירו את OLLAMA_HOST=0.0.0.0:11434 על המארח. הגבילו את פורט 11434 ב-firewall לטווח הכתובות של Docker, כיוון של-Ollama אין מנגנון אימות משלו. צפו לכך שתצטרכו להעלות את ה-num_ctx של Ollama ל-16k או יותר, שכן הנחיות (prompts) של סוכנים עם הגדרות כלים חורגות מחלון ההקשר (context window) המוגדר כברירת מחדל, והמודל מפסיק להפעיל כלים.

האם אני זקוק ל-reverse proxy, או שאפשר לפתוח את פורט 8088?

אתם זקוקים ל-proxy. קובץ ה-Compose שמגיע עם Octop מפרסם את 8088 על כל הממשקים ללא TLS, כך שסיסמאות ו-bearer tokens יעברו באינטרנט בטקסט גלוי. שנו את הפורט המפורסם ל-127.0.0.1:8088:8088 והציבו לפניו את Caddy או nginx עם תעודה. בשימוש ב-nginx, העבירו את ה-headers של ה-WebSocket upgrade והגדירו את proxy_buffering off, אחרת הדף ייטען אך הצ'אט לא יגיב.

האם Octop מוכן לסביבת ייצור (production)?

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

#octop#self-hosting #ai-assistant #docker-compose #ollama