אירוח עצמי של LiveContext: מדריך התקנה ודרישות שרת

מהו LiveContext ומהן עלויות ההרצה שלו

כדי לארח את LiveContext באופן עצמאי, נדרש שרת VPS עם כ־8 GB של זיכרון RAM. LiveContext CE היא פלטפורמת אוטומציה בקוד פתוח המריצה סוכני AI בתוך תהליכי האוטומציה עצמם, והיא מופצת כ־Docker Compose stack המורכב משישה קונטיינרים המבוססים על backend ב־Java. ה־README הרשמי דורש מינימום של 4 GB והמלצה על 8 GB, וקובץ ה-compose מפרט לאן מוקצה זיכרון זה.

הפרויקט זמין ב־livecontext-ai/livecontext-ce ב-GitHub, תחת רישיון AGPL-3.0. הגרסה הנוכחית נכון לאוגוסט 2026 היא v0.2.11, שפורסמה ב-3 באוגוסט 2026. כל image בנויה עבור linux/amd64 בלבד, מה שפוסל שימוש בתוכניות Arm זולות. מדריך זה מקבע את ה-tag הספציפי הזה, מציב את ה-stack מאחורי reverse proxy, ומכסה את הליך הגיבוי שאינו כלול בתיעוד הרשמי.

התאמת גודל ה-VPS לפני אירוח עצמי של LiveContext

לכל שירות בקובץ ה-compose המסופק יש הגבלת זיכרון מפורשת, כך שניתן להתאים את גודל השרת לפני השכרתו. אלו הן המגבלות הכתובות בקובץ ה-v0.2.11 compose, ולא צריכת זיכרון בפועל.

[
  {
    "label": "livecontext (backend)",
    "memory_limit_mb": 1536
  },
  {
    "label": "bridge",
    "memory_limit_mb": 512
  },
  {
    "label": "redis",
    "memory_limit_mb": 384
  },
  {
    "label": "postgres",
    "memory_limit_mb": 256
  },
  {
    "label": "minio",
    "memory_limit_mb": 256
  },
  {
    "label": "websearch (optional)",
    "memory_limit_mb": 2048
  },
  {
    "label": "searxng (optional)",
    "memory_limit_mb": 512
  },
  {
    "label": "renderer (optional)",
    "memory_limit_mb": 1024
  }
]

ה-backend לבדו מוגבל ל-1536 MB. מגבלה זו חלה על תהליך Java 21, ולכן ה-JVM ינצל את רוב המשאבים הללו ויחזיק בהם. חמשת שירותי הבסיס מסתכמים בקצת פחות מ-3 GB, וה-frontend אינו מוגבל כלל, כך שהוא צורך את מה ש-Node מבקש. ב-VPS עם 4 GB זיכרון, לא נותר כמעט דבר עבור ה-kernel ועבור ה-page cache; זו הסיבה ש-4 GB מצוין כמינימום ולא כהמלצה.

הפרופילים האופציונליים הם אלו שדוחפים את דרישות השרת ל-8 GB. פרופיל ה-browser agent מוסיף מכולת Chromium המוגבלת ל-2048 MB לצד מופע חיפוש של SearXNG, ופרופיל ה-renderer מוסיף עוד 1024 MB עבור צילומי מסך וקבצי PDF. אף אחד מהם לא יופעל אלא אם תפעיל את הפרופיל שלו, לכן השאר את שניהם כבויים עד שתזדקק להם.

אם אתה כבר מריץ את n8n, תכנן להחליף אותו במקום להוסיף עליו. ה-stack המתואר ב-מדריך שלנו להרצת n8n על VPS עם Docker ו-HTTPS מורכב מתהליך Node אחד לצד Postgres, והוא פועל בנוחות על שרת קטן. LiveContext משריין עבור ה-backend שלו לבדו יותר זיכרון ממה שכל ה-stack ההוא צורך. שתי פלטפורמות אוטומציה על VPS אחד של 8 GB יפעלו היטב, עד לרגע שבו שתיהן יריצו משימה באותה דקה בדיוק. אם בכל זאת בחרת לשתף שרת, הגדר מגבלות מפורשות גם לכל השאר, באמצעות השיטה המתוארת ב-פוסט שלנו על הגדרת מגבלות זיכרון ב-Docker Compose, כדי שתהליך אוטומציה שיוצא משליטה לא יפיל את המכונה כולה.

התקנת LiveContext באמצעות Docker Compose, בקיבוע לגרסה (tag)

התחילו משרת VPS נקי עם Ubuntu 24.04, Docker Engine 24 ומעלה, ו-Compose v2. אם Docker טרם הותקן, עקבו תחילה אחר המדריך שלנו ליסודות Docker Compose ב-VPS, ולאחר מכן חזרו לכאן.

קובץ ה-README מציע את npx livecontext כפקודה להרצה בשורה אחת. זה מתאים למחשב נייד. בשרת, מומלץ שהקובץ docker-compose.yml יימצא בתיקייה שבשליטתכם; כך שדרוג מתבצע באמצעות git checkout, וניתן לבחון בדיוק אילו שינויים בוצעו.

sudo apt update && sudo apt install -y git
git clone https://github.com/livecontext-ai/livecontext-ce.git
cd livecontext-ce
git tag --list 'v*' | tail -5
git checkout v0.2.11
cp docker/.env.ce.example docker/.env.ce
chmod 600 docker/.env.ce

קובץ ה-compose כבר מקבע כל image לגרסה (tag) ספציפית, לדוגמה ghcr.io/livecontext-ai/livecontext-ce:v0.2.11. ביצוע checkout ל-git tag התואם שומר על סנכרון בין קובץ ה-compose לבין ה-images, כיוון שקובץ ה-compose עבור v0.2.11 נכתב בהתאמה לאותם images. אל תשנו את ה-tags ל-latest. תגית latest משתנה ללא התראה, וה-backend מריץ את ה-migrations של מסד הנתונים בכל עלייה; לכן, pull מקרי עלול לקדם את ה-schema שלכם בשלוש לפנות בוקר, ללא אפשרות חזרה מלבד שחזור מגיבוי.

ערכו את docker/.env.ce לפני ההפעלה הראשונה (הסעיף הבא מפרט מה יש לשנות), ולאחר מכן העלו את ה-stack.

docker compose --env-file docker/.env.ce up -d
docker compose --env-file docker/.env.ce ps

השתמשו באותו דגל --env-file בכל פקודת compose במדריך זה. Compose קורא את הקובץ מחדש בכל הרצה; פקודה ללא הדגל תחזור להגדרות ברירת המחדל המוטמעות בקובץ ה-compose, ועלולה לחשוף פורטים שונים מאלו שהגדרתם.

בדיקת התקינות (healthcheck) של ה-backend כוללת start_period של 120 שניות וסורקת את /actuator/health, לכן docker compose ps ידווח על שירות livecontext כ-health: starting במשך כשתי הדקות הראשונות, בזמן שה-migrations והרישום של הכלים מתבצעים. זהו מצב תקין. בדיקה מהירה מהשרת:

curl -s localhost:8080/actuator/health

הפקודה אמורה להדפיס {"status":"UP"}. כאשר זה קורה, פתחו את ממשק ה-web בפורט 3000. החשבון הראשון שתיצרו יהפוך למנהל המערכת (admin), לכן צרו את החשבון שלכם לפני שהפורט יהיה נגיש לאחרים. זוהי הסיבה החשובה ביותר לא לחשוף את פורט 3000 לאינטרנט ביום הראשון.

ערכי ה-env שעליך לשנות

קובץ הדוגמה מגיע עם הגדרות ברירת מחדל תקינות כדי שהמערכת תעלה על מחשב נייד. חלקן אינן מאובטחות עבור שרת ציבורי.

POSTGRES_PASSWORD=<random>
MINIO_ROOT_USER=<not minioadmin>
MINIO_ROOT_PASSWORD=<random>
CREDENTIAL_ENCRYPTION_PASSWORD=<random>
CREDENTIAL_ENCRYPTION_SALT=<random>
ANTHROPIC_API_KEY=sk-ant-...
FRONTEND_PORT=3000
BACKEND_PORT=8080
GATEWAY_PUBLIC_URL=https://lc-api.example.com

צור כל ערך אקראי באמצעות openssl rand -base64 32. הערות על הערכים הקריטיים:

• POSTGRES_PASSWORD ו-MINIO_ROOT_PASSWORD מגיעים כ-postgres ו-minioadmin. אף אחד מפורטי מסד הנתונים אינו מפורסם למארח, לכן הם אינם חשופים ישירות, אך כל מכולה שתחבר בהמשך לאותה רשת תוכל להגיע לשניהם באמצעות ברירת המחדל המתועדת.
• CREDENTIAL_ENCRYPTION_PASSWORD ו-CREDENTIAL_ENCRYPTION_SALT נוצרים אוטומטית אם משאירים אותם ריקים. הגדר אותם בעצמך במקום זאת. פרטי הגישה שזרימות העבודה שלך מאחסנות מוצפנים באמצעות צמד זה, לכן שחזור של dump ממסד הנתונים על שרת חדש ללא אותה סיסמה ואותו salt יגרום לכך ששורות פרטי הגישה לא יהיו קריאות. הגדר אותם פעם אחת, ולאחר מכן התייחס ל-docker/.env.ce כחלק מהגיבוי.
• FRONTEND_PORT ו-BACKEND_PORT מוצבים במיפויי הפורטים כ-${FRONTEND_PORT:-3000}:3000 ו-${BACKEND_PORT:-8080}:8080. קובץ ה-env לדוגמה מגדיר את שניהם במפורש, והערכים שהוא מגיע איתם אינם תמיד 3000 ו-8080. קרא את העותק שלך במקום להניח הנחות.
• GATEWAY_PUBLIC_URL הוא ה-origin של ה-backend כפי שהוא נראה מהדפדפן. הוא הופך למשמעותי ברגע שמעורב reverse proxy. ראה את הסעיף הבא.
• מפתחות המודל (ANTHROPIC_API_KEY, OPENAI_API_KEY, GOOGLE_API_KEY, ובאופן אופציונלי MISTRAL_API_KEY או DEEPSEEK_API_KEY) נמצאים כאן בטקסט גלוי. מלא רק את הספק שבו אתה משתמש בפועל.

מה עושים ששת הקונטיינרים

• postgres מריץ את pgvector/pgvector:pg16 כקונטיינר livecontext-db, ומכיל את מסד הנתונים בשם livecontext. תוסף pgvector כלול שם לצורך חיפוש וקטורי (embedding search), לכן אימג' postgres:16 רגיל לא יתאים.
• redis מריץ את redis:7-alpine עם appendonly yes ו---maxmemory-policy noeviction. מדיניות זו מכוונת: Redis נושא כאן את התור ואת מצב הריצה, כך שכאשר הוא מגיע לתקרת הזיכרון שלו, הוא מחזיר שגיאה לכותב במקום להשליך מפתחות בשקט. שגיאה שניתן לראות עדיפה על עבודה שנעלמת.
• minio הוא אחסון אובייקטים תואם S3 עבור קבצים העוברים בתהליכי עבודה (workflows). קונטיינר minio-init חד-פעמי מריץ את mc mb myminio/workflow-files --ignore-existing בעת העלייה, יוצר את ה-bucket ומסיים את פעולתו. מצב תקין הוא לראות את minio-init כ-exited (0) בתוך docker compose ps.
• bridge מכיל את מתאמי ה-CLI ואת כלי ה-MCP (פרוטוקול הקשר מודל). הוא מאזין בפורט 8093 בתוך רשת ה-Docker ואינו חשוף למארח.
• livecontext הוא ה-backend, מונוליט Java 21 בפורט 8080. הוא מריץ את מנוע ה-workflow, את התזמונים ואת הסוכנים.
• frontend הוא ממשק ה-Web מבוסס Next.js בפורט 3000. רק שני האחרונים חשופים למארח.

המידע נשמר בחמישה volumes בעלי שם: livecontext_data עבור Postgres, וכן livecontext_redis, livecontext_minio, livecontext_keys, ו-livecontext_logs. ה-Compose מוסיף להם תחילית של שם הפרויקט, שברירת המחדל שלו היא שם הספרייה, לכן ה-volume האמיתי בדיסק נקרא משהו כמו livecontext-ce_livecontext_minio. הריצו את docker volume ls והעתיקו את השמות המדויקים לפני כתיבת סקריפט גיבוי כלשהו עבורם.

docker compose down -v מוחק את כל חמשת ה-volumes. זו הדרך המתועדת להתחיל מחדש, וזו גם הדרך המהירה ביותר לאבד כל workflow שבניתם. ה--v הוא כל ההבדל.

העברת השירות אל מאחורי Traefik במקום חשיפת פורט 3000

חשיפת פורטים 3000 ו-8080 בשרת VPS ציבורי חושפת את היישום ללא TLS (אבטחת שכבת תעבורה) וללא שער לפני דף ההרשמה למנהל המערכת. חוק ufw אינו מספיק כשלעצמו, כיוון ש-Docker מחדיר חוקי iptables משלו עבור פורטים חשופים לפני השרשרת שמנהל ufw. לכן, פורט שנחשף ל-0.0.0.0 נשאר נגיש גם כאשר ufw מוגדר לחסום אותו.

הפתרון הנקי הוא לא לחשוף פורטים כלל ולאפשר ל-proxy להגיע למכולות דרך רשת Docker משותפת. צרו את docker-compose.override.yml בשורש המאגר:

services:
  frontend:
    ports: !override []
    networks:
      - default
      - proxy
  livecontext:
    ports: !override []
    networks:
      - default
      - proxy

networks:
  proxy:
    external: true

שני פרטים קובעים אם זה יעבוד. !override מחליף את רשימת הפורטים במקום למזג אותה, מה שדורש Compose בגרסה 2.24 ומעלה: בדקו זאת באמצעות docker compose version, שכן בגרסאות Compose ישנות יותר הרשימות מתמזגות והפורטים נשארים חשופים. כמו כן, default חייב להישאר בכל רשימת networks, כיוון שציון רשת כלשהי מחליף את רשת ברירת המחדל; השמטתו תנתק את ה-frontend מ-Postgres ומ-Redis. אשרו את התוצאה הממוזגת לפני הפעלת דבר מה:

docker compose --env-file docker/.env.ce config

הנתבים (routers), פותר התעודות (certificate resolver) והפניית HTTP ל-HTTPS זהים לכל יישום אחר, לכן עקבו אחר מדריך ה-reverse proxy שלנו ב-Traefik להרצת כמה יישומים על שרת VPS אחד במקום לכתוב תצורת TLS חדשה כאן. נתבו שם מתחם אחד ל-frontend בפורט 3000, ושם מתחם שני ל-livecontext בפורט 8080.

שם המתחם השני אינו אופציונלי. ממשק ה-web קורא ל-backend מהדפדפן, לכן ה-backend זקוק למקור (origin) משלו שהדפדפן יכול להגיע אליו. הגדירו את GATEWAY_PUBLIC_URL בתוך docker/.env.ce לכתובת ה-URL של ה-backend, למשל https://lc-api.example.com. אם תדלגו על כך, הדף ייטען כרגיל אך כל פעולה תיכשל, כיוון שה-UI מסיק את מקור ה-backend מכתובת הדף שפתחתם ומנסה לקרוא לפורט שה-proxy שלכם מעולם לא חשף.

מכיוון שדף ההרשמה פתוח לכל מי שמגיע אליו ראשון, כדאי להוסיף אימות (auth) בנתב ה-frontend, כך שאיש לא יראה את הדף ללא אימות ב-proxy. זהו הערך המוסף של הרצת Authentik כשכבת SSO עצמאית על גבי אותה תצורת Traefik.

היכן ממוקם מפתח המודל, ומדוע מופע לא פעיל עדיין עולה כסף

סוכנים רצים בתוך האוטומציה כאן, מה שמשנה את הכלכלה בהשוואה לכלי workflow רגיל. מפתח הספק ממוקם ב-docker/.env.ce כ-ANTHROPIC_API_KEY או כ-OPENAI_API_KEY, הוא נקרא על ידי ה-backend וה-bridge בעת העלייה, וחלה על כל המופע. הוא אינו מוגדר ברמת המשתמש. כל מי שמחזיק חשבון במופע שלכם ויכול לבנות סוכן משתמש במפתח הזה, והאדם הראשון שנרשם הוא מנהל מערכת (admin).

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

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

גיבוי של Postgres ומאגר האובייקטים

קיימים שני מאגרי נתונים וסוד אחד; אובדן של כל אחד מהשלושה יוביל לאובדן המופע שלכם. בצעו את הגיבוי של מסד הנתונים ושל ה-bucket באותו חלון זמן, כאשר ה-backend עצור, כדי למנוע מצב שבו קובץ נכתב לאחר שהשורה המתאימה לו במסד הנתונים כבר יוצאה (dumped).

cd ~/livecontext-ce
mkdir -p ~/backups
docker compose --env-file docker/.env.ce stop livecontext frontend
docker compose --env-file docker/.env.ce exec -T postgres \
  pg_dump -U postgres -d livecontext --clean --if-exists \
  | gzip > ~/backups/livecontext-db-$(date +%F).sql.gz

השתמשו בערך שהגדרתם כ-DB_USERNAME במקום ב-postgres אם שיניתם אותו. לאחר מכן, העתיקו את ה-volume של מאגר האובייקטים באמצעות השם עם הקידומת שהדפיס docker volume ls:

docker run --rm \
  -v livecontext-ce_livecontext_minio:/data \
  -v ~/backups:/backup \
  alpine tar czf /backup/livecontext-minio-$(date +%F).tgz -C /data .
docker compose --env-file docker/.env.ce start livecontext frontend
cp docker/.env.ce ~/backups/env.ce.$(date +%F)

ודאו שה-dump אינו ריק לפני שאתם מסתמכים עליו: gunzip -c ~/backups/livecontext-db-*.sql.gz | head -20 אמור להציג הצהרות CREATE TABLE ו-DROP TABLE, ולא שורת שגיאה בודדת. לאחר מכן, העתיקו את כל שלושת הקבצים אל מחוץ לשרת. גיבוי שנמצא רק על המכונה שאותה הוא אמור להגן אינו נחשב לגיבוי.

כדי לשחזר על שרת חדש, התקינו את אותו ה-tag, החזירו את ה-docker/.env.ce השמור כדי שסיסמת הצפנת פרטי הגישה וה-salt יתאימו, הפעילו את ה-stack פעם אחת כדי שה-volumes ייווצרו, עצרו את ה-backend, ולאחר מכן טענו את ה-dump:

gunzip -c livecontext-db-2026-08-10.sql.gz \
  | docker compose --env-file docker/.env.ce exec -T postgres psql -U postgres -d livecontext

שדרוגים, וחזרה למצב תקין במקרה של כשל

בצעו גיבוי (dump) תחילה, בכל פעם. ה-backend מחיל את ה-schema migrations שלו בעת העלייה, והעברות אלו נעות רק קדימה. לכן, חזרה ל-tag ישן לאחר שדרוג כושל תגרום להרצת קוד ישן מול schema חדש. ביצוע rollback משמעו שחזור ה-dump, וזו הסיבה שה-dump מגיע ראשון.

cd ~/livecontext-ce
git fetch --tags
git tag --list 'v*' | tail -5
TAG=v0.2.11
git checkout "$TAG"
docker compose --env-file docker/.env.ce pull
docker compose --env-file docker/.env.ce up -d
docker compose --env-file docker/.env.ce logs -f livecontext

הגדירו את TAG ל-tag שבחרתם מתוך הרשימה שהפקודה השלישית הציגה. עקבו אחר הלוג של ה-backend עד שנקודת ה-health endpoint תשיב שוב. ה-docker-compose.override.yml שלכם אינו במעקב (untracked), לכן git checkout ישאיר אותו במקומו. עם זאת, קראו את ה-diff ב-docker-compose.yml בין ה-tags, כיוון ששירות חדש או שירות ששמו שונה עלולים להפוך את ה-override שלכם ללא רלוונטי מבלי להציג הודעת שגיאה.

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

מכולה מבצעת אתחול חוזר ו־docker compose ps מציג exited (137). זהו מנגנון ה-OOM killer של הליבה; הפקודה docker inspect livecontext-app תאשר זאת עם "OOMKilled": true בבלוק המצב. ה-backend הגיע למגבלת ה-1536M שלו, או שהזיכרון במארח (host) אזל. בדקו את free -m לפני העלאת מגבלות כלשהן, שכן העלאת מגבלה למכולה על מארח ללא משאבים פנויים רק תעביר את הכשל למכולה אחרת.

פעולת ה-pull נכשלת עם no matching manifest for linux/arm64/v8 in the manifest list entries. התמונות (images) פורסמו עבור linux/amd64 בלבד. שרת VPS מבוסס Arm אינו יכול להריץ את ה-stack הזה מהתמונות שפורסמו, ואמולציה באמצעות QEMU איטית מדי עבור JVM יחד עם Chromium. עברו לתוכנית אירוח מבוססת x86.

Bind for 0.0.0.0:3000 failed: port is already allocated. תהליך אחר על המארח כבר תופס את הפורט הזה. שנו את FRONTEND_PORT בתוך docker/.env.ce, או החילו את ה-override שלעיל ואל תפרסמו דבר.

ממשק המשתמש פעיל אך בקשת ההתחברות נכשלת לאחר הוספת ה-proxy. הדפדפן פונה ל-backend בכתובת מקור (origin) שה-proxy שלכם אינו משרת. פתחו את לשונית ה-network בדפדפן ובדקו את ה-host של הבקשה שנכשלה. הגדירו את GATEWAY_PUBLIC_URL לכתובת ה-URL הציבורית של ה-backend והקימו מחדש את מכולת ה-frontend, כיוון שערך זה נקרא בעת העלייה.

הכל תקין אך קבצים שהועלו בתהליך עבודה (workflow) נעלמים. בדקו ש-minio-init מציג exited (0) ולא קוד שגיאה שאינו אפס. אם ה-bucket ב-workflow-files לא נוצר מעולם, ל-backend אין מקום לשמור בו אובייקטים.

בחירה בין LiveContext לבין n8n

בחרו ב-LiveContext כאשר המוקד הוא הסוכן (agent): אתם מעוניינים שהמודל יבנה ויריץ את האוטומציה, ואתם מקבלים את העלות של שרת עם 8 GB זיכרון ושירות Java. בחרו ב-n8n כאשר אתם זקוקים לתהליכי עבודה דטרמיניסטיים, ספריית צמתים (nodes) עשירה וטביעת רגל קטנה המאפשרת שיתוף של ה-VPS עם שירותים אחרים. מספרי הגרסאות כאן עדיין צעירים, v0.2.11 נכון לאוגוסט 2026, לכן קבעו גרסה (pin) באמצעות ה-tag וקראו את הערות השחרור (release notes) לפני כל שדרוג. לסקירה רחבה יותר, הכוללת כלים הנמצאים בטווח שבין שתי האפשרויות הללו, עיינו ב-סקירת החלופות ל-n8n באירוח עצמי במקום להסתמך על השוואה של שני כלים אלו בלבד.

FAQ

כמה זיכרון RAM דרוש להרצה עצמית של LiveContext?

תכננו עבור 8 GB. ה-README הרשמי מציין 4 GB כמינימום ו-8 GB כהמלצה, וקובץ ה-compose המצורף תואם לכך: ה-backend לבדו מוגבל ל-1536 MB, וחמשת שירותי הבסיס יחד מגיעים לקצת פחות מ-3 GB לפני הוספת ה-frontend ללא הגבלת זיכרון. הפעלת פרופיל ה-browser agent מוסיפה עוד 2048 MB עבור Chromium וקונטיינר SearXNG, כך שבשלב זה 8 GB הופכים להכרחיים.

האם ניתן להריץ את LiveContext על שרת VPS מבוסס Arm?

לא. כל אימג' שפורסם בנוי עבור linux/amd64, לכן docker compose up על תוכנית Arm ייכשל בשלב ה-pull עם no matching manifest for linux/arm64/v8 in the manifest list entries. הרצה תחת אמולציית QEMU אפשרית תיאורטית, אך אינה שמישה בפועל עבור עומסי עבודה של JVM. בחרו בתוכנית x86.

היכן עליי להזין את מפתח ה-API של המודל?

בתוך docker/.env.ce, תחת ANTHROPIC_API_KEY, OPENAI_API_KEY או GOOGLE_API_KEY, לפני ההפעלה הראשונה. ה-backend וה-bridge קוראים אותו בעת העלייה, והוא חל על כל ה-instance ולא על משתמש בודד. שמרו על הקובץ בהרשאות 600, השתמשו במפתח שנוצר במיוחד עבור שרת זה כדי שתוכלו לבטל אותו בנפרד, והגדירו תקרת הוצאות במסוף של ספק השירות, שכן תקרה זו היא המגבלה היחידה שקיימת מחוץ למכונה.

כיצד עליי לגבות את LiveContext?

יש לגבות שלושה דברים: pg_dump של מסד הנתונים livecontext, עותק של ה-volume של MinIO, ואת הקובץ docker/.env.ce. עצרו את השירותים livecontext ו-frontend בזמן ביצוע הגיבוי לשני הראשונים, כדי להבטיח עקביות בין מסד הנתונים לאחסון האובייקטים. קובץ ה-env קריטי מכיוון שהפרטים המאוחסנים ב-workflows שלכם מוצפנים באמצעות CREDENTIAL_ENCRYPTION_PASSWORD ו-CREDENTIAL_ENCRYPTION_SALT; שחזור ללא ערכים אלו ישאיר שורות עם פרטי הזדהות שאף רכיב במכונה החדשה לא יוכל לקרוא.

מדוע ה-backend נשאר במצב health: starting במשך דקות לאחר העלייה?

ה-healthcheck של ה-compose מגדיר start_period: 120s ומבצע פניות ל-/actuator/health, לכן Docker מדווח על השירות כ-starting בזמן שמתבצעות מיגרציות של ה-schema ורישום הכלים. המתנה של שתיים עד שלוש דקות בהפעלה ראשונה היא תקינה. אם השירות לעולם לא מגיע למצב healthy, קראו את docker compose logs -f livecontext. stack שנעצר בשלב המיגרציה מצביע בדרך כלל על volume של מסד נתונים מגרסה חדשה יותר.