איך להריץ 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 בנפח של מאות מגה-בייטים. עשרה יישומים הם כמה גיגה-בייטים של ספריות תלויות עוד לפני שסופרים את ה-images. התחילו עם 40 GB ועקבו אחריו:

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

בגרסה v0.3.6, הגרסה שאליה מדריך זה מקובע, ספריית הנתונים המוגדרת כברירת מחדל היא /var/lib/sandboxed, עם ה-e הנוסף. הקלדת /var/lib/sandboxd שם לא תניב דבר ותגזול חמש דקות של בלבול. זה השתנה בגרסה v0.3.9 (25 באוגוסט 2026). מתקינים חדשים מציבים התקנות טריות ב-/var/lib/sandboxd ושומרים על /var/lib/sandboxed רק עבור התקנה שכבר קיימת שם. בשרת שהוגדר לראשונה עם גרסה מאוחרת יותר, השתמשו בנתיב ללא ה-e בכל הפקודות להלן.

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

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

docker compose version
git --version

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

המתקין הוא סקריפט shell שנטען מהרשת, לכן יש לקרוא את תוכנו לפני ההרצה ולקבע את הגרסה.

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 שהמתקין מבצע לו checkout לתוך $HOME/.sandboxd/src, וערך ברירת המחדל שלו הוא main. השארת המשתנה ללא הגדרה פירושה שההתקנה תהיה של הקוד העדכני ביותר שמוזג באותו בוקר; זהו נתון קריטי בפרויקט ששחרר שש גרסאות במהלך יולי 2026 בלבד. קבעו את הגרסה, ושדרגו אותה באופן יזום לאחר קריאת ה-changelog. נכון ל-12 באוקטובר 2026, הגרסה החדשה ביותר היא v0.3.22, שש-עשרה גרסאות אחרי v0.3.6 המקובעת כאן.

הסקריפט משכפל את קוד המקור, בונה את ה-images, מפעיל את ה-stack באמצעות docker compose up -d, ומציג בסיום את כתובת ה-URL של ה-console ואת ה-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 סגור לגישה מהעולם: ראו כללי ufw firewall בסיסיים. זכרו שכל מי שיכול לנחש שם מארח של תצוגה מקדימה יכול לטעון את היישום, לכן התייחסו לתצוגות מקדימות כאל תוכן ציבורי.

אם אתם מעדיפים לוותר לחלוטין על דומיין, DNS ותעודות, המפתחים מציעים כעת את sandboxd Cloud. שירות זה מעניק לשרת שלכם כתובת HTTPS ציבורית תחת sandboxd.io בעלות של 9.99 דולר לשרת לחודש, או 4.99 דולר עם הנחת ההשקה, נכון לאוקטובר 2026. בדקו איזו גרסה (release) נדרשת לפני שתסתמכו עליו עם נעילה לגרסה v0.3.6.

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

על המארח (host), תחת ספריית הנתונים. כל סביבת עבודה היא ספרייה רגילה בנתיב /var/lib/sandboxed/workspaces/<id>/ בהתקנת v0.3.6, המחוברת (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":"todo-first-pass"}'

פעולת ה-push תמיד מתבצעת לענף (branch) חדש. אם משמיטים את branch, ברירת המחדל היא sandboxd/<slug>-<shortsha>. הפקודות main, master והענף שממנו ביצעת ייבוא נדחות, לכן יש לבצע את ה-merge בצד המרוחק.

עבור 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) רץ כמשתמש ללא הרשאות עם מערכת קבצים ראשית לקריאה בלבד, כל ה-Linux capabilities מוסרות, no-new-privileges מוגדר, וקיימת תקרה לזיכרון ומגבלה על מספר התהליכים. הפרויקט מצהיר בגלוי על מגבלות המודל: מכולת Linux המשתפת ליבה (kernel) מהווה גבול בידוד חזק אך גבול אבטחה חלש. באג בליבה משמעו פריצה למארח.

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

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

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

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

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

FAQ

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

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

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

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

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

במערכת הקבצים של המארח, לא בתוך image של מכולה. כל יישום מקבל תיקייה בנתיב /var/lib/sandboxed/workspaces/<id>/ בהתקנת v0.3.6 (או /var/lib/sandboxd/workspaces/<id>/ בהתקנה נקייה של v0.3.9 ומעלה), אשר ממופה (bind mount) לתוך ה־sandbox שלו, והקבצים מופיעים בנתיב /home/sandbox/workspace/app בתוך המכולה. מצב ה־control plane נשמר בקובץ SQLite יחיד תחת state/ באותה תיקיית נתונים. ניתן לבצע commit ו־push לענף חדש ב־git remote מתוך לשונית ה־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. לארגזי החול יש גם גישה פתוחה לרשת החוצה (egress) בגרסה המותקנת עצמאית (self-hosted), מה שאומר שקוד שהסוכן כותב יכול להגיע לרשת המקומית שלכם ולנקודות קצה של מטא-דאטה בענן. לכן, הוסיפו חוקי firewall במארח אם ישנם שרתים שכנים שחשוב להגן עליהם. עבור הנחיות מאנשים שאינכם סומכים עליהם, הריצו מארח נפרד לכל דייר (tenant) במקום להסתמך על גבולות המכולה בלבד.