אירוח עצמי של Dormice עבור ארגזי חול לסוכני AI

מהו Dormice ומה הוא אינו

Dormice הוא ארגז חול (sandbox) לסוכנים (agents) באירוח עצמי: daemon אחד על שרת VPS בבעלותכם, שאליו קוד הסוכן שלכם פונה באמצעות HTTP כדי להריץ קוד לא מהימן בתוך מכולה מבודדת. התוכנית שלכם מבקשת ארגז חול לפי שם, מקבלת בחזרה את אותו ארגז חול ללא קשר למצבו הקודם, מריצה בתוכו פקודה וקוראת את הפלט. ארגז החול הוא משאב תכנותי, לא מכונה שאליה מתחברים ב-SSH.

זהו מודל שונה ממתן מחשב שלם לסוכן. מכונה וירטואלית חד-פעמית עבור סוכן קידוד היא סביבה שאליה מתחברים ב-SSH, מאפשרים לסוכן להרוס אותה, ואז מוחקים אותה. Dormice נמצא רמה אחת מתחת: זהו API לביצוע פקודות שהתוכנית שלכם קוראת לו כאשר כבר יש לה קוד והיא זקוקה למקום בטוח להרצתו. השתמשו במכונה וירטואלית חד-פעמית כאשר יחידת העבודה היא מחשב שלם. השתמשו ב-Dormice כאשר יחידת העבודה היא קריאת exec בודדת, ואתם מעוניינים לבצע מאות כאלו ביום מבלי להקים מאות מכונות וירטואליות.

הפרויקט מגדיר את עצמו כתואם E2B. E2B הוא שירות ארגז חול מנוהל שספריות הלקוח שלו כבר מוטמעות בפריימוורקים רבים של סוכנים. Dormice מגיש את אותו פרוטוקול תחת קידומות URL משלו, כך שיישום שנכתב מול חבילת ה-e2b הרשמית ימשיך לעבוד כאשר תפנו אותו לשרת שלכם. קוד היישום אינו משתנה. רק שני כתובות URL וקידומת אחת של מפתח API משתנים.

מה המשמעות המעשית של "ה-SQLite של ארגזי החול לסוכנים"

SQLite הוא בסיס נתונים שמשלבים בתוך היישום במקום שירות שמנהלים בנפרד, ו-Dormice שואלת את ההשוואה הזו ישירות. דמון (daemon) אחד לכל מכונה, קובץ SQLite אחד עבור ה-ledger שלו, פורט TCP אחד, ו-gateway קטן שמותקן לצדו ומגיש את ממשק הניהול. ללא Kubernetes, ללא שרת בסיס נתונים חיצוני. הדמון תופס נעילה בלעדית לצד ה-ledger שלו, כך שדמון שני על אותה מכונה יסרב לעלות במקום לפצל את המצב בשקט. כל ארגז חול (sandbox) חי על המכונה שבה נוצר. ה-README מתאר כעת צי (fleet) כ-gateway אחד בתוספת המכונות ברשת הפרטית שלו, אך הוא עדיין מציין שאם דרושים ארגזי חול שעוברים בין מכונות, או צי שפרוס על פני אזורים גיאוגרפיים, כדאי לבחור בפתרון אחר, ומומלץ להקשיב להמלצה זו.

החצי השני של הרעיון עוסק בעלות. ארגז חול מאוחסן (hosted) מחויב לפי כל שנייה של קיום, ולכן ארגזי חול מאוחסנים מתוכננים להיות חד-פעמיים. Dormice רצה על חומרה שאתם כבר משלמים עליה, כך שארגזי החול שלה הם קבועים והופכים לזולים יותר ככל שהם נשארים במצב סטטי. ארגז חול מתקרר שלב אחר שלב: פעיל, לאחר מכן קפוא (frozen), לאחר מכן נעצר, ולבסוף מאורכב. כל פעולת acquire מחזירה אותו למעלה מכל שלב שאליו הגיע.

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

[
  {
    "label": "Active, holding 1 GiB",
    "resident_memory_mib": 1024,
    "wake_ms": 0
  },
  {
    "label": "Frozen",
    "resident_memory_mib": 5,
    "wake_ms": 50
  }
]

ארגז חול במצב המתנה שמחזיק 1024 MiB של זיכרון יורד ל-5 MiB בזיכרון ה-resident לאחר הקפאה, וחוזר לפעילות תוך כ-50 ms. תהליכים מושהים ומתחדשים במקומם, כך שסוכן בעל אורך חיים ארוך שומר על מצב ה-shell שלו ועל עבודתו החלקית לאורך ההקפאה. בצעו שכפול של התהליך על המארח שלכם לפני שתתכננו קיבולת על בסיס נתונים אלו.

דרישות קדם להתקנה על המארח

המארח חייב להריץ Ubuntu או Debian בארכיטקטורת x86_64, והמתקין דורש הרשאות root. ה-daemon שומר על הרשאות root בזמן הריצה כיוון שהוא מבצע loop mounts וכותב ל-cgroups.

סביבות ה-sandbox רצות תחת Docker עם gVisor (סביבת הרצה של מכולות המציבה ליבת userspace בין המכולה לבין ליבת המארח), אשר מספקת את ה-runsc שבו משתמש כל sandbox. ה-daemon דורש Node 22 או גרסה חדשה יותר. אם גרסת ה-Node המותקנת במערכת היא 22 ומעלה, המתקין ישתמש בה; רק כאשר היא חסרה או ישנה מדי, המתקין יוריד עותק ייעודי, יאמת את ה-checksum שלו ויפרוס אותו תחת /opt.

חובה שיהיה קיים swap, וערך ה-vm.swappiness חייב להיות 100. זו אינה המלצת כוונון, אלא דרישה תפקודית. פעולת ה-freezing מתבצעת על ידי דחיפת הזיכרון של sandbox לא פעיל אל ה-swap; מכיוון ש-gVisor מחזיק את זיכרון ה-sandbox כזיכרון משותף (shared memory), הליבה לא תבצע swap לזיכרון משותף בערך ה-swappiness המוגדר כברירת מחדל. הפרויקט מדד 0 בתים שפונו בערך ברירת המחדל, לעומת 99.5 אחוזים שפונו בערך 100. בדקו את הערך שהליבה משתמשת בו בפועל, שכן תמונות מערכת מסוימות בענן כוללות את vm.swappiness = 0 בתוך קובץ שלא תעלו בדעתכם לקרוא.

sysctl vm.swappiness
swapon --show

הפקודה sysctl vm.swappiness צריכה להדפיס vm.swappiness = 100, והפקודה swapon --show צריכה להציג קובץ swap. אם ה-swappiness מציג 0, כל פעולת freeze לא תבצע דבר ותשאיר אתכם משלמים על מלוא צריכת הזיכרון עבור כל sandbox לא פעיל.

התקנת Dormice על Ubuntu

התקנה המתועדת מתבצעת באמצעות צינור (pipe) אחד לתוך bash:

curl -fsSL https://raw.githubusercontent.com/BitMiracle-AI/Dormice/main/deploy/install.sh | bash

הורידו את הסקריפט וקראו אותו לפני ההרצה. סקריפט זה רץ כ-root ומבצע שינויים במערכת המארחת: הוא מתקין את Docker אם הוא חסר, מוריד את gVisor ואת Caddy עם אימות checksum, יוצר swapfile אם למארח אין swap, כותב יחידות systemd עבור ה-daemon, ה-gateway ומרשם תמונות (image registry), ומוסיף חוקי firewall.

curl -fsSL https://raw.githubusercontent.com/BitMiracle-AI/Dormice/main/deploy/install.sh -o dormice-install.sh
less dormice-install.sh
sudo bash dormice-install.sh --swap-gb 8

--swap-gb קובע את גודל ה-swapfile, כאשר ברירת המחדל היא 16, כמות משמעותית של שטח דיסק ב-VPS קטן. --mirror cn מעביר את ההורדות למקורות (mirrors) הנגישים מסין היבשתית. הרצה חוזרת של המתקין מעדכנת את הקוד ומתקנת סטיות בתצורה, והיא לעולם אינה מחליפה את ה-API token שלכם.

הקוד מותקן ב-/opt/dormice, התצורה ב-/etc/dormice/env (בתוספת /etc/dormice/gateway.env עבור ה-gateway), נתוני ה-sandbox ב-/var/lib/dormice, והפקודות dormice ו-dor נמצאות ב-/usr/local/bin. המתקין מייצר את ה-API token במהלך ההתקנה וכותב אותו ל-/etc/dormice/env עם הרשאות 600, ואותו ערך מוזן לקובץ של ה-gateway.

לא קיימת גרסה מתויגת (tagged release) להתקנה. נכון ל-12 באוקטובר 2026, המאגר אינו כולל תגיות git או GitHub releases, לכן המתקין משכפל (clones) את main ואתם מקבלים את הקוד העדכני ביותר לאותו בוקר. קיבוע גרסה (pinning) מחייב לכן תיעוד של ה-commit שהותקן בפועל.

git -C /opt/dormice rev-parse HEAD

שמרו את ה-hash הזה עם הערות הפריסה שלכם, שכן הוא מציין בדיוק איזה קוד רץ אצלכם. זו אינה דרך חזרה בפני עצמה: התהליכים החדשים מבצעים מיגרציות למסד הנתונים בעת העלייה, ותיעוד השדרוג מציין שמיגרציה אינה מתבטלת על ידי הרצה חוזרת של מתקין ישן. לפני הפעלה מחדש של כל רכיב, המתקין שומר snapshots של שני מסדי הנתונים ב-/var/lib/dormice/backups/ ושומר את השלושה האחרונים. snapshots אלו הם הדרך המתועדת לחזרה לאחור לאחר שדרוג כושל, לכן העתיקו את החדש ביותר מחוץ לשרת לפני שתבצעו שדרוג נוסף.

המתקין מסיים בהרצת dor doctor, בדיקת מארח לקריאה בלבד שמפעילה מכולות gVisor אמיתיות כדי לוודא שה-runtime עובד, במקום להסתמך על רשימת חבילות. הריצו זאת שוב בכל פעם שה-daemon אינו מתפקד כראוי.

sudo dor doctor
systemctl is-active dormice

systemctl is-active dormice אמור להדפיס active. אם הוא מדפיס failed, journalctl -u dormice -n 50 מכיל את הסיבה, וכשל בהפעלה נובע בדרך כלל מבעיית swap או מדרישות הקדם של gVisor, ולא מה-daemon עצמו.

המתקין מתקין גם את Caddy על השרת, לכן בדקו מה מאזין לפני שתחליטו שעבודת ה-firewall הושלמה.

sudo ss -lntp

ה-daemon תמיד מאזין ב-127.0.0.1, ובתכנון המערכת אין הגדרה לשינוי כתובת זו. רק הפורט משתנה: DORMICE_PORT כברירת מחדל הוא 3676. ה-gateway שלצידו פועל לפי אותו כלל ב-127.0.0.1:3677, עם DORMICE_GATEWAY_PORT עבור הפורט, וגם כאן אין הגדרת מארח במכוון. גישה לכל אחד מהם מהמחשב האישי שלכם היא פעולה יזומה, והדרך הזולה ביותר היא מנהרת SSH המעבירה את שני הפורטים.

ssh -L 3676:127.0.0.1:3676 -L 3677:127.0.0.1:3677 root@your-server

כאשר המנהרה פתוחה, http://127.0.0.1:3677/console במחשב שלכם הוא ה-web console, המוגש על ידי ה-gateway. בביקור הראשון עליכם להוכיח שאתם המפעילים על ידי הדבקת ה-API token פעם אחת, ולאחר מכן הגדירו שם משתמש וסיסמה לקונסולה. הכניסה מגדירה עוגיית session מסוג httpOnly, התקפה ל-7 ימים, שקוד JavaScript בדף אינו יכול לקרוא, והקונסולה לעולם אינה מציגה את ה-token בחזרה. דף ה-Connect שם מדפיס קטעי קוד (snippets) להעתקה עבור הלקוח, שכבר מצביעים על ה-endpoint שלכם.

יצירת ארגז חול (sandbox) והרצת קוד בתוכו

פעולה אחת יוצרת ארגז חול: acquire. הפעולה היא אידמפוטנטית, לכן אותו מפתח תמיד יחזיר את אותו ארגז חול, תוך יצירה, השכמה, הפעלה או שחזור שלו לפי הצורך. כל פועל אחר יחזיר שגיאת 404 עבור מפתח שטרם הוכר. ב־dor CLI אין פועל acquire, לכן ארגז החול הראשון שלכם ייווצר דרך ה-console או דרך ספריית לקוח.

הדרך המהירה ביותר היא דרך ה-console. פתחו את /console דרך ה-tunnel וצרו ארגז חול בשם my-agent. לאחר מכן ה-CLI יעבוד מולו.

sudo grep DORMICE_API_TOKEN /etc/dormice/env
export DORMICE_ENDPOINT=http://127.0.0.1:3676
export DORMICE_API_TOKEN=paste-the-value-here
dor sandbox ls
dor sandbox exec my-agent 'python3 --version'

dor sandbox ls מציג רשימה של כל ארגזי החול עם מצב מחזור החיים שלהם; כך ניתן לעקוב אחר המעבר של ארגז חול ממצב פעיל למצב קפוא. dor sandbox exec מדפיס גרסת Python 3.12, כיוון שה-image המובנה הוא Ubuntu 24.04 הכולל כבר Python 3.12, Node 24, git ו-ripgrep. שגיאת אימות מעידה על כך ששורת ה-token שהעתקתם כללה גם את שם המשתנה.

קבצים מועברים באמצעות dor sandbox push my-agent ./script.py, שמגיע אל /home/user/script.py, ו-dor sandbox pull my-agent notes.txt מחזיר קובץ חזרה. פקודות הקבצים המובנות מוגבלות ל-16 MiB לקובץ, בעוד ש-file surface של E2B מאפשר הזרמת נתונים ומגביל אתכם רק לפי מכסת הדיסק של ארגז החול.

השמדה (destroying) היא הפעולה היחידה שגורמת לאובדן נתונים. dor sandbox destroy my-agent מסיר את ארגז החול והוא אידמפוטנטי; ה-README הראשי, ה-agent skill המצורף וה-README של חבילת ה-CLI מתעדים כולם את הפעולה תחת שם זה. בכל מקרה, הריצו dor sandbox --help על ה-build שלכם, כיוון שה-installer עוקב אחרי main וה-CLI ממשיך לגדול.

הפניית קוד E2B קיים לשרת שלכם

זו הסיבה לכך שזה חשוב. חבילת ה-e2b הרשמית מ-npm, ללא שינויים, מתקשרת עם Dormice. הריצו זאת מהמחשב הנייד שלכם כשה-SSH tunnel פתוח, כך ששום דבר חדש לא יאזין בשרת.

npm init -y
npm i e2b tsx

import { Sandbox } from 'e2b';

const sbx = await Sandbox.create({
  apiKey: `e2b_${process.env.DORMICE_API_TOKEN}`,
  apiUrl: 'http://127.0.0.1:3676/e2b/api',
  sandboxUrl: 'http://127.0.0.1:3676/e2b/envd',
});

const result = await sbx.commands.run('python3 -c "print(6 * 7)"');
console.log(result.exitCode, result.stdout);

await sbx.kill();

DORMICE_API_TOKEN=paste-the-value-here npx tsx index.ts

הרצה תקינה תציג קוד יציאה 0 ו-42. ה-API key הוא ה-token שלכם מ-Dormice עם קידומת e2b_ לפניו, שכן זהו הפורמט ששכבת התאימות מצפה לו.

שכבת התאימות אינה רק ממשק ריק. הזרמת stdout ו-stderr, פקודות ברקע, PTY אינטראקטיבי, כתובות URL חתומות להעלאה והורדה, ניטור ספריות ו-port proxy – כולם מופעלים דרך החבילה הרשמית מול Docker ו-gVisor אמיתיים על ידי חבילת הבדיקות מקצה-לקצה של הפרויקט. ישנם כמה הבדלים שחשוב להכיר לפני העברת עומסי עבודה אמיתיים:

• בניית תבניות (Template builds) אינה ממומשת. תבנית היא image של Docker שאתם בונים בעצמכם ורושמים באמצעות dor template add, ו-Sandbox.create('name') פותר את השם שלה. שם שלא נרשם יחזיר שגיאת 404 במקום לבצע פעולה מדומה.
• סביבות מבודדות (sandboxes) שנוצרות דרך הממשק של E2B מקבלות דדליינים אמיתיים, כיוון שהסמנטיקה של E2B מחייבת זאת. דדליינים לעולם אינם נאכפים על סביבות שנוצרות דרך ה-API המקורי.
• סביבה מוקפאת (frozen sandbox) שומרת על התהליכים שלה ומחדשת אותם מאותה נקודה, לכן פעולות השהיה (pause) וחידוש (resume) כאן אינן דומות לעצירה והפעלה מחדש (cold start) שאולי אתם רגילים אליהן.

מה ה-sandbox עוצר, ומה לא

gVisor מיירט את קריאות המערכת של ה-container במרחב המשתמש (userspace) ומטפל בהן בעצמו, כך שהקוד שבתוך ה-sandbox אינו מתקשר ישירות עם ה-kernel של המארח. בתוך ה-sandbox, פקודות רצות כ-user (uid 1000), אך לחשבון זה יש הרשאות sudo ללא סיסמה, כך שכל קוד יכול לקבל הרשאות root בתוך ה-sandbox. אל תתייחסו ל-uid כאל אמצעי הגנה: הפרויקט מצהיר בבירור שגבול האבטחה הוא gVisor, לא ה-uid, ו-sandbox שמבצע הרשאת יתר עדיין אינו יכול להגיע ל-kernel של המארח. זה מטפל במקרה הרגיל: סקריפט שנוצר ומריץ rm -rf /, ממלא את הדיסק, או מבצע fork עד לקריסת המערכת, יפגע רק ב-sandbox של עצמו וייעצר שם.

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

• ל-sandbox יש גישה לרשת חיצונית. קוד שנוצר יכול להוריד כל מה שירצה ולשלוח החוצה כל מה שימצא. הקשחת הרשת של המתקין מכסה שני דברים ספציפיים: הוא חוסם תעבורת container לשירות ה-metadata של הענן בכתובות 169.254.0.0/16 וב-100.100.100.200 (הכתובת שבה משתמש Alibaba Cloud), שכן שם הענן מספק אישורי גישה לכל מי שמגיע לכתובות אלו, והוא מכבה תעבורה בין containers באמצעות "icc": false בתוך ה-daemon.json של Docker. שום דבר אחר אינו חסום. קראו את sudo iptables -S DOCKER-USER והוסיפו חוקי DROP משלכם עבור טווחי כתובות פרטיים שאין ל-sandbox שום סיבה להגיע אליהם.
• Docker מכניס חוקים משלו לפני ה-firewall שלכם, כך שפורט של container שפורסם יכול להגיב מהאינטרנט גם אם ufw מציג אותו כסגור. קראו את איך Docker מפרסם פורטים מעבר ל-ufw ואת יסודות ה-firewall מסוג ufw עבור VPS לפני שאתם חושפים משהו במארח זה.
• gVisor הוא kernel במרחב המשתמש, לא hypervisor. זו פשרה מכוונת, כיוון שביצוע הקפאה (freezing) מחייב שה-sandboxes יהיו תהליכים, ודרישה ל-KVM הייתה מונעת את התקנת המערכת במקומות רבים. אם מודל האיומים שלכם דורש וירטואליזציה ברמת החומרה, השתמשו בבידוד מסוג Firecracker וקבלו את העלות התפעולית הנלווית לכך.
• ה-API token הוא גבול האבטחה המלא בצד הלקוח. כל מי שמחזיק ב-DORMICE_API_TOKEN יכול ליצור, לקרוא ולהשמיד כל sandbox במכונה. תנו לתהליך ה-agent משתמש בעל הרשאות מינימליות ב-VPS והתייחסו ל-token כפי שאתם מתייחסים ל-SSH key. ההרגלים מ-הרצת Claude Code בצורה בטוחה על VPS תקפים גם כאן.

ה-daemon עצמו רץ כ-root על המארח שלכם. gVisor מגן על המארח מפני הקוד שבתוך ה-sandbox, אך שום דבר אינו מגן על המארח מפני ה-daemon או מפני מי שמחזיק ב-token שלו. לכן, המכונה שמריצה את Dormice צריכה להיות מכונה שמבצעת רק זאת. אם ה-agent שלכם ניגש גם לכלים דרך MCP (model context protocol), שמרו את שרתי ה-MCP ב-VPS נפרד מאותה סיבה.

כמה סביבות sandbox נכנסות ב-4 GB וב-8 GB?

שני גורמים צורכים זיכרון: בסיס המערכת של המארח, וסט העבודה של כל sandbox שפעיל כרגע. הקצו כ-1 GB עבור Ubuntu, Docker וה-daemon, ולאחר מכן חלקו את היתרה בכמות הזיכרון שסביבת sandbox אחת באמת צורכת. סביבת sandbox שמריצה סקריפט Python שקורא כמה קבצים צורכת בין 200 ל-300 MiB. סביבה שמריצה מהדר או חבילת בדיקות מלאה יכולה לעבור את ה-gibibyte.

[
  {
    "host": "4 GB VPS",
    "active_at_512_mib": 6,
    "active_at_1_gib": 3,
    "frozen_on_16gb_swap": 16
  },
  {
    "host": "8 GB VPS",
    "active_at_512_mib": 14,
    "active_at_1_gib": 7,
    "frozen_on_16gb_swap": 16
  }
]

שרת VPS עם 4 GB יכול להחזיק כ-6 סביבות sandbox פעילות בו-זמנית אם כל אחת צורכת 512 MiB, או 3 אם כל אחת צורכת gibibyte מלא. שרת VPS עם 8 GB מעלה את המספרים ל-14 ו-7. אלו הם גבולות עליונים לעבודה בו-זמנית, והם מבוססים על חישוב אריתמטי ולא על מדד ביצועים, לכן יש לנטר את free -m בזמן שהעומס שלכם רץ.

סביבות sandbox קפואות (frozen) מוגבלות על ידי ה-swap ולא על ידי ה-RAM, וזו כל מטרת התכנון. סביבת sandbox קפואה שהחזיקה gibibyte שומרת בערך כמות כזו ב-swap וכמעט שום דבר בזיכרון ה-resident, לכן קובץ ה-swap המוגדר כברירת מחדל על ידי המתקין בגודל 16 GB יכול להכיל כ-16 מהן. מעבר לכך, הן צריכות להגיע למצב עצירה (stopped), שבו הן תופסות מקום בדיסק בלבד. הדיסק הוא המגבלה האמיתית לטווח ארוך כאן: כל sandbox שומרת את מערכת הקבצים שלה, וכמה עשרות סוכנים שכל אחד מהם נושא ספריית node_modules ימלאו נפח אחסון קטן הרבה לפני שהזיכרון יהפוך לבעיה מעניינת.

הקפאה, עצירה, ארכוב: כפתורי מחזור החיים

ברירת המחדל היא הקפאה לאחר 10 דקות של חוסר פעילות, עצירה לאחר 3 ימים, וארכוב לאחר 7 ימים כאשר הארכוב מוגדר. הגדרת stopAfterSeconds ל-null הופכת את הסוכן לתושב (resident): הוא עשוי לקפוא בזמן חוסר פעילות, אך לעולם לא יבצע cold start.

ארכוב הוא אופציונלי, וה-daemon מדווח על כך בשקיפות. הגדירו אחסון תואם S3 בדף ההגדרות של ה-console (ארבעת משתני ה-DORMICE_S3_* עדיין קיימים, אך משמשים רק כערכי התחלה עבור ה-boot הראשון של ה-gateway). לאחר מכן, הדיסק של sandbox במצב עצור נארז באמצעות tar ו-zstd, נשלח ל-bucket, ומתפנה מקומית. ה-bucket הזה יכול להיות bucket של MinIO שאתם מארחים בעצמכם על מכונה אחרת שלכם. אם תותירו את האחסון ללא הגדרה, ה-sandboxes יישארו במצב עצור לצמיתות, ומדיניות המבקשת לבצע ארכוב תידחה במקום שתתעלם מהבקשה בשקט. שחזורים הם גלויים ולא שקטים: ה-acquire הבא ישיב מיד עם סטטוס של שחזור וערך התקדמות, ולאחר מכן יעבור למצב מוכן ברגע שהדיסק יחזור.

האם כדאי להסתמך על זה כבר עכשיו?

תשובה ישירה: לא עבור שום דבר שאינכם יכולים לבנות מחדש. המאגר נוצר ב-8 ביולי 2026. נכון ל-12 באוקטובר 2026 הוא מציג 1,509 כוכבים, 109 מזלגות (forks), רישיון Apache-2.0, וללא אף גרסה מתויגת (tagged release). שורת הסטטוס ב-README עצמו מציינת ששום דבר שם אינו מוכן לסביבת ייצור.

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

מה שהופך את הסיכון לנסבל הוא התאימות ל-E2B. היישום שלכם מדבר עם פרוטוקול שיש לו מימוש מאוחסן מאחוריו, כך שאם Dormice נתקע, אתם משנים שתי כתובות URL וממשיכים לעבוד. כתבו את ה-agent שלכם מול הממשק של E2B במקום מול ה-API המקורי, וכך תשמרו לעצמכם את נתיב היציאה הזה. חבילת ה-@dormice/sdk המקורית גם היא עדיין לא ב-npm, לכן שימוש בה משמעו בנייה מתוך המאגר, וזו סיבה שנייה להתחיל עם הנתיב התואם.

הריצו את זה במקום שבו אתם יכולים להרשות לעצמכם לאבד את המידע. בנו את המארח מחדש באמצעות סקריפט, שמרו את ה-token מחוץ לכל prompt וכל commit, ומשכו כל דבר ששווה לשמור מתוך ה-sandboxes לפי לוח זמני הגיבוי שלכם.

FAQ

האם Dormice מוכן לסביבת ייצור?

לא, והפרויקט מצהיר על כך בעצמו. שורת הסטטוס ב-README מציינת ששום דבר שם אינו מוכן עדיין לסביבת ייצור. נכון ל-12 באוקטובר 2026, המאגר קיים כשלושה חודשים, ללא git tags וללא releases, כך שאין מספר גרסה שאפשר להסתמך עליו. תוכנית ההתקנה משכפלת (clones) את הענף main, מה שאומר שכל הרצה מספקת לך את ה-commit העדכני ביותר. תעדו את git -C /opt/dormice rev-parse HEAD לאחר כל התקנה, שמרו עותק של צילומי מסד הנתונים שהמתקין כותב ל-/var/lib/dormice/backups/, ושמרו כל דבר בעל ערך מחוץ ל-sandboxes.

במה שונה Dormice ממתן VM זמני לסוכן שלי?

VM זמני הוא מכונה עם SSH שיוצרים עבור סשן ומוחקים לאחר מכן. Dormice הוא API לביצוע (execution API): התוכנית שלך קוראת ל-acquire, לאחר מכן ל-exec, ומקבלת בחזרה stdout וקוד יציאה, ללא סשן shell באמצע. ה-VM מתאים לאדם או לסוכן שרוצה מחשב שלם לזמן מה. Dormice מתאים ליישום שמריץ קוד שנוצר פעמים רבות ביום ואינו רוצה את התקורה של הקמה ופירוק מכונה עבור כל הרצה.

האם ה-SDK הרשמי של E2B באמת עובד ללא שינויי קוד?

כן, עם שינויי תצורה. הפנו את apiUrl ו-sandboxUrl אל /e2b/api ו-/e2b/envd ב-daemon שלכם, והעבירו את ה-token של Dormice עם תחילית e2b_ בתור ה-API key. הרצת פקודות, סשנים של PTY, העברת קבצים, כתובות URL חתומות ו-port proxy – כולם מכוסים על ידי חבילת הבדיקות מקצה לקצה של הפרויקט שרצה דרך החבילה הרשמית. בניית תבניות (templates) היא הפער הבולט: e2b template build אינו ממומש, לכן תבנית היא image של Docker שאתם בונים ורושמים באמצעות dor template add.

כמה sandboxes נכנסים ב-VPS של 4 GB?

בערך 6 פעילים בו-זמנית אם כל sandbox משתמש ב-512 MiB, או 3 אם כל אחד משתמש בגיביבייט מלא, לאחר שמירה של כ-1 GB עבור מערכת ההפעלה, Docker וה-daemon. sandboxes קפואים (frozen) מוגבלים על ידי ה-swap במקום זאת, לכן קובץ ה-swap המוגדר כברירת מחדל על ידי המתקין (16 GB) מאחסן סביב 16 sandboxes שכל אחד מהם תפס גיביבייט. מדדו את הצריכה שלכם עם free -m תחת עומס אמיתי, כיוון ש-sandbox שמריץ חבילת בדיקות צורך פי כמה מאשר אחד שמריץ סקריפט קטן.

מדוע Dormice דורש ש-vm.swappiness יוגדר ל-100?

הקפאת sandbox משמעותה דחיקת הזיכרון הלא פעיל שלו ל-swap. gVisor מחזיק זיכרון של sandbox כזיכרון משותף (shared memory), וליבת ה-Linux לא תבצע swap לזיכרון משותף בערך ה-swappiness המוגדר כברירת מחדל. לכן, בערך ברירת המחדל, הקפאה אינה מפנה דבר וה-sandbox ממשיך לצרוך זיכרון מלא. הפרויקט מדד 0 בתים שפונו בברירת המחדל ו-99.5 אחוזים שפונו ב-100. בדקו את הערך האפקטיבי עם sysctl vm.swappiness במקום לקרוא קובצי תצורה, כיוון שחלק מה-images בענן מגיעים עם ערך של 0.