SSD Nodes Learn 🎉 VPS החל מ־$5.50/חודש
מדריכים Matt Connorמאת Matt Connor · עודכן 2026-08-13

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

למדו כיצד להריץ את KiroCrew כקונטיינר Docker קבוע על שרת VPS. המדריך כולל הגדרת systemd לשרידות, ניהול גיבויים, ביצוע Rollback וגישה מאובטחת לפורט 5476.

מדוע לארח את KiroCrew בשרת VPS במקום במחשב נייד

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

KiroCrew הוא סביבת עבודה לסוכנים בקוד פתוח מבית צוות Kiro, תחת רישיון Apache 2.0, כאשר הגרסאות הציבוריות הראשונות שלו שוחררו בתחילת אוגוסט 2026. תהליך אחד, הנקרא gateway, מחזיק במצב המערכת ומגיש לוח בקרה (dashboard) מבוסס אינטרנט בפורט 5476. ניתן לגשת ל-gateway זה מלוח הבקרה, מ-kirocrew CLI, או מערוץ צ'אט כגון Slack. ה-gateway הוא הרכיב היחיד שאתם מארחים בעצמכם, לכן מדריך זה עוסק בשמירה על פעילותו, בהרחקתו מהאינטרנט הציבורי, וביכולת לשחזר אותו לאחר שדרוג כושל.

שני דברים שכדאי לדעת לפני שמתחילים. KiroCrew מפעיל את kiro-cli, אשר דורש התחברות חד-פעמית עם חשבון Kiro, והסקה (inference) של סוכנים מחויבת לפי תוכנית Kiro, כך שנכון לאוגוסט 2026 זו אינה התקנה לא מקוונת (offline). הפרויקט גם קיים שבועות ספורים בלבד. הניחו שתצטרכו לבצע שחזור (rollback) בנקודה כלשהי, והתקינו אותו בדרך שתאפשר זאת. אם לא הרצתם סוכן על שרת בעבר, הרצת סוכן תכנות על שרת VPS מכסה את כללי היסוד שעליהם מדריך זה מתבסס.

מה KiroCrew דורשת, והיכן נשמר המצב שלה

התקנה מקומית (native) דורשת Python 3.10 או חדש יותר (הפרויקט ממליץ על 3.12), Node.js 18 או חדש יותר אם בונים את ה-dashboard ממקור, ו-kiro-cli, שההפעלה הראשונה מתקינה ומבצעת בו כניסה עבורכם. התקנה באמצעות מכולה (container) אינה דורשת דבר מכל אלו על המארח. היא דורשת Docker. זו הסיבה העיקרית להעדיף אותה.

המצב נשמר ב-~/.kiro/crew, ומשתנה הסביבה KIROCREW_HOME מעביר אותו למקום אחר. מה נמצא בפנים:

  • config.json: הגדרות ה-gateway ופרטי הגישה לערוצי הצ'אט.
  • .env: סודות (secrets).
  • workspace/memory/: העדפות, הערות פרויקט והיסטוריית צ'אט.
  • memory.db ו-memory_index.db: האינדקסים הסמנטיים ואינדקס הטקסט המלא.
  • models/: מודל ה-embedding, שיורד בהפעלה הראשונה.
  • gateway.log ו-security_events.jsonl: לוג זמן הריצה ולוג אירועי האבטחה.

התיקייה הזו היא ההתקנה. העתיקו אותה ל-VPS חדש והעברתם את הסוכן שלכם; זו הסיבה שסעיף הגיבוי להלן חשוב יותר מסעיף ההתקנה.

תכננו לפי נפח דיסק ולא לפי RAM. ה-gateway הוא תהליך Python; מה שבאמת מעמיס על השרת הוא מה שהסוכן מריץ, כמו build או חבילת בדיקות. תיקיית המצב גדלה עם היסטוריית הצ'אט, ומודל ה-embedding מגיע בהפעלה הראשונה, לכן מדדו את הנפח על השרת שלכם באמצעות du -sh ~/.kiro/crew לאחר כמה שבועות, במקום להסתמך על נתונים שפורסמו בחודש הראשון של הפרויקט.

באיזו מתוך שלוש דרכי ההתקנה עליך לבחור

הפרויקט מפיץ שלוש אפשרויות. מתקין השורה האחת מושך wheel ומציב את kirocrew ב־PATH שלך:

curl -fsSL https://download.crew.kiro.dev/cli.sh | sh

הוא מקבל דגל ערוץ ודגל גרסה:

curl -fsSL https://download.crew.kiro.dev/cli.sh | sh -s -- --channel insider
curl -fsSL https://download.crew.kiro.dev/cli.sh | sh -s -- --version 0.1.3

דימוי המכולה מפורסם ב־ghcr.io/kirodotdev/kirocrew, עבור linux/amd64 ו־linux/arm64 תחת כל תגית. בנייה ממקור היא git clone פלוס make build, והיא מיועדת לאנשים המשנים את הקוד, לא לאנשים המריצים אותו.

השתמש במכולה. התקנה מקומית מציבה חבילות Python, Node ו־kiro-cli על אותו מארח שמריץ את שאר השירותים שלך, כך ששדרוג שמשתבש משאיר אותך לפתור זאת ידנית. המכולה שומרת את סביבת הריצה בדימוי אחד ואת המצב בנפח (volume) אחד, מה שהופך ביצוע rollback לשינוי תגית ואתחול מחדש.

הצמידו את ה-image ל-release tag, לא ל-stable

הדוגמה של הפרויקט עצמו משתמשת ב-tag מסוג stable:

docker run -d --name kirocrew \
  -p 127.0.0.1:5476:5476 \
  -v kirocrew-home:/home/kirocrew \
  ghcr.io/kirodotdev/kirocrew:stable

stable הוא tag דינמי. הוא מצביע על הגרסה היציבה העדכנית ביותר בכל רגע נתון, לכן ה-pull הבא עלול לשנות את הגרסה שרצה אצלכם ללא בחירה מודעת מצדכם, וה-tag אינו מתעד איזו גרסה הותקנה. תגי גרסה הם בלתי ניתנים לשינוי (immutable), לכן הצמידו אחד מהם. הגרסה העדכנית ביותר נכון ל-6 באוגוסט 2026 היא 0.1.3, שפורסמה ב-5 באוגוסט 2026. קיים גם tag מסוג nightly, שבפרויקט צעיר כזה משמעותו שהקוד השתנה הבוקר.

כתבו את /opt/kirocrew/compose.yaml:

services:
  kirocrew:
    image: ghcr.io/kirodotdev/kirocrew:0.1.3
    container_name: kirocrew
    restart: unless-stopped
    ports:
      - "127.0.0.1:5476:5476"
    volumes:
      - kirocrew-home:/home/kirocrew

volumes:
  kirocrew-home:

הפעילו אותו, ולאחר מכן בדקו את ה-health endpoint שבו ה-image משתמש גם עבור ה-HEALTHCHECK שלו:

cd /opt/kirocrew
docker compose up -d
docker compose ps
curl -s http://127.0.0.1:5476/api/health

docker compose ps אמור לדווח שה-container תקין (healthy) תוך דקה לערך, ו-/api/health משיב ללא token (כמו גם /api/live ו-/api/ready, מה שהופך אותם לשמישים כ-probes). אם המצב נשאר starting, קראו את docker logs kirocrew לפני שמשנים דבר מה. ההרצה הראשונה מורידה את מודל ה-embedding, לכן חיבור איטי עשוי להפוך את ההפעלה הראשונה לארוכה.

שמירה על פעילות רציפה באמצעות systemd

restart: unless-stopped מחזיר את המכולה לפעולה לאחר קריסה ולאחר אתחול, כל עוד Docker עצמו עולה בזמן ה-boot. קובץ unit הופך את התלות הזו למפורשת ומספק פקודה אחת שעוצרת את כל ה-stack לפני ביצוע גיבוי. הפעלת stack של Docker Compose בזמן ה-boot מכסה את התבנית הכללית. זהו המבנה של KiroCrew, בתוך /etc/systemd/system/kirocrew.service:

[Unit]
Description=KiroCrew gateway
Requires=docker.service
After=docker.service

[Service]
Type=oneshot
RemainAfterExit=yes
WorkingDirectory=/opt/kirocrew
ExecStart=/usr/bin/docker compose up -d
ExecStop=/usr/bin/docker compose down
TimeoutStartSec=0

[Install]
WantedBy=multi-user.target
sudo systemctl daemon-reload
sudo systemctl enable --now kirocrew
systemctl status kirocrew

systemctl status kirocrew אמור להציג active (exited), שזו התוצאה התקינה עבור יחידה זו. Type=oneshot עם RemainAfterExit=yes נמצא כאן מכיוון ש-docker compose up -d מסיים את פעולתו ברגע שהמכולה מופעלת: systemd עוקב אחר העובדה שה-stack פעיל, ולא אחר תהליך שרץ ב-foreground. אם תכתבו Type=simple במקום זאת, systemd יראה שהפקודה מסתיימת מיד, יסמן את השירות כמת, ולאחר מכן יוותר או יבצע לולאת אתחול בהתאם להגדרת ה-Restart= שלכם. עבור התקנה מקומית (native), הפרויקט מספק שירות מקביל משלו, kirocrew service install, אשר כותב ל-/etc/systemd/system/kirocrew.service ומריץ את ה-gateway תחת המשתמש שלכם. אל תריצו את שתי היחידות במקביל. הגרסה המורחבת של נושא זה נמצאת ב-שירותי systemd ו-timers ב-VPS.

הרצה ראשונה: התחברות וקבלת אסימון ללוח הבקרה

המכולה מפעילה את ה-gateway, אך סביבת ה-agent עדיין אינה מחוברת. בצעו התחברות בתוך המכולה:

docker exec -it kirocrew kiro-cli login

פעולה זו תציג קוד מכשיר וכתובת URL שעליכם לפתוח בדפדפן שלכם. לאחר מכן, צרו אסימון (token) ללוח הבקרה:

docker exec kirocrew kirocrew token --ttl 2h

כתובת ה-URL של לוח הבקרה היא http://localhost:5476/?token=<the token>. לאסימונים יש תוקף: ברירת המחדל של הפעלות היא שעה אחת, והמקסימום המתועד הוא עשרים שעות. לוח בקרה שנטען ריק או מחזיר אתכם מיד החוצה מעיד בדרך כלל על אסימון שפג תוקפו; במקרה כזה, צרו אסימון חדש. לעולם אל תדביקו אסימון בתוך כרטיס תמיכה (ticket) או בהודעת צ'אט, כיוון שכל מי שמחזיק בו מחזיק בגישה ל-agent שלכם.

גישה ללוח הבקרה באמצעות SSH, ללא חשיפת פורט 5476

עיינו שוב בכתובת ה-bind בדוגמה של הפרויקט: -p 127.0.0.1:5476:5476. בתוך המכולה, ה-gateway מאזין ל-0.0.0.0, כיוון שהוא חייב להיות נגיש דרך מיפוי הפורטים, אך המיפוי עצמו מוגדר להאזנה ל-loopback בלבד במארח. מחיקת הקידומת 127.0.0.1: תחשוף את ה-gateway לאינטרנט הציבורי עבור כל מי שיסרוק את הפורט הזה. חוק firewall לא יגן עליכם במקרה זה: Docker מפרסם פורטים על ידי כתיבת חוקי DNAT שמוערכים לפני הסינון של ufw, לכן ufw deny 5476 אינו משפיע על פורט שפורסם. המדריך Docker ports bypassing ufw מסביר את המנגנון הזה בפירוט.

במקום זאת, בצעו העברת פורט (forwarding) דרך SSH מהמחשב האישי שלכם:

ssh -N -L 5476:127.0.0.1:5476 you@your-server.example.com

השאירו את הפקודה רצה ופתחו את http://localhost:5476/?token=<the token> בדפדפן המקומי. כדי להפוך את ההעברה לאוטומטית בכל חיבור, הוסיפו אותה לקובץ ~/.ssh/config:

Host your-server.example.com
    LocalForward 5476 127.0.0.1:5476

אם פורט 5476 כבר נמצא בשימוש במחשב שלכם, שנו רק את המספר השמאלי: ssh -N -L 45476:127.0.0.1:5476 you@your-server.example.com, ולאחר מכן גלשו ל-http://localhost:45476/?token=....

התנהגות מתועדת שצפויה בעבודה דרך מנהרה (tunnel): ה-gateway מזהה בקשות מועברות כבקשות מרחוק, ולכן נקודות קצה (endpoints) של כתיבת הגדרות וחשיפת סודות בלוח הבקרה יחסמו אותן. שינוי הגדרות שלא נשמר דרך SSH הוא התנהגות מכוונת, לא באג. ערכו את התצורה ישירות במארח:

docker cp kirocrew:/home/kirocrew/.kiro/crew/config.json .
# edit config.json here
docker cp config.json kirocrew:/home/kirocrew/.kiro/crew/config.json
docker exec -u 0 kirocrew chown kirocrew:kirocrew /home/kirocrew/.kiro/crew/config.json
docker restart kirocrew

עבור גישה מהטלפון, הפרויקט ממליץ על tailscale serve של Tailscale, ששומר את לוח הבקרה בתוך ה-tailnet הפרטי שלכם במקום תחת שם מתחם ציבורי. העדיפו זאת על פני reverse proxy ציבורי. האסימון (token) עובר בתוך ה-URL, וכל URL נרשם בכל לוג גישה לאורך הנתיב שלו.

צמצום טווח ההשפעה של הסוכן למינימום האפשרי

הקונטיינר בודק תמיכה ב-sandbox בעת ההפעלה הראשונה, והתוצאה קובעת אם סוכנים יכולים להריץ פקודות. אם קיימת הפרדת namespaces, תהליכי המשנה של הסוכן ירוצו בסביבה מבודדת. אם ההפרדה אינה זמינה והמשתנה KIROCREW_ALLOW_UNSANDBOXED=1 אינו מוגדר, ההרצה תיחסם במקום להתבצע ללא הגבלות; לכן, שער (gateway) שנראה תקין אך כל המשימות בו תקועות מעיד בדרך כלל על מצב זה. ההחלטה נשמרת ב-docker logs kirocrew החל מההרצה הראשונה. הפרויקט מפרסם גם פרופיל seccomp (מצב מחשוב מאובטח) שניתן להחיל:

curl -fsSL https://raw.githubusercontent.com/kirodotdev/KiroCrew/main/docker/seccomp/kirocrew-seccomp.json \
  -o /opt/kirocrew/kirocrew-seccomp.json
    security_opt:
      - seccomp:./kirocrew-seccomp.json

אם בחרתם להגדיר את KIROCREW_ALLOW_UNSANDBOXED=1, היו מודעים למשמעות: הקונטיינר הוא כעת הגבול היחיד בין הסוכן לבין השרת שלכם. אזהרת הפרויקט ראויה לחזרה מלאה: אל תבצעו mount לנתיבים במערכת המארחת שלא הייתם מוסרים ישירות לסוכן. בפועל, הדבר פוסל את ה-Docker socket, כל bind mount של /, וכל תיקייה המכילה נתונים של שירות אחר.

השאר הוא המסגרת החלה על כל סוכן שמורשה להריץ פקודות. הגבילו את הרשאות הגישה שלו למאגר (repository) או ל-bucket הספציפי שהוא צריך, ולעולם אל תשתמשו ב-token אישי בעל הרשאות לכל החשבון. הריצו אותו כמשתמש ייעודי שתיקיית הבית שלו אינה מכילה דבר מלבד זאת, כפי שמוסבר ב-משתמשים בעלי הרשאות מינימליות ב-VPS. כאשר הסוכן כותב קוד ואז מריץ אותו, תנו לו מכונה שמותר לו לשבור: מכונה וירטואלית חד-פעמית עבור סוכני תכנות מהווה גבול חזק יותר מכל flag בקובץ ה-compose הזה, כיוון שאתם מוחקים אותה במקום לנקות אותה. אותו היגיון מנחה את הרצת OpenClaw בצורה מאובטחת ב-VPS ואת אירוח עצמי של סוכן Hermes ב-VPS. גם כלים נחשבים כחלק מטווח ההשפעה: מתן אפשרות לסוכן לבצע חיפוש באינטרנט הופך כל דף שהוא מושך לקלט לא מהימן, לכן הפניית הסוכן למופע SearXNG עצמי היא החלטה של הזרקת פקודות (prompt injection) לא פחות מאשר החלטה טכנית. עבודה מתוזמנת גם עולה כסף בזמן שאתם ישנים, שכן הסקת מסקנות (inference) מחויבת לפי תוכנית ה-Kiro שלכם; לכן, הגדירו את המגבלות המתוארות ב-שליטה בעלויות של סוכן AI ב-VPS לפני שתוסיפו משימה לילית.

גבו את נפח הנתונים (volume) לפני כל שדרוג

תחילה, מצאו את השם האמיתי של ה-volume. ‏Compose מוסיף תחילית לשמות של volumes לפי שם הפרויקט, שברירת המחדל שלו היא שם הספרייה, לכן ה-volume שמוגדר כ-kirocrew-home בתוך /opt/kirocrew/compose.yaml נוצר כ-kirocrew_kirocrew-home:

docker volume ls

עצרו את ה-gateway לפני העתקה של כל קובץ. memory.db ו-memory_index.db הם מסדי נתונים מסוג SQLite, והעתקה של מסד נתונים בזמן כתיבה עלולה לתפוס טרנזקציה חלקית, מה שיוביל לשחזור של קובץ פגום. הוראות השדרוג של הפרויקט מציינות זאת במפורש: העבירו נתונים רק כאשר ה-gateways עצורים.

sudo systemctl stop kirocrew
docker run --rm -v kirocrew_kirocrew-home:/data:ro -v "$PWD":/backup \
  alpine tar czf /backup/kirocrew-2026-08-06.tgz -C /data .
sudo systemctl start kirocrew

העתיקו את הארכיון מחוץ לשרת. שחזור מתבצע באמצעות אותה פקודה, כאשר המכולה עצורה ו-tar xzf מחליף את tar czf:

sudo systemctl stop kirocrew
docker run --rm -v kirocrew_kirocrew-home:/data -v "$PWD":/backup \
  alpine tar xzf /backup/kirocrew-2026-08-06.tgz -C /data
sudo systemctl start kirocrew

מעבר למארח (host) חדש הוא פעולה שונה משחזור באותו המיקום, והפרויקט מפרט זאת במדויק. היסטוריית הצ'אטים והערות הפרויקט תחת workspace/memory/ עוברות במלואן, וכך גם שני קובצי מסד הנתונים ו-config.json. קובצי PID, יומן אירועי האבטחה ו-.env קשורים למארח הישן, לכן השאירו אותם מאחור והזינו את ה-secrets מחדש במכונה החדשה.

כיצד מבצעים Rollback לשדרוג לא תקין

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

sudo systemctl stop kirocrew
# take the backup here, as above
sudo nano /opt/kirocrew/compose.yaml   # set the new image tag
sudo systemctl start kirocrew
docker compose -f /opt/kirocrew/compose.yaml ps
curl -s http://127.0.0.1:5476/api/health

docker compose up -d מושך את ה-image אם הוא אינו נמצא כבר על השרת, כך שעריכת ה-tag היא כל תהליך השדרוג. ביצוע Rollback הוא רצף פעולות זהה עם המספר הישן, והוא מחזיר אותך בדיוק ל-image שהיה לך קודם, כיוון ש-version tags הם בלתי ניתנים לשינוי (immutable).

ה-binary חוזר לגרסה הקודמת בצורה נקייה. ה-state הוא החלק שעלול שלא לחזור. Gateway חדש יותר יכול לשכתב את config.json או להעביר מסדי נתונים בזיכרון למבנה ש-gateway ישן יותר אינו קורא, ונכון לאוגוסט 2026 לא מתועד מסלול Downgrade. לכן, אם ה-image הישן עולה ומתנהג בצורה מוזרה, אל תנסה לבצע לו Debug. עצור אותו, שחזר את הגיבוי שלקחת לפני השדרוג, והתחל שוב. זו הסיבה המלאה לכך שהגיבוי מגיע לפני הכל, וזו הסיבה שההרגל לשדרג עכשיו ולגבות אחר כך נכשל בפרויקט צעיר כל כך.

מה לא הוכח כאן

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

שתי התנהגויות ראויות לבדיקה עצמית לפני שתסתמכו עליהן. ראשית, האם שדרוג לאחור (downgrade) קורא מצב שנכתב על ידי גרסה חדשה יותר: נסו זאת על עותק של ה-volume בזמן שזה לא קריטי, ולא במהלך תקלה. שנית, מה ה-gateway עושה כאשר ה-sign-in של Kiro פג תוקף בזמן ש-scheduled job אמור להתבצע. שני המקרים הם מסוג הקצוות המחוספסים שפרויקט צעיר משייף בשקט בין גרסאות, ושניהם זולים לבדיקה כעת.

FAQ

מדוע לוח הבקרה של KiroCrew לא נפתח בכתובת ה-IP הציבורית של השרת שלי?

מכיוון שהדוגמה שפורסמה קושרת את הפורט ל-loopback. הפקודה -p 127.0.0.1:5476:5476 ממפה את הפורט של המכולה לכתובת ה-loopback של המארח בלבד, וזאת בכוונה תחילה. ניתן לגשת אליו על ידי העברת הפורט דרך SSH באמצעות ssh -N -L 5476:127.0.0.1:5476 you@your-server, ולאחר מכן פתיחת http://localhost:5476/?token=<token> במחשב האישי שלך. הסרת הקידומת 127.0.0.1: כדי להפוך אותו לנגיש חושפת את ה-gateway לאינטרנט הציבורי, וכלל firewall לא יחסום אותו, כיוון שחוקי ה-DNAT של פורטים מפורסמים ב-Docker מוערכים לפני ש-ufw מסנן את התעבורה.

היכן KiroCrew שומר את הנתונים שלו, ומה עלי לגבות?

הכל נמצא תחת ~/.kiro/crew, שהוא /home/kirocrew/.kiro/crew בתוך תמונת המכולה, ו-KIROCREW_HOME משנה את מיקומו. יש לגבות את כל הספרייה, או את כל ה-Docker volume, כאשר ה-gateway עצור. הקבצים memory.db ו-memory_index.db הם מסדי נתונים מסוג SQLite, לכן העתקה שמתבצעת בזמן שה-gateway כותב אליהם עלולה להוביל לחוסר עקביות. בעת מעבר למארח חדש, workspace/memory/, שני קובצי מסד הנתונים ו-config.json עוברים איתך, בעוד שקבצי PID, יומן אירועי האבטחה ו-.env שייכים למארח הישן.

האם עלי להשתמש בתג stable או בתג גרסה?

השתמש בתג גרסה. התג stable משתנה בכל פעם שיוצאת גרסה חדשה, כך שהגרסה שאתה מריץ עלולה להשתנות מתחת לאפך ב-pull הבא, והתג עצמו לא מעיד על מה שרץ בפועל. תגי גרסה כמו 0.1.3 הם בלתי ניתנים לשינוי (immutable), וזה בדיוק מה שמאפשר ביצוע rollback: אתה מחזיר את המספר הישן ומקבל את אותה תמונה בדיוק. נכון ל-6 באוגוסט 2026, הגרסה החדשה ביותר היא 0.1.3.

מדוע ה-agent שלי מסרב להריץ פקודות כלשהן?

המכולה בודקת תמיכה ב-sandbox בהפעלה הראשונה שלה. אם היא לא מצליחה לבודד תתי-תהליכים של ה-agent והמשתנה KIROCREW_ALLOW_UNSANDBOXED=1 אינו מוגדר, היא מסרבת להריץ אותם במקום להריץ אותם ללא הגנה, כך שה-gateway נראה תקין בזמן שכל משימה נתקעת. הפקודה docker logs kirocrew מציגה את החלטת ה-sandbox מאותה הרצה ראשונה. הגדרת המשתנה הופכת את המכולה לגבול היחיד בין ה-agent למארח, לכן אם הגדרת אותו, אל תעגן (mount) שום דבר שלא היית מוסר ישירות ל-agent.

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

כן, נכון לאוגוסט 2026. KiroCrew היא תוכנה חופשית תחת רישיון Apache 2.0, אך היא מפעילה את kiro-cli, הדורש התחברות חד-פעמית, וביצועי ה-inference של ה-agent מחויבים במסגרת תוכנית Kiro. בתוך המכולה, הרץ את docker exec -it kirocrew kiro-cli login ואשר את קוד המכשיר בדפדפן שלך. עד להשלמת ההתחברות, ה-gateway יעלה ולוח הבקרה ייטען, אך ל-agent לא יהיה מודל לתקשר איתו.

#kirocrew#ai-agents#docker#systemd#self-hosting