איך להריץ sandboxd על שרת VPS: מדריך התקנה מלא

מהו sandboxd ומה משיגים מהרצה עצמית שלו

כדי לארח את sandboxd בעצמכם, דרוש שרת Linux עם Docker ושם מתחם. אתם שולחים הנחיה (prompt), סוכן תכנות בונה יישום אמיתי בתוך מכולה מבודדת, והיישום עולה בכתובת URL ייעודית לתצוגה מקדימה. כלים מסוג "Prompt-to-app" הם הקטגוריה הבולטת ביותר ב־2026, ו־sandboxd הוא הכלי שרץ על ה-VPS שלכם, תחת רישיון MIT, כאשר הקוד שנוצר נשמר על הדיסק שלכם.

התכנון מצומצם בכוונה. מישור בקרה (control plane) שנכתב ב־Go מנהל את Docker, ‏Traefik v3 מנתב כל שם מארח של תצוגה מקדימה, SQLite מחזיק את המצב, וכל יישום רץ בתוך מכולה אחת. אין כאן Kubernetes ואין שרת מסד נתונים נפרד, וזו הסיבה ששרת עם 2 vCPU מסוגל להריץ אותו.

ארבעה אובייקטים מרכיבים את כל המודל. app הוא הפרויקט הקבוע, המכיל את שמו, מטא-דאטה של git וסודות (secrets). sandbox הוא מכולת Docker שבה היישום רץ, כאשר כל יישום מצביע על sandbox אחד בכל פעם. workspace הוא קובצי היישום, השוכנים על המארח ושורדים את המכולה. task הוא הנחיה אחת המועברת לסוכן בתוך ה-sandbox. עצירת sandbox משחררת זיכרון ושומרת על הקבצים. השמדה שלו מוחקת את המכולה, והיישום יכול להפעיל אחת חדשה.

במה שונה sandboxd מ-Dify ומ-OpenHands?

שלושת הכלים הללו גורמים לבלבול כיוון שכולם מריצים LLM (מודל שפה גדול) על השרת שלך, אך התוצרים שלהם שונים. Dify בונה יישומי LLM: ממשקי צ'אט, צינורות שליפת מידע (retrieval pipelines) ותהליכי עבודה הקוראים למודל בכל פעם שמשתמש מפעיל אותם. המודל הוא חלק מהמוצר המוגמר. OpenHands עובד על מאגר קוד (repository) קיים: אתה מפנה אותו לקוד שלך, והוא קורא קבצים, מריץ פקודות ומציע שינויים. sandboxd מתחיל מאפס. הוא יוצר תשתית (scaffold) לפרויקט מתוך הגדרה מראש, בונה אותו בתוך מכולה (container) נקייה ומספק לך URL לצפייה. התוצר הסופי הוא יישום React או FastAPI רגיל שאינו זקוק למודל כדי לרוץ.

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

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

[
  {
    "tool": "sandboxd",
    "github_stars": "875",
    "forks": "50"
  },
  {
    "tool": "OpenHands",
    "github_stars": "83,091",
    "forks": "10,711"
  },
  {
    "tool": "Dify",
    "github_stars": "151,320",
    "forks": "23,886"
  }
]

ל-sandboxd יש 875 כוכבים, לעומת 83,091 עבור OpenHands ו-151,320 עבור Dify. המאגר נוצר ב-3 ביוני 2026, כך שהוא בן חודשיים נכון לאוגוסט 2026, בעוד ש-OpenHands קיים ממרץ 2024 ו-Dify מאפריל 2023. גרסה v0.1.0 שוחררה ב-6 ביוני 2026 וגרסה v0.3.6 ב-1 באוגוסט 2026. הפרויקט מגדיר את עצמו כגרסת בטא ומציין שגרסאות 0.x עלולות לשבור תאימות. התייחס למספרים אלו כאל סיכון תלויות (dependency risk) ולא כאל קביעה לגבי איכות: פרויקט בן חודשיים עבר רק חודשיים של מציאת באגים על ידי משתמשים אחרים.

מה השרת צריך, ומה משתבש כשיש מחסור במשאבים

הפרויקט מציין כי 2 ליבות vCPU ו-4 GB של RAM מספיקים להתחלה. זה נכון עבור ה-control plane ועבור sandbox קטן אחד, אך זה אינו מספיק עבור שני אנשים הבונים פרויקטים בו-זמנית. תכננו את הקצאת הזיכרון בחלקים. Traefik וה-control plane שנכתב ב-Go הם קטנים. כל sandbox פעיל מחזיק toolchain מלא של Node או Python, והשיא מגיע ב-npm install ואחריו build של גרסת production. תכננו 8 GB עבור שרת שיחזיק כמה יישומים פעילים, והתייחסו ל-swap כרשת ביטחון ולא כקיבולת, כיוון ש-build שנכנס ל-swap אורך דקות במקום שניות.

כאשר הזיכרון אוזל, מתקבלים שני סוגי כשלים שונים, והם אינם דומים כלל. בתוך ה-sandbox, המכולה מגיעה לתקרת ה---memory הקשיחה ש-sandboxd מגדיר, וה-kernel מסיים את התהליך הגדול ביותר, כך שה-build קורס ללא הודעה מועילה מה-agent. הפקודה docker ps -a מציגה exit code 137 עבור אותה מכולה, ו-docker inspect עליה מדווח על "OOMKilled": true. build של Node שקורס בדרך זו מדפיס לעיתים קרובות JavaScript heap out of memory לפני כן.

הכשל השני מתרחש ב-host. ה-sandboxd מריץ מנגנון pressure reaper שעוצר sandboxes כאשר הזיכרון של ה-host נמוך, לכן בשרת קטן sandbox עלול להיעלם בזמן שאתם צופים ב-preview שלו. הקבצים נשמרים והבקשה הבאה ל-URL של ה-preview תעיר אותו, אך משימה שהייתה פעילה בזמן שהמכולה נעצרה לא תתחדש.

דיסק הוא בעיה שקטה יותר. כל יישום שומר workspace משלו על ה-host, ופרויקט JavaScript נושא עץ node_modules בנפח של מאות מגה-בייטים. עשרה יישומים הם כמה ג'יגה-בייטים של dependencies עוד לפני שסופרים את ה-images. התחילו ב-40 GB ועקבו אחריו:

docker system df
sudo du -sh /var/lib/sandboxed/workspaces

ספריית הנתונים המוגדרת כברירת מחדל היא /var/lib/sandboxed, עם ה-e הנוסף. הקלדת /var/lib/sandboxd תוביל אתכם לספרייה ריקה ולחמש דקות של בלבול.

התקנת גרסה מקובעת של sandboxd

יש לוודא ש-Docker Engine עם תוסף ה-Compose, וכן git, מותקנים על השרת תחילה. המדריך התקנת Docker על שרת VPS מכסה את החלק הזה.

docker compose version
git --version

שני הרכיבים חייבים להציג גרסה בתגובה לפקודה. השגיאה docker: 'compose' is not a docker command מעידה על כך שמותקן אצלכם הקובץ הבינארי העצמאי הישן docker-compose, בעוד שהמתקין מצפה לתוסף v2.

המתקין הוא סקריפט shell המורד מהרשת; קראו אותו לפני ההרצה וקבעו גרסה ספציפית (pin).

curl -fsSL https://raw.githubusercontent.com/tastyeffectco/sandboxd/v0.3.6/install.sh -o install-sandboxd.sh
less install-sandboxd.sh
SANDBOXD_REF=v0.3.6 bash install-sandboxd.sh

המשתנה SANDBOXD_REF מייצג את ה-git ref שהמתקין מושך לתוך $HOME/.sandboxd/src, וערך ברירת המחדל שלו הוא main. השארת המשתנה ללא הגדרה משמעותה שההתקנה שלכם תהיה תמיד הגרסה העדכנית ביותר שמוזגה באותו בוקר, דבר בעל משמעות בפרויקט ששחרר שש גרסאות במהלך יולי 2026 בלבד. קבעו גרסה, ושדרגו באופן יזום לאחר קריאת ה-changelog.

הסקריפט משכפל את קוד המקור, בונה את ה-images, מפעיל את ה-stack באמצעות docker compose up -d, ומציג בסיום את כתובת ה-URL של הקונסולה ואת ה-API token. שמרו את ה-token במקום בטוח. זהו פרט האימות עבור ה-API שמנהל את Docker בהרשאות root.

curl http://127.0.0.1:9090/healthz

פקודה זו מדפיסה ok כאשר ה-control plane פעיל. אם לא מודפס דבר, ה-stack לא עלה: הריצו את docker compose ps מתוך ~/.sandboxd/src כדי לראות איזה שירות אינו פעיל, ולאחר מכן את docker compose logs sandboxd כדי להבין את סיבת הכשל.

גישה למסוף בשרת מרוחק

המסוף מוגש דרך Traefik בפורט HTTP_PORT, שברירת המחדל שלו היא 80, תחת שם המארח http://console.localhost. Traefik מבצע ניתוב לפי שם המארח, לכן הזנת כתובת ה-IP של השרת בדפדפן לא תתאים לאף כלל ותחזיר שגיאת 404. עד להגדרת שם מתחם אמיתי, בצעו העברת פורטים ושמרו על שם המארח:

ssh -L 8080:127.0.0.1:80 you@your-vps

לאחר מכן פתחו את http://console.localhost:8080 במחשב הנייד שלכם. ב-Linux וב-macOS, כל שם שמסתיים ב-.localhost מתורגם ל-127.0.0.1, כך שהבקשה עוברת במנהרה עם ה-header הנכון מסוג Host. הגדירו את סיסמת המסוף בביקור הראשון.

הקצאת מודל לסוכן

שני סוכני כתיבת קוד מגיעים בתוך ה-base image: OpenCode ו-Claude Code. המערכת SANDBOXD_DEFAULT_AGENT מחליטה איזה מהם יבצע משימה שלא צוין עבורה סוכן, וברירת המחדל היא opencode. כאשר לא מחובר מפתח כלל, המשימות רצות על המודלים החינמיים ללא מפתח של OpenCode Zen, כך שה-build הראשון שלכם אינו עולה דבר וניתן לבחון את כל התהליך לפני שמשלמים.

חברו מפתח משלכם כאשר תרצו להשתמש במודל חזק יותר. מפתחות נשלחים ל-control plane ולעולם לא ל-sandbox: הם נשמרים מוצפנים תחת ספריית הנתונים ומוזרקים לתעבורה על ידי credential proxy, כך שאף הסוכן ואף הקוד שהוא כותב אינם יכולים לקרוא אותם.

export API=http://127.0.0.1:9090
export SANDBOXD_TOKEN=sk_...                       # printed by the installer
export AUTH="Authorization: Bearer $SANDBOXD_TOKEN"

curl -s -XPOST $API/v1/agents/claude-code/api-key -H "$AUTH" \
  -H 'content-type: application/json' \
  -d '{"api_key":"sk-ant-..."}'

הקונסולה מבצעת פעולה זהה תחת Settings, AI Agents, כולל תהליך OAuth מודרך אם ברצונכם להשתמש במנוי Claude במקום ב-API key. המודל המוגדר כברירת מחדל לכל סוכן נמצא באותו לוח בקרה, וניתן לדרוס הגדרה זו עבור משימה בודדת.

בניית יישום קטן מקצה לקצה

צרו את היישום, הפעילו את ה-sandbox שלו, ולאחר מכן שלחו הנחיה (prompt). המזהים יוחזרו בפורמט JSON, וה-quickstart מחלץ אותם באמצעות sed, כך שאין צורך בהתקנת jq.

APP=$(curl -s -XPOST $API/v1/apps -H "$AUTH" \
  -H 'content-type: application/json' \
  -d '{"name":"todo","runtime_preset":"react-vite"}' \
  | sed -E 's/.*"id":"([^"]+)".*/\1/')

SB=$(curl -s -XPOST $API/v1/apps/$APP/sandbox -H "$AUTH" \
  -H 'content-type: application/json' -d '{"ports":[3000]}' \
  | sed -E 's/.*"id":"([^"]+)".*/\1/')

echo "app=$APP sandbox=$SB"

שני המשתנים חייבים להכיל מזהה. ערך ריק ב-$SB מעיד על כך שה-sandbox מעולם לא עלה; הסיבה הנפוצה לכך היא שתמונת הבסיס (base image) עדיין בבנייה או שהמארח חסר זיכרון פנוי. הופעת 401 במקום מזהה מעידה על כך ש-bearer token שגוי.

curl -s -XPOST $API/v1/sandboxes/$SB/tasks -H "$AUTH" \
  -H 'content-type: application/json' \
  -d '{"prompt":"Add a todo list with a text input, an add button, and a delete button on each row. Keep the list in localStorage.","agent":"opencode"}'

התגובה נושאת מזהה משימה (task id). הפקודה GET /v1/sandboxes/$SB/tasks/<task id> מחזירה את התוצאה, והנתיב /events על אותה משימה הוא זרם SSE (server sent events) חי של פעולות הסוכן. הקונסולה מציגה את אותו הזרם כצ'אט.

היישום זמין בכתובת http://s-<sandbox id>-3000.preview.localhost, כאשר 3000 הוא הפורט שביקשתם. אם ה-sandbox היה במצב שינה, הבקשה הראשונה מגיעה ל-catch-all של Traefik, שירות sandboxd מפעיל את המכולה, ממתין למענה מהפורט ומגיש דף "חימום" קצר שמתרענן אוטומטית ליישום שלכם. תצוגה מקדימה שנתקעת בדף זה מעידה על כך שהתהליך הפנימי אינו מאזין בפורט שהוגדר ב-sandbox.yaml של היישום.

העברת תצוגות מקדימות לדומיין אמיתי עם HTTPS

לכל סביבת sandbox יש שם מארח (hostname) משלה, כך שרשומת DNS אחת מסוג wildcard מכסה את כולן. הצביעו עם *.preview.yourdomain.com על כתובת ה-IP של השרת באמצעות רשומת A. לאחר מכן, הגדירו את משתני התצוגה המקדימה ב-.env בתוך ~/.sandboxd/src:

PREVIEW_DOMAIN=yourdomain.com
PREVIEW_ENTRYPOINT=websecure
PREVIEW_TLS=true
SANDBOXD_API_AUTH_DISABLED=false

Traefik זקוק לחצי השני של ההגדרה: הפעילו את נקודת הכניסה (entrypoint) של websecure בתוך traefik/traefik.yml והוסיפו פותר תעודות (certificate resolver). השתמשו באתגר DNS-01, כיוון שתעודת wildcard אחת תכסה אז כל שם מארח של תצוגה מקדימה. עם HTTP-01, כל סביבת sandbox חדשה תדרוש הנפקה משלה, ועבודה אינטנסיבית של בניית סביבות תוביל במהירות למגבלות הקצב (rate limits) של Let's Encrypt. המאמר תעודות Wildcard באמצעות אתגר DNS-01 מכסה את הצד של ה-DNS בנושא זה.

cd ~/.sandboxd/src
docker compose up -d

כתובות ה-URL של התצוגות המקדימות יהיו https://s-<id>-3000.preview.yourdomain.com. פתחו את פורטים 80 ו-443 ב-firewall והשאירו את 9090 סגור לגישה חיצונית: ראו חוקי firewall בסיסיים ב-ufw. זכרו שכל מי שיכול לנחש שם מארח של תצוגה מקדימה יוכל לטעון את היישום, לכן התייחסו לתצוגות המקדימות כאל שירות ציבורי.

היכן נשמר הקוד שנוצר, והאם ניתן לייצא אותו?

על המארח, תחת ספריית הנתונים. כל סביבת עבודה היא ספרייה רגילה ב-/var/lib/sandboxed/workspaces/<id>/, המחוברת (bind mount) לתוך המכולה, וקבצי היישום נמצאים ב-/home/sandbox/workspace/app בתוך ה-sandbox. מצב ה-control plane נשמר בקובץ SQLite יחיד ב-state/sandboxd.db, ואישורי ה-agent המוצפנים נמצאים ב-agent-auth/. דבר אינו מוסתר בתוך שכבות המכולה, לכן גיבוי הוא העתקה של הספרייה יחד עם קובץ מסד הנתונים. ביצוע גיבויים עם restic ב-VPS מטפל בשניהם.

sudo ls /var/lib/sandboxed/workspaces
sudo du -sh /var/lib/sandboxed/workspaces/*

ייצוא ל-Git מובנה במערכת ולא מתווסף כתוספת חיצונית. ה-API חושף סטטוס ו-diff לקריאה, ולאחר מכן ניתן לבצע commit ו-push:

curl -s $API/v1/apps/$APP/git/status -H "$AUTH"

curl -s -XPOST $API/v1/apps/$APP/git/commit -H "$AUTH" \
  -H 'content-type: application/json' \
  -d '{"message":"todo list, first pass"}'

curl -s -XPOST $API/v1/apps/$APP/git/push -H "$AUTH" \
  -H 'content-type: application/json' -d '{"branch":"main"}'

עבור remote פרטי נדרש personal access token, שמוגדר פעם אחת בקונסולה תחת Settings, Git credentials. הוא נשמר בצורה מוצפנת ונשאר מחוץ ל-sandbox, כך שה-agent אינו יכול לקרוא אותו או לבצע באמצעותו push ללא ידיעתכם. בצעו push מוקדם ולעיתים קרובות. עד שתעשו זאת, ספריית סביבת העבודה היא העותק היחיד של הקוד, ו-DELETE /v1/apps/<id> מוחק אותה ללא אפשרות שחזור.

מהי העלות של build במונחי tokens של מודל?

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

מבנה החשבונית נגזר מאופן הפעולה של לולאת ה-agent. כל סבב שולח מחדש את ההקשר (context) הדרוש, לכן העלות נגזרת ממספר הסבבים ולא ממספר היישומים. prompt בודד שמצליח במשימתו הוא זול. לעומת זאת, חמישה-עשר סבבים של "תקן עכשיו את המרווחים" בפרויקט המכיל חמישים קבצים אינם זולים, כיוון שתוכן הקבצים נשלח בכל פעם מחדש. תמחור ה-tokens של קלט ופלט שונה, ו-העלות של agent תכנות לסשן מציג את טווח המחירים הריאלי. הגדירו מגבלת הוצאה קשיחה אצל הספק לפני שאתם מעבירים את השליטה ללולאה שרצה ללא השגחה.

ניקוי סביבות עבודה (sandboxes) שאינן בשימוש

מנגנון ה-idle reaper עוצר כל sandbox שהיה במצב המתנה מעבר ל-SANDBOXD_IDLE_THRESHOLD_SECONDS, שערך ברירת המחדל שלו הוא 2100 שניות, או 35 דקות. פעולה זו משחררת את ה-RAM ושומרת את הקבצים, והבקשה הבאה לכתובת ה-URL של התצוגה המקדימה תעיר את ה-container. בשרתים קטנים מומלץ להפחית ערך זה, שכן 35 דקות של containers במצב המתנה הן 35 דקות של זיכרון שאינו זמין לשימוש.

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

curl -s -XPOST $API/v1/sandboxes/$SB/stop -H "$AUTH"     # frees RAM, keeps files
curl -s -XDELETE $API/v1/sandboxes/$SB -H "$AUTH"        # container and workspace gone
curl -s -XDELETE $API/v1/apps/$APP -H "$AUTH"            # app and everything under it

לאחר מספר שבועות של ניסויים, docker system df יציג שטח תמונה (image space) שניתן לפינוי גדול מהצפוי, כיוון שכל app שהוריד לעצמו שרשרת כלים (toolchain) הותיר אחריו שכבות. הפקודה docker image prune מנקה את השכבות היתומות (dangling). בדקו תחילה את GET /v1/apps, שכן תמונה שעדיין מופנית על ידי sandbox במצב שינה אינה נחשבת ל-garbage.

מה גבולות המכולה מספקים ומה לא

כל ארגז חול (sandbox) רץ כמשתמש ללא הרשאות מיוחדות, עם מערכת קבצים ראשית (root filesystem) לקריאה בלבד, כל ה-Linux capabilities מוסרות, no-new-privileges מוגדר, וקיימת תקרה לזיכרון ומגבלה על מספר התהליכים. הפרויקט מצהיר בגלוי על מגבלות המודל: מכולת Linux המשתפת ליבה (kernel) היא גבול בידוד חזק, אך גבול אבטחה חלש. באג בליבה משמעו פריצה למארח (host).

שתי עובדות דורשות התייחסות. תעבורה יוצאת (egress) מה-sandbox פתוחה בגרסת ה-self-hosted, כך שקוד שנוצר יכול להגיע לאינטרנט, לרשת המקומית שלכם ולנקודות קצה של מטא-דאטה בענן. תת-מערכת nftables לניהול תעבורה יוצאת קיימת בקוד המקור אך מנוטרלת בהידור בגרסת ה-Docker Compose הניידת, מה שאומר שהמגבלות חייבות להגיע מ-firewall המארח שלכם. בנוסף, ה-API של ה-control plane הוא למעשה root של המארח, כיוון שהוא מנהל את ה-Docker socket. הוא מאזין כברירת מחדל ל-127.0.0.1:9090, ה-SANDBOXD_API_AUTH_DISABLED חייב להישאר false, ואסור לחשוף אותו לאינטרנט בשום אופן.

אם אתם מתכננים לאפשר לאנשים אחרים לשלוח הנחיות (prompts) לשרת שלכם, המודל הזה חלש מדי כשלעצמו. הפרויקט מצביע על gVisor עם SANDBOXD_RUNTIME=runsc, אשר מציב ליבה במרחב המשתמש (userspace kernel) בין ה-sandbox למארח, מה שגורם להאטה של פי 1.7 עד 4 בעבודה אינטנסיבית של syscall. הפתרון החזק יותר הוא מכונה אחת לכל משתמש, טיעון הזהה לזה שב-הרצת סוכני קידוד ב-VM חד-פעמי.

האם כדאי לבנות על פרויקט בן חודשיים?

עבור שרת בנייה אישי, כן, עם אמצעי הזהירות המתבקשים: הצמידו גרסאות (pin) ל-SANDBOXD_REF, בצעו גיבוי ל-/var/lib/sandboxed, ודחפו כל יישום שחשוב לכם ל-git remote. עבור כל דבר שנוגע ללקוח, המתינו לגרסת 1.0 או תקצבו זמן לתיקון תקלות, כיוון שהמפתחים מצהירים בבירור שגרסאות 0.x עלולות להשתנות ללא התראה. המפתחים מציעים גם התקנה מנוהלת בעלות של 79 דולר לחודש נכון לאוגוסט 2026, נתון שכדאי להכיר כשמעריכים האם לפרויקט יש סיבה להמשיך להתקיים.

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

FAQ

מהן דרישות המערכת המינימליות עבור sandboxd?

הפרויקט מציין כי 2 ליבות vCPU ו־4 GB של RAM מספיקים להפעלה ראשונית, הכוללת את ה-control plane, את Traefik וסביבת sandbox אחת קטנה. השתמשו ב־8 GB RAM וב־40 GB שטח דיסק אם ברצונכם להריץ כמה יישומים במקביל, כיוון שכל sandbox פעיל מחזיק שרשרת כלים (toolchain) מלאה של Node או Python, וכל סביבת עבודה שומרת עץ תלויות משלה על הדיסק. כאשר המשאבים במארח אוזלים, מנגנון ה-pressure reaper של sandboxd עוצר סביבות sandbox כדי לפנות זיכרון, ותהליך בנייה שחורג ממכסת הזיכרון של המכולה שלו מופסק על ידי ה-kernel: הקוד docker ps -a מציג עבורו קוד יציאה 137.

במה שונה sandboxd מ־Dify או מ־OpenHands?

הם מייצרים תוצרים שונים. Dify בונה יישומים שקוראים למודל בזמן ריצה, כגון ממשקי צ'אט וצינורות שליפת נתונים (retrieval pipelines). OpenHands עורך מאגר (repository) קיים, מריץ פקודות ומציע שינויים לקוד קיים. sandboxd מקים פרויקט חדש מאפס על בסיס הנחיה (prompt), בונה אותו בתוך מכולה ייעודית, ומגיש אותו בכתובת URL לתצוגה מקדימה; התוצאה היא יישום אינטרנט רגיל שאינו זקוק למודל כדי לפעול.

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

במערכת הקבצים של המארח, לא בתוך image של מכולה. כל יישום מקבל תיקייה בנתיב /var/lib/sandboxed/workspaces/<id>/, אשר מחוברת (bind mount) לתוך ה-sandbox שלו, והקבצים מופיעים בנתיב /home/sandbox/workspace/app בתוך המכולה. מצב ה-control plane נשמר בקובץ SQLite יחיד תחת state/ באותה תיקיית נתונים. ניתן לבצע commit ו-push למאגר git מרוחק דרך לשונית ה-Git בקונסולה או דרך נקודות הקצה /v1/apps/<id>/git/commit ו-/git/push. אסימון (token) עבור מאגרים פרטיים נשמר מוצפן על ידי ה-control plane, ולא מועבר ישירות לתוך ה-sandbox.

האם בטוח לחשוף את sandboxd לאינטרנט?

חשפו את כתובות ה-URL לתצוגה מקדימה ואת הקונסולה, אך לעולם לא את ה-API של ה-control plane. ה-API הזה מנהל את Docker על המארח, ולכן הוא שקול להרשאות root; מסיבה זו הוא מאזין כברירת מחדל ל-127.0.0.1:9090. ל-sandboxes יש גם גישה פתוחה לרשת החוצה (egress) בגרסה המותקנת עצמאית, מה שאומר שקוד שהסוכן כותב יכול להגיע לרשת המקומית שלכם ולנקודות קצה של metadata בענן. לכן, הוסיפו חוקי firewall במארח אם ישנם שכנים ברשת שחשוב להגן עליהם. עבור הנחיות (prompts) מאנשים שאינכם סומכים עליהם, הריצו מארח נפרד לכל דייר (tenant) במקום להסתמך על גבולות המכולה בלבד.