Dormice वापरून स्वतःचे एजंट सँडबॉक्स कसे तयार करावे

Dormice म्हणजे काय आणि काय नाही

Dormice हे एक self-hosted एजंट सँडबॉक्स आहे: तुमच्या मालकीच्या Linux VPS वर चालणारा एक daemon, ज्याला तुमचे एजंट कोड HTTP द्वारे कॉल करून एका isolated कंटेनरमध्ये असुरक्षित (untrusted) कोड रन करतात. तुमचा प्रोग्राम नावावरून सँडबॉक्सची मागणी करतो, तो ज्या स्थितीत असेल त्याच स्थितीत परत मिळवतो, त्यात एक कमांड रन करतो आणि आउटपुट वाचतो. सँडबॉक्स हे एक प्रोग्रामॅटिक रिसोर्स आहे, ज्यामध्ये तुम्ही SSH द्वारे लॉग-इन करता अशी ही मशीन नाही.

एजंटला संपूर्ण संगणक देण्यापेक्षा हे वेगळे आहे. कोडिंग एजंटसाठी throwaway VM हा एक असा बॉक्स असतो ज्यामध्ये तुम्ही SSH करता, एजंटला तो खराब करू देता आणि नंतर तो डिलीट करता. Dormice एका पातळी खाली काम करते: जेव्हा तुमच्या प्रोग्रामकडे आधीच कोड असतो आणि तो रन करण्यासाठी सुरक्षित जागेची गरज असते, तेव्हा तुम्ही या execution API ला कॉल करता. जेव्हा संपूर्ण मशीन हे कामाचे एकक (unit of work) असते, तेव्हा throwaway VM वापरा. जेव्हा एक exec कॉल हे कामाचे एकक असते आणि तुम्हाला दिवसाला शंभर वेळा ते करायचे असते, तेव्हा शंभर VM न वापरता Dormice वापरा.

हा प्रोजेक्ट स्वतःला E2B सुसंगत (compatible) म्हणवतो. E2B ही एक होस्ट केलेली सँडबॉक्स सेवा आहे, जिची क्लायंट लायब्ररी अनेक एजंट फ्रेमवर्क्स आधीच वापरतात. Dormice त्याच प्रोटोकॉलला स्वतःच्या URL prefixes अंतर्गत सर्व्ह करते, त्यामुळे अधिकृत e2b पॅकेज वापरून लिहिलेले ॲप्लिकेशन तुम्ही तुमच्या स्वतःच्या बॉक्सकडे वळवल्यावरही तसेच काम करत राहते. ॲप्लिकेशन कोडमध्ये कोणताही बदल करावा लागत नाही. फक्त दोन URL आणि एक API key prefix बदलावे लागतात.

"एजंट सँडबॉक्ससाठीचे SQLite" याचा प्रत्यक्ष अर्थ काय आहे

SQLite हा एक असा डेटाबेस आहे जो तुम्ही सर्व्हिसप्रमाणे चालवण्याऐवजी थेट ॲप्लिकेशनमध्ये एम्बेड करता, आणि Dormice ही तुलना थेट वापरते. एक डेमन (daemon), लेजरसाठी एक SQLite फाईल आणि एक TCP पोर्ट. यामध्ये Kubernetes नाही, वेगळा डेटाबेस नाही आणि शेड्युलरही नाही. हा डेमन त्याच्या लेजरच्या बाजूला एक लॉक तयार करतो आणि जर लेजर आणि सध्याचे मशीन एकमेकांशी संबंधित नसतील, तर तो सुरू होण्यास नकार देतो. त्यामुळे 'split brain'ची स्थिती गुपचूप उद्भवू शकत नाही. हे डिझाइन एका मशीनसाठी आहे. जर तुम्हाला अनेक होस्ट्सवर फ्लीट चालवायची असेल, तर README मध्ये स्पष्टपणे सांगितले आहे की तुम्ही दुसरा पर्याय निवडावा, आणि तुम्ही ते ऐकले पाहिजे.

या कल्पनेचा दुसरा भाग खर्चाशी संबंधित आहे. होस्ट केलेला सँडबॉक्स अस्तित्वात असलेल्या प्रत्येक सेकंदासाठी बिल आकारतो, म्हणून होस्ट केलेले सँडबॉक्स डिझाइननुसारच तात्पुरते असतात. Dormice तुम्ही आधीच पैसे भरलेल्या हार्डवेअरवर चालते, त्यामुळे त्याचे सँडबॉक्स कायमस्वरूपी असतात आणि ते जितका जास्त काळ निष्क्रिय राहतात, तितके स्वस्त होतात. सँडबॉक्स एका वेळी एका टप्प्याने थंड होतो: सक्रिय (active), त्यानंतर गोठवलेला (frozen), त्यानंतर थांबलेला (stopped) आणि शेवटी संग्रहित (archived). कोणताही 'acquire' कमांड त्याला तो ज्या टप्प्यावर पोहोचला असेल तिथून पुन्हा सक्रिय करते.

'फ्रीझिंग' (गोठवणे) हा भाग समजून घेणे महत्त्वाचे आहे, कारण यामुळेच प्रत्येक एजंटचा सँडबॉक्स कायमस्वरूपी ठेवणे परवडणारे ठरते. ही आकडेवारी प्रकल्पाने स्वतः प्रकाशित केली आहे, जी त्यांच्या हार्डवेअरवर मोजली गेली आहे, तुमच्या हार्डवेअरवर नाही.

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

1024 MiB मेमरी असलेला एक निष्क्रिय सँडबॉक्स गोठवल्यानंतर (frozen) 5 MiB रेसिडेंट मेमरीवर येतो आणि सुमारे 50 ms मध्ये पुन्हा सक्रिय होतो. प्रक्रिया (processes) आहे त्याच स्थितीत सस्पेंड आणि रिझ्युम होतात, त्यामुळे दीर्घकाळ चालणारा एजंट त्याचे शेल स्टेट आणि अर्धवट राहिलेले काम फ्रीझिंगनंतरही टिकवून ठेवतो. यावर आधारित क्षमतेचे नियोजन करण्यापूर्वी ते तुमच्या स्वतःच्या होस्टवर तपासून पहा.

इन्स्टॉलेशनपूर्वी होस्टसाठी आवश्यक गोष्टी

होस्टवर Ubuntu किंवा Debian (x86_64) असणे आवश्यक आहे आणि इन्स्टॉलरला root परवानग्यांची गरज असते. डॅमन (daemon) रनटाइम दरम्यान root अधिकार कायम ठेवतो, कारण तो loop mounts करतो आणि cgroups मध्ये लिहितो.

सँडबॉक्सेस Docker आणि gVisor (एक कंटेनर रनटाइम जो कंटेनर आणि होस्ट कर्नलच्या मध्ये एक userspace कर्नल ठेवतो) अंतर्गत चालतात, जे प्रत्येक सँडबॉक्ससाठी runsc रनटाइम पुरवते. डॅमन चालवण्यासाठी Node 22 किंवा त्यापुढील आवृत्ती आवश्यक आहे. इन्स्टॉलर स्वतःची प्रत सोबत आणतो, त्यामुळे तुमच्या सिस्टममधील Node ला कोणताही धक्का लागत नाही.

सिस्टममध्ये swap असणे अनिवार्य आहे आणि vm.swappiness चे मूल्य 100 असणे आवश्यक आहे. हा केवळ ट्युनिंगचा सल्ला नसून एक कार्यात्मक गरज (functional requirement) आहे. सँडबॉक्सची मेमरी रिकामी (freeze) करण्यासाठी ती swap मध्ये ढकलली जाते. gVisor सँडबॉक्सची मेमरी shared memory म्हणून ठेवते आणि डीफॉल्ट swappiness वर कर्नल shared memory स्वॅप करत नाही. प्रकल्पानुसार, डीफॉल्ट मूल्यावर 0 bytes मेमरी रिकामी झाली, तर 100 मूल्यावर 99.5 टक्के मेमरी रिकामी झाली. कर्नल सध्या कोणते मूल्य वापरत आहे ते तपासा, कारण काही क्लाउड इमेजेसमध्ये vm.swappiness = 0 अशा फाईलमध्ये असते जी तुम्ही सहसा तपासत नाही.

sysctl vm.swappiness
swapon --show

sysctl vm.swappiness ने vm.swappiness = 100 आउटपुट दिले पाहिजे आणि swapon --show मध्ये एक swapfile दिसली पाहिजे. जर swappiness चे मूल्य 0 असेल, तर प्रत्येक freeze प्रक्रिया निरर्थक ठरेल आणि तुम्हाला प्रत्येक idle सँडबॉक्ससाठी पूर्ण मेमरीचा खर्च करावा लागेल.

Ubuntu वर Dormice इन्स्टॉल करणे

दस्तऐवजीकरणानुसार इन्स्टॉलेशन करण्यासाठी bash मध्ये एक पाईप कमांड वापरली जाते:

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

ही स्क्रिप्ट रन करण्यापूर्वी ती डाऊनलोड करून वाचा. ही स्क्रिप्ट root म्हणून रन होते आणि तुमच्या होस्टमध्ये बदल करते: जर Docker नसेल तर ते इन्स्टॉल करते, gVisor आणि Caddy चेकसम पडताळणीसह डाऊनलोड करते, एक swapfile तयार करते, systemd युनिट्स लिहिते आणि फायरवॉल नियम जोडते.

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 डाऊनलोड्सना चीनमधून उपलब्ध असलेल्या मिरर्सवर वळवते. इन्स्टॉलर पुन्हा रन केल्यास कोड अपग्रेड होतो आणि त्रुटी सुधारल्या जातात, परंतु तुमचा API token कधीही बदलला जात नाही.

कोड /opt/dormice मध्ये, कॉन्फिगरेशन /etc/dormice/env मध्ये, सँडबॉक्स डेटा /var/lib/dormice मध्ये आणि dormice व dor कमांड्स /usr/local/bin मध्ये साठवले जातात. इन्स्टॉलर इन्स्टॉलेशन दरम्यान API token तयार करतो आणि तो 600 मोडसह /etc/dormice/env मध्ये लिहितो.

इन्स्टॉल करण्यासाठी कोणतेही टॅग केलेले रिलीज उपलब्ध नाही. 4 ऑगस्ट 2026 पर्यंत रिपॉझिटरीमध्ये कोणतेही git टॅग किंवा GitHub रिलीज नाहीत, त्यामुळे इन्स्टॉलर main क्लोन करतो आणि तुम्हाला त्या दिवशी उपलब्ध असलेला लेटेस्ट कोड मिळतो. त्यामुळे व्हर्जन पिन करण्यासाठी तुम्ही प्रत्यक्षात इन्स्टॉल केलेल्या कमिटचा हॅश लिहून ठेवणे आवश्यक आहे.

git -C /opt/dormice rev-parse HEAD

तो हॅश तुमच्या डिप्लॉयमेंट नोट्समध्ये जतन करा. जेव्हा अपग्रेडमुळे काही बिघडते, तेव्हा तो कमिटच तुम्हाला जुन्या स्थितीत परत नेऊ शकतो, कारण विचारण्यासाठी कोणतेही व्हर्जन नंबर उपलब्ध नाही.

इन्स्टॉलर शेवटी dor doctor रन करतो. ही एक रीड-ओन्ली होस्ट चेक कमांड आहे जी प्रत्यक्ष gVisor कंटेनर बूट करून रनटाइम काम करत असल्याची खात्री करते, केवळ पॅकेज लिस्टवर अवलंबून राहत नाही. जेव्हा डेमन नीट काम करत नसेल, तेव्हा ही कमांड पुन्हा रन करा.

sudo dor doctor
systemctl is-active dormice

systemctl is-active dormice ने active आउटपुट दिले पाहिजे. जर ते failed प्रिंट करत असेल, तर journalctl -u dormice -n 50 मध्ये त्याचे कारण असते. स्टार्टअप अयशस्वी होण्याचे कारण सहसा swap किंवा gVisor च्या पूर्वअटी असतात, डेमन स्वतः नाही.

इन्स्टॉलर Caddy देखील इन्स्टॉल करतो, त्यामुळे फायरवॉलचे काम पूर्ण झाले असे मानण्यापूर्वी कोणते पोर्ट्स लिसनिंग मोडमध्ये आहेत ते तपासा.

sudo ss -lntp

डेमन 127.0.0.1:3676 वर बाइंड होतो आणि डिझाइननुसार ते बदलण्यासाठी कोणतीही सेटिंग उपलब्ध नाही. तुमच्या लॅपटॉपवरून त्याला ॲक्सेस करणे ही एक जाणीवपूर्वक केलेली कृती असावी आणि त्यासाठी स्वस्त पर्याय म्हणजे SSH टनेल वापरणे.

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

टनेल सुरू झाल्यावर, तुमच्या लॅपटॉपवर http://127.0.0.1:3676/console हे वेब कन्सोल असेल. एकदा टोकन वापरून साइन इन केल्यावर ते httpOnly सेशन कुकी बनते, त्यामुळे टोकन अशा ठिकाणी साठवले जात नाही जिथे पेज ते वाचू शकेल. तिथे असलेल्या Connect पेजवर क्लायंट स्निपेट्स मिळतात, जे आधीच तुमच्या एंडपॉईंटवर पॉइंट केलेले असतात.

सँडबॉक्स तयार करणे आणि त्यात कोड कार्यान्वित करणे

एक ऑपरेशन सँडबॉक्स तयार करते: acquire. हे आयडॅम्पोटंट (idempotent) आहे, त्यामुळे एकाच की (key) द्वारे नेहमी तोच सँडबॉक्स मिळतो; आवश्यकतेनुसार तो तयार करणे, सुरू करणे किंवा रिस्टोर करणे ही कामे याद्वारे होतात. इतर सर्व व्हर्ब्स (verbs) अशा की साठी 404 एरर देतात जी त्यांनी कधीही पाहिलेली नाही. dor CLI मध्ये acquire व्हर्ब नाही, त्यामुळे तुमचा पहिला सँडबॉक्स कन्सोल किंवा क्लायंट लायब्ररीद्वारे मिळवावा लागतो.

कन्सोल मार्ग सर्वात जलद आहे. टनेलद्वारे /console उघडा आणि 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 प्रत्येक सँडबॉक्सची लाइफसायकल स्थिती दर्शवते, ज्याद्वारे तुम्ही सँडबॉक्स active वरून frozen स्थितीत कसा जातो हे पाहू शकता. dor sandbox exec Python 3.12 आवृत्ती प्रिंट करते, कारण स्टॉक इमेजमध्ये Ubuntu 24.04 सोबत Python 3.12, Node 24, git आणि ripgrep आधीच इन्स्टॉल केलेले असतात. ऑथेंटिकेशन एररचा अर्थ असा की तुम्ही कॉपी केलेल्या टोकन लाइनमध्ये व्हेरिएबलचे नाव समाविष्ट होते.

फाईल्स dor sandbox push my-agent ./script.py द्वारे हलवल्या जातात, ज्या /home/user/script.py वर पोहोचतात आणि dor sandbox pull my-agent notes.txt द्वारे त्या परत मिळवता येतात. नेटिव्ह फाईल व्हर्ब्सची मर्यादा प्रति फाईल 16 MiB आहे, तर E2B फाईल इंटरफेस स्ट्रीम करण्याची सुविधा देते आणि सँडबॉक्स डिस्क कोटा हीच एकमेव मर्यादा उरते.

डिस्ट्रॉय (destroy) करणे ही एकमेव क्रिया आहे ज्यामध्ये डेटा नष्ट होतो, आणि हा प्रकल्पाच्या वयाचा एक उत्तम नमुना आहे: मुख्य README आणि बंडल केलेला एजंट स्किल दोन्ही dor sandbox destroy <key> दस्तऐवजीकरण करतात, तर CLI पॅकेज README मध्ये dor sandbox release <key> दस्तऐवजीकरण केलेले आहे. तुमच्या स्वतःच्या बिल्डवर dor sandbox --help चालवा आणि त्यावर विश्वास ठेवा.

तुमचा विद्यमान E2B कोड तुमच्या स्वतःच्या सर्व्हरकडे वळवा

हेच याकडे लक्ष देण्याचे मुख्य कारण आहे. npm कडील अधिकृत e2b पॅकेज, कोणत्याही बदलाशिवाय, Dormice शी संवाद साधते. SSH टनेल उघडा असताना तुमच्या लॅपटॉपवरून हे चालवा, जेणेकरून सर्व्हरवर कोणतीही नवीन सेवा पोर्टवर लिसन (listen) होणार नाही.

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 की हा तुमचा Dormice टोकन आहे, ज्याच्या सुरुवातीला e2b_ हा प्रिफिक्स जोडलेला आहे; सुसंगतता लेयर (compatibility layer) याच स्वरूपाची अपेक्षा करते.

ही सुसंगतता केवळ एक स्टब (stub) नाही. अधिकृत पॅकेजद्वारे प्रत्यक्ष Docker आणि gVisor डेमनवर स्टँडर्ड आउटपुट (stdout) आणि स्टँडर्ड एरर (stderr) स्ट्रीमिंग, बॅकग्राउंड कमांड्स, इंटरअॅक्टिव्ह PTY, स्वाक्षरी केलेले (signed) अपलोड आणि डाउनलोड URL, डिरेक्टरी वॉचिंग आणि पोर्ट प्रॉक्सी या सर्व गोष्टी प्रोजेक्टच्या एंड-टू-एंड सूटद्वारे तपासल्या जातात. कोणतीही महत्त्वाची गोष्ट स्थलांतरित (migrate) करण्यापूर्वी खालील काही फरक लक्षात घेणे आवश्यक आहे:

• टेम्पलेट बिल्ड्स कार्यान्वित केलेले नाहीत. टेम्पलेट म्हणजे एक Docker इमेज जी तुम्ही स्वतः तयार करता आणि dor template add सह रजिस्टर करता, आणि Sandbox.create('name') त्याचे रिझोल्यूशन करते. नोंदणीकृत नसलेले नाव वापरल्यास ते खोटे आश्वासन देण्याऐवजी 404 एरर देते.
• E2B इंटरफेसद्वारे तयार केलेल्या सँडबॉक्सेसना वास्तविक डेडलाईन्स असतात, कारण E2B च्या नियमांनुसार त्यांची आवश्यकता असते. नेटिव्ह API द्वारे तयार केलेल्या सँडबॉक्सेसवर अशा कोणत्याही डेडलाईन्स लादल्या जात नाहीत.
• फ्रोजन (frozen) सँडबॉक्स त्याच्या प्रक्रिया जशाच्या तशा ठेवतो आणि त्या तिथूनच पुन्हा सुरू करतो, त्यामुळे येथे 'पॉज' आणि 'रिझ्युम' म्हणजे तुम्ही ज्याला सरावलेले आहात असा 'स्टॉप' आणि 'कोल्ड स्टार्ट' नाही.

सँडबॉक्स काय थांबवतो आणि काय नाही

gVisor कंटेनरच्या सिस्टम कॉल्सना userspace मध्ये अडवते आणि स्वतःच पूर्ण करते, त्यामुळे सँडबॉक्समधील कोड थेट तुमच्या होस्ट कर्नलशी संवाद साधत नाही. सँडबॉक्सच्या आत, सर्व काही unprivileged user म्हणून चालते, ज्याचा uid 1000 असतो. हे संयोजन सामान्य परिस्थिती हाताळते: एखादी तयार केलेली स्क्रिप्ट जी rm -rf / चालवते, डिस्क भरते किंवा जोपर्यंत एखादी गोष्ट क्रॅश होत नाही तोपर्यंत फोर्क (fork) करत राहते, ती फक्त स्वतःच्या सँडबॉक्सचे नुकसान करते आणि तिथेच थांबते.

खालील गोष्टी सँडबॉक्स थांबवत नाही. या प्रत्येकाची जबाबदारी तुमची आहे.

• सँडबॉक्समध्ये आउटबाउंड नेटवर्क कार्यरत असते. तयार केलेला कोड त्याला हवे ते डाउनलोड करू शकतो आणि त्याला सापडलेली माहिती कुठेही पोस्ट करू शकतो. इंस्टॉलरचे नेटवर्क हार्डनिंग दोन विशिष्ट गोष्टी कव्हर करते: ते 169.254.0.0/16 वरील क्लाउड मेटाडेटा सर्व्हिसकडे जाणारा कंटेनर ट्रॅफिक ड्रॉप करते, जिथे क्लाउड इन्स्टन्स क्रेडेंशियल्स उपलब्ध असतात, आणि ते Docker च्या daemon.json मध्ये "icc": false वापरून कंटेनर-टू-कंटेनर ट्रॅफिक बंद करते. याव्यतिरिक्त काहीही ब्लॉक केलेले नाही. sudo iptables -S DOCKER-USER वाचा आणि ज्या खाजगी रेंजमध्ये सँडबॉक्सला जाण्याचे काहीही कारण नाही, तिथे स्वतःचे DROP नियम जोडा.
• Docker स्वतःचे नियम तुमच्या फायरवॉलच्या आधी समाविष्ट करते, त्यामुळे ufw ते बंद असल्याचे दर्शवत असले तरीही, पब्लिश केलेला कंटेनर पोर्ट इंटरनेटवरून प्रतिसाद देऊ शकतो. कोणतीही गोष्ट या होस्टवर उघड करण्यापूर्वी Docker कसे ufw च्या पलीकडे पोर्ट पब्लिश करते आणि VPS साठी ufw फायरवॉलची मूलभूत माहिती वाचा.
• gVisor हे userspace कर्नल आहे, हायपरवाइजर नाही. हा एक जाणीवपूर्वक केलेला तडजोड आहे, कारण फ्रीझिंगसाठी सँडबॉक्स हे प्रोसेस असणे आवश्यक असते आणि KVM ची अट घातल्यास हे कुठेही इन्स्टॉल करणे कठीण होईल. जर तुमच्या थ्रेट मॉडेलला हार्डवेअर व्हर्च्युअलायझेशनची गरज असेल, तर Firecracker-class आयसोलेशन वापरा आणि त्यासोबत येणारा ऑपरेशनल खर्च स्वीकारा.
• क्लायंटच्या बाजूने API token हीच संपूर्ण सुरक्षा सीमा आहे. ज्याच्याकडे DORMICE_API_TOKEN आहे, तो मशीनवरील प्रत्येक सँडबॉक्स तयार करू शकतो, वाचू शकतो आणि नष्ट करू शकतो. एजंट प्रोसेसला स्वतःचा VPS वरील कमीत कमी अधिकारांचा वापरकर्ता (least privilege user) द्या आणि टोकनला तुम्ही SSH की (key) प्रमाणेच हाताळा. VPS वर सुरक्षितपणे Claude Code चालवणे मधील सवयी येथे थेट लागू होतात.

डेमन स्वतः तुमच्या होस्टवर root म्हणून चालतो. gVisor होस्टला सँडबॉक्समधील कोडपासून वाचवते, परंतु डेमनपासून किंवा ज्याच्याकडे त्याचे टोकन आहे त्याच्यापासून होस्टला काहीही वाचवत नाही. त्यामुळे Dormice चालवणारे मशीन हे फक्त त्याच कामासाठी असावे. जर तुमचा एजंट MCP (model context protocol) द्वारे टूल्सपर्यंत पोहोचत असेल, तर त्याच कारणासाठी ते MCP सर्व्हर्स वेगळ्या VPS वर ठेवा.

4 GB आणि 8 GB मध्ये किती सँडबॉक्सेस मावतात?

दोन गोष्टी मेमरी वापरतात: होस्टची स्वतःची बेसलाइन आणि सध्या सुरू असलेल्या प्रत्येक सँडबॉक्सचा वर्किंग सेट. Ubuntu, Docker आणि डेमनसाठी सुमारे 1 GB राखून ठेवा, त्यानंतर उरलेली मेमरी एका सँडबॉक्सच्या प्रत्यक्ष वापराच्या क्षमतेने भागा. काही फाइल्स वाचणारा पायथन स्क्रिप्ट चालवणारा सँडबॉक्स 200 ते 300 MiB च्या आसपास मेमरी वापरतो. कंपायलर किंवा पूर्ण टेस्ट सूट चालवणारा सँडबॉक्स एक गिबिबाइटच्या पुढे जाऊ शकतो.

[
  {
    "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
  }
]

जर प्रत्येक सँडबॉक्स 512 MiB वापरत असेल, तर 4 GB चा VPS एकाच वेळी 6 सँडबॉक्सेस चालू ठेवू शकतो, किंवा जर प्रत्येक सँडबॉक्स एक पूर्ण गिबिबाइट वापरत असेल तर 3 सँडबॉक्सेस चालू ठेवू शकतो. 8 GB चा VPS ही क्षमता 14 आणि 7 पर्यंत वाढवतो. हे एकाच वेळी चालणाऱ्या कामाचे कमाल मर्यादेचे आकडे आहेत आणि हे केवळ गणिती अंदाज आहेत, बेंचमार्क नाहीत, त्यामुळे तुमचा लोड चालू असताना free -m वर लक्ष ठेवा.

फ्रोजन (frozen) सँडबॉक्सेसची मर्यादा RAM ऐवजी स्वॅपवर (swap) अवलंबून असते, आणि हीच या डिझाइनची मुख्य संकल्पना आहे. एक गिबिबाइट मेमरी वापरणारा फ्रोजन सँडबॉक्स स्वॅपमध्ये साधारण तितकीच जागा व्यापतो आणि RAM मध्ये जवळजवळ काहीही वापरत नाही, त्यामुळे इन्स्टॉलरची डीफॉल्ट 16 GB स्वॅपफाइल सुमारे 16 सँडबॉक्सेस साठवू शकते. या मर्यादेच्या पुढे त्यांना 'स्टॉप्ड' (stopped) स्थितीत जावे लागते, जिथे ते फक्त डिस्क स्पेस वापरतात. दीर्घकाळात डिस्क हीच खरी मर्यादा ठरते: प्रत्येक सँडबॉक्स स्वतःची फाइलसिस्टम राखून ठेवतो आणि काही डझन एजंट्स, ज्यांच्याकडे प्रत्येकी एक node_modules डिरेक्टरी असते, ते मेमरी संपण्याआधीच लहान व्हॉल्यूम पूर्णपणे भरून टाकतील.

Freeze, stop, archive: जीवनचक्राचे पर्याय

डीफॉल्टनुसार, 10 मिनिटे निष्क्रिय राहिल्यास सँडबॉक्स फ्रीझ होतो, 3 दिवसांनंतर थांबतो (stop) आणि आर्काइव्हिंग कॉन्फिगर केलेले असल्यास 7 दिवसांनंतर आर्काइव्ह होतो. stopAfterSeconds ला null वर सेट केल्यास तुम्हाला एक रेसिडेंट एजंट मिळतो: तो निष्क्रिय असताना फ्रीझ होऊ शकतो, परंतु तो कधीही कोल्ड स्टार्ट होत नाही.

आर्काइव्हिंग ऐच्छिक आहे आणि डेमन त्याबाबत स्पष्ट माहिती देतो. चार DORMICE_S3_* व्हेरिएबल्स सेट केल्यास, थांबलेल्या सँडबॉक्सची डिस्क tar आणि zstd वापरून पॅक केली जाते, कोणत्याही S3-सुसंगत बकेटवर पाठवली जाते आणि स्थानिक पातळीवरून मोकळी केली जाते. ते बकेट तुमच्या दुसऱ्या मशीनवर तुम्ही स्वतः होस्ट केलेले MinIO बकेट असू शकते. जर हे व्हेरिएबल्स सेट केले नाहीत, तर सँडबॉक्स कायमस्वरूपी थांबलेल्या (stopped) स्थितीत राहतात आणि आर्काइव्ह करण्याची पॉलिसी नाकारली जाते, ती शांतपणे दुर्लक्षित केली जात नाही. रिस्टोअरची प्रक्रिया स्पष्टपणे दिसते: पुढच्या वेळी जेव्हा तुम्ही acquire करता, तेव्हा ते त्वरित restoring स्टेटस आणि प्रोग्रेस व्हॅल्यू दर्शवते, आणि डिस्क परत आल्यावर स्टेटस ready मध्ये बदलते.

तुम्ही यावर आताच अवलंबून राहावे का?

थेट उत्तर: अशा कोणत्याही गोष्टीसाठी नाही जी तुम्ही पुन्हा तयार करू शकत नाही. रिपॉझिटरीमधील पहिली कमिट 8 जुलै 2026 ची आहे. 4 ऑगस्ट 2026 पर्यंत, याला 446 स्टार्स, 37 फोर्क्स, Apache-2.0 परवाना आणि एकही टॅग केलेली रिलीज नाही. README मधील स्टेटस लाइन स्वतःच सांगते की त्यातील काहीही प्रोडक्शनसाठी तयार नाही.

या संयोजनामध्ये जोखमीचे एक विशिष्ट स्वरूप आहे. कोड तुमच्या नियंत्रणाबाहेर बदलत राहतो, कारण इंस्टॉलर main ट्रॅक करतो. इंटरफेस अजूनही स्थिर होत आहे, म्हणूनच एकाच रिपॉझिटरीमधील दोन वेगवेगळ्या फाइल्समध्ये 'delete' या क्रियेसाठी दोन वेगळी नावे आहेत. आणि चार आठवडे जुना प्रकल्प कोणत्याही क्षणी बंद पडू शकतो, कारण परवान्यातील कोणतीही अट कोणालाही तो सुरू ठेवण्यास बांधील करत नाही.

E2B सुसंगतता (compatibility) या जोखमीला सहन करण्यायोग्य बनवते. तुमचे ॲप्लिकेशन अशा प्रोटोकॉलशी संवाद साधते ज्याच्या मागे एक होस्ट केलेली अंमलबजावणी आहे, त्यामुळे जर Dormice थांबले, तर तुम्ही फक्त दोन URL बदलून काम सुरू ठेवू शकता. तुमच्या एजंटला नेटिव्ह API ऐवजी E2B इंटरफेसवर आधारित लिहा, जेणेकरून तुमच्याकडे बाहेर पडण्याचा मार्ग उपलब्ध राहील. नेटिव्ह @dormice/sdk पॅकेज अजून npm वर उपलब्ध नाही, त्यामुळे ते वापरण्यासाठी तुम्हाला रिपॉझिटरीमधून बिल्ड करावे लागेल, जे सुसंगत मार्गाने सुरुवात करण्याचे दुसरे कारण आहे.

हे तिथेच चालवा जिथे ते गमावण्याची तुमची तयारी असेल. होस्टला स्क्रिप्टद्वारे पुन्हा तयार करा, टोकनला प्रत्येक प्रॉम्प्ट आणि प्रत्येक कमिटपासून दूर ठेवा आणि जपून ठेवण्यासारखी कोणतीही गोष्ट तुमच्या स्वतःच्या बॅकअप वेळापत्रकानुसार सँडबॉक्समधून बाहेर काढा.

FAQ

Dormice उत्पादनासाठी (production) तयार आहे का?

नाही, आणि प्रकल्प स्वतःच हे स्पष्ट करतो. README मधील स्टेटस लाईननुसार, त्यातील काहीही अद्याप उत्पादनासाठी तयार नाही. 4 ऑगस्ट 2026 रोजी, रिपॉझिटरी सुमारे चार आठवडे जुनी आहे, त्यात कोणतेही git tags किंवा releases नाहीत, त्यामुळे पिन करण्यासाठी कोणताही व्हर्जन नंबर उपलब्ध नाही. इंस्टॉलर main ब्रँच क्लोन करतो, याचा अर्थ प्रत्येक रनमध्ये तुम्हाला सर्वात नवीन कमिट मिळते. प्रत्येक इंस्टॉलेशननंतर git -C /opt/dormice rev-parse HEAD नोंदवून ठेवा आणि कोणतीही मौल्यवान गोष्ट सँडबॉक्सच्या बाहेर ठेवा.

Dormice माझ्या एजंटला डिस्पोजेबल VM देण्यापेक्षा वेगळे कसे आहे?

डिस्पोजेबल VM म्हणजे SSH असलेले एक मशीन, जे तुम्ही सत्रासाठी तयार करता आणि नंतर डिलीट करता. Dormice हे एक एक्झिक्यूशन API आहे: तुमचा प्रोग्राम acquire आणि नंतर exec कॉल करतो, आणि मध्ये कोणतीही शेल सत्र न वापरता stdout आणि एक्झिट कोड मिळवतो. VM अशा मानवासाठी किंवा एजंटसाठी योग्य आहे ज्याला काही काळासाठी संपूर्ण संगणक हवा असतो. Dormice अशा ॲप्लिकेशनसाठी योग्य आहे जे दिवसातून अनेकदा जनरेट केलेला कोड चालवते आणि प्रत्येक रनसाठी मशीन सेटअप आणि टियरडाऊन करण्याची गरज नसते.

अधिकृत E2B SDK खरोखर कोडमध्ये बदल न करता काम करते का?

हो, कॉन्फिगरेशनमधील बदलांसह. apiUrl आणि sandboxUrl ला तुमच्या डॅमनवरील /e2b/api आणि /e2b/envd कडे पॉइंट करा आणि तुमचा Dormice टोकन e2b_ प्रिफिक्ससह API की म्हणून वापरा. कमांड एक्झिक्यूशन, PTY सत्रे, फाईल ट्रान्सफर, साईन केलेले URL आणि पोर्ट प्रॉक्सी हे सर्व प्रकल्पाच्या अधिकृत पॅकेजद्वारे चालणाऱ्या एंड-टू-एंड सूटमध्ये समाविष्ट आहेत. टेम्पलेट बिल्डिंगमध्ये एक महत्त्वाची त्रुटी आहे: e2b template build कार्यान्वित केलेले नाही, त्यामुळे टेम्पलेट हे एक Docker इमेज आहे जे तुम्ही स्वतः तयार करता आणि dor template add सह रजिस्टर करता.

4 GB च्या VPS वर किती सँडबॉक्स मावू शकतात?

जर प्रत्येक सँडबॉक्स 512 MiB वापरत असेल, तर एकाच वेळी 6 सँडबॉक्स चालू शकतात, किंवा जर प्रत्येक सँडबॉक्स एक पूर्ण gibibyte वापरत असेल, तर 3 सँडबॉक्स चालू शकतात. यासाठी ऑपरेटिंग सिस्टम, Docker आणि डॅमनसाठी सुमारे 1 GB जागा राखून ठेवली आहे. फ्रोजन सँडबॉक्सची मर्यादा स्वॅपवर अवलंबून असते, त्यामुळे इंस्टॉलरची डीफॉल्ट 16 GB स्वॅपफाईल सुमारे 16 सँडबॉक्स साठवू शकते, ज्यातील प्रत्येकाने एक gibibyte व्यापला आहे. प्रत्यक्ष लोड अंतर्गत free -m वापरून स्वतः मोजमाप करा, कारण टेस्ट सूट चालवणारा सँडबॉक्स लहान स्क्रिप्ट चालवणाऱ्या सँडबॉक्सपेक्षा कित्येक पटीने जास्त मेमरी वापरतो.

Dormice ला vm.swappiness 100 वर सेट करण्याची गरज का आहे?

सँडबॉक्स फ्रीझ करणे म्हणजे त्याची आयडल मेमरी स्वॅपमध्ये ढकलणे. gVisor सँडबॉक्सची मेमरी शेअर केलेली मेमरी म्हणून ठेवते आणि Linux कर्नल डीफॉल्ट swappiness वर शेअर केलेली मेमरी स्वॅप करत नाही. त्यामुळे डीफॉल्ट सेटिंगवर फ्रीझ केल्यास कोणतीही मेमरी रिकामी होत नाही आणि सँडबॉक्स पूर्ण मेमरी वापरत राहतो. प्रकल्पाने केलेल्या मोजमापात डीफॉल्ट सेटिंगवर 0 बाइट्स रिकामे झाले, तर 100 सेटिंगवर 99.5 टक्के मेमरी रिकामी झाली. कॉन्फिगरेशन फाईल्स वाचण्याऐवजी sysctl vm.swappiness वापरून प्रभावी व्हॅल्यू तपासा, कारण काही क्लाउड इमेजेसमध्ये ही व्हॅल्यू 0 असते.