Self-hosted Dormice का उपयोग करके agent sandbox कैसे बनाएं

Dormice क्या है, और क्या नहीं है

Dormice एक self-hosted agent sandbox है: यह आपके Linux VPS पर चलने वाला एक daemon है, जिसे आपका agent code HTTP के माध्यम से कॉल करता है ताकि एक isolated container के भीतर untrusted code चलाया जा सके। आपका प्रोग्राम नाम के आधार पर sandbox मांगता है, उसे वही sandbox वापस मिलता है (चाहे उसकी स्थिति कुछ भी हो), वह उसके भीतर एक command चलाता है, और output पढ़ता है। यह sandbox एक programmatic resource है, न कि कोई ऐसी मशीन जिसमें आप login करते हैं।

यह किसी agent को पूरा कंप्यूटर देने से बिल्कुल अलग है। एक coding agent के लिए throwaway VM एक ऐसा box है जिसमें आप SSH करते हैं, agent को उसे खराब करने देते हैं, और फिर उसे delete कर देते हैं। Dormice एक स्तर नीचे काम करता है: यह एक execution API है जिसे आपका प्रोग्राम तब कॉल करता है जब उसके पास पहले से code होता है और उसे चलाने के लिए एक सुरक्षित जगह की आवश्यकता होती है। जब काम की इकाई एक पूरी मशीन हो, तब throwaway VM का उपयोग करें। जब काम की इकाई एक single exec call हो, और आप बिना सौ VMs के दिन में सौ बार ऐसा करना चाहते हों, तब Dormice का उपयोग करें।

यह प्रोजेक्ट खुद को E2B compatible कहता है। E2B एक hosted sandbox service है जिसकी client library को कई agent frameworks पहले से ही import करते हैं। Dormice अपने स्वयं के URL prefixes के तहत उसी protocol को serve करता है, इसलिए आधिकारिक e2b package के लिए लिखा गया application तब भी चलता रहता है जब आप उसे अपने स्वयं के box की ओर point करते हैं। Application code में कोई बदलाव नहीं करना पड़ता। केवल दो URLs और एक API key prefix बदलते हैं।

"Agent sandboxes का SQLite" होने का व्यावहारिक अर्थ

SQLite एक ऐसा database है जिसे आप operate करने के बजाय embed करते हैं, और Dormice सीधे इसी तुलना का उपयोग करता है। एक daemon, ledger के लिए एक SQLite file, और एक TCP port। न Kubernetes, न अलग database, और न ही कोई scheduler। Daemon अपने ledger के बगल में एक lock लगाता है और यदि ledger और machine का मेल न हो, तो यह start होने से मना कर देता है, ताकि split brain की स्थिति चुपचाप न बन सके। इसे एक ही machine के लिए design किया गया है। यदि आपको कई hosts पर fleet की आवश्यकता है, तो README स्पष्ट रूप से आपको कुछ और चुनने की सलाह देता है, और आपको उस सलाह को मानना चाहिए।

इस विचार का दूसरा हिस्सा लागत के बारे में है। एक hosted sandbox अपने अस्तित्व के हर second का शुल्क लेता है, इसलिए hosted sandboxes को disposable (नष्ट करने योग्य) होने के लिए design किया जाता है। Dormice उस hardware पर चलता है जिसके लिए आप पहले से भुगतान कर रहे हैं, इसलिए इसके sandboxes स्थायी होते हैं और जितना अधिक समय वे निष्क्रिय रहते हैं, उतने ही सस्ते होते जाते हैं। एक sandbox एक-एक चरण करके ठंडा (cool down) होता है: active, फिर frozen, फिर stopped, और अंत में archived। कोई भी acquire command इसे उस चरण से वापस ऊपर ले आता है जहाँ तक वह पहुँचा था।

Freezing वह हिस्सा है जिसे समझना जरूरी है, क्योंकि यही हर agent के sandbox को हमेशा के लिए किफायती बनाए रखता है। ये project के अपने प्रकाशित आंकड़े हैं, जिन्हें इसके hardware पर मापा गया है, न कि आपके hardware पर।

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

1024 MiB memory रखने वाला एक idle sandbox frozen होने के बाद 5 MiB resident memory पर आ जाता है, और लगभग 50 ms में वापस active हो जाता है। Processes अपनी जगह पर ही suspend और resume होती हैं, इसलिए एक long-lived agent freeze के दौरान भी अपनी shell state और अधूरे काम को सुरक्षित रखता है। इसके आधार पर capacity plan करने से पहले इसे अपने host पर reproduce करें।

इंस्टॉलेशन से पहले होस्ट की आवश्यकताएं

होस्ट Ubuntu या Debian (x86_64) पर आधारित होना चाहिए और इंस्टॉलर को root एक्सेस की आवश्यकता होती है। daemon रनटाइम के दौरान root एक्सेस बनाए रखता है क्योंकि यह loop mounts करता है और cgroups में लिखता है।

Sandboxes, Docker के साथ gVisor (एक container runtime जो container और host kernel के बीच एक userspace kernel रखता है) के अंतर्गत चलते हैं, जो runsc प्रदान करता है जिसे प्रत्येक sandbox उपयोग करता है। daemon को चलाने के लिए Node 22 या उससे नया संस्करण आवश्यक है, और इंस्टॉलर अपनी स्वयं की copy साथ लाता है, इसलिए आपके सिस्टम का Node प्रभावित नहीं होता है।

Swap का होना अनिवार्य है और vm.swappiness का मान 100 होना चाहिए। यह ट्यूनिंग की सलाह नहीं, बल्कि एक कार्यात्मक आवश्यकता है। Freezing की प्रक्रिया एक idle sandbox की memory को swap में भेजकर काम करती है, gVisor sandbox की memory को shared memory के रूप में रखता है, और kernel डिफ़ॉल्ट swappiness पर shared memory को swap नहीं करेगा। प्रोजेक्ट ने पाया कि डिफ़ॉल्ट मान पर 0 bytes reclaim हुए, जबकि 100 के मान पर 99.5 प्रतिशत memory reclaim हुई। जांचें कि kernel वास्तव में किस मान का उपयोग कर रहा है, क्योंकि कुछ cloud images में vm.swappiness = 0 ऐसी फ़ाइल में होता है जिसे आप शायद ही कभी देखें।

sysctl vm.swappiness
swapon --show

sysctl vm.swappiness को vm.swappiness = 100 प्रिंट करना चाहिए, और swapon --show में एक swapfile दिखनी चाहिए। यदि swappiness 0 प्रिंट होता है, तो प्रत्येक freeze एक no-op है, जिसका अर्थ है कि आप प्रत्येक idle sandbox के लिए पूरी memory का भुगतान कर रहे हैं।

Ubuntu पर Dormice इंस्टॉल करना

दस्तावेजीकृत इंस्टॉलेशन प्रक्रिया bash में एक पाइप के माध्यम से होती है:

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

इसे चलाने से पहले इसे फेच करें और पढ़ें। यह स्क्रिप्ट root के रूप में चलती है और आपके होस्ट को पुनर्गठित करती है: यदि Docker मौजूद नहीं है तो यह उसे इंस्टॉल करती है, checksum वेरिफिकेशन के साथ gVisor और Caddy को डाउनलोड करती है, एक swapfile बनाती है, systemd यूनिट्स लिखती है, और 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 में, सैंडबॉक्स डेटा /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 की पूर्व-आवश्यकता (prerequisite) से संबंधित होता है।

इंस्टॉलर बॉक्स पर Caddy भी डालता है, इसलिए यह तय करने से पहले कि firewall का काम पूरा हो गया है, देखें कि कौन सा पोर्ट लिसन कर रहा है।

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 हमेशा एक ही सैंडबॉक्स लौटाती है, जिसे आवश्यकतानुसार बनाया, जगाया, शुरू किया या रिस्टोर किया जाता है। अन्य सभी वर्ब किसी ऐसी key के लिए 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 प्रत्येक सैंडबॉक्स को उसकी lifecycle state के साथ सूचीबद्ध करता है, जिससे आप यह देख सकते हैं कि कोई सैंडबॉक्स active से frozen स्थिति में कैसे आता है। dor sandbox exec Python 3.12 संस्करण प्रिंट करता है, क्योंकि स्टॉक इमेज Ubuntu 24.04 है जिसमें Python 3.12, Node 24, git और ripgrep पहले से इंस्टॉल हैं। यदि इसके बजाय authentication error आती है, तो इसका मतलब है कि आपने जो टोकन लाइन कॉपी की थी, उसमें वेरिएबल का नाम भी शामिल था।

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

Destroying एकमात्र ऐसा वर्ब है जिससे डेटा नष्ट हो जाता है, और यह प्रोजेक्ट की आयु का भी एक सटीक उदाहरण है: मुख्य 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

एक सफल रन exit code 0 और 42 प्रिंट करता है। API key आपका Dormice टोकन है जिसके आगे e2b_ उपसर्ग लगा है, जो कि वह प्रारूप है जिसकी compatibility layer अपेक्षा करती है।

यह compatibility कोई स्टब नहीं है। स्ट्रीमिंग stdout और stderr, बैकग्राउंड कमांड, एक इंटरैक्टिव PTY, हस्ताक्षरित अपलोड और डाउनलोड URL, डायरेक्टरी वाचिंग और एक पोर्ट प्रॉक्सी, ये सभी आधिकारिक पैकेज के माध्यम से एक वास्तविक Docker और gVisor डेमन पर प्रोजेक्ट के एंड-टू-एंड सूट द्वारा उपयोग किए जाते हैं। किसी भी वास्तविक चीज़ को माइग्रेट करने से पहले कुछ अंतरों पर ध्यान देना आवश्यक है:

• टेम्पलेट बिल्ड लागू नहीं किए गए हैं। एक टेम्पलेट वह docker इमेज है जिसे आप स्वयं बनाते हैं और dor template add के साथ रजिस्टर करते हैं, और Sandbox.create('name') इसे रिज़ॉल्व करता है। एक अपंजीकृत नाम होने पर यह बहाना बनाने के बजाय 404 त्रुटि देता है।
• E2B इंटरफेस के माध्यम से बनाए गए सैंडबॉक्स को वास्तविक समय-सीमा (deadlines) मिलती है, क्योंकि E2B सिमेंटिक्स के लिए उनकी आवश्यकता होती है। नेटिव API के माध्यम से बनाए गए सैंडबॉक्स पर कभी भी समय-सीमा लागू नहीं की जाती है।
• एक फ्रोजन सैंडबॉक्स अपनी प्रक्रियाओं को बनाए रखता है और उन्हें बीच से ही फिर से शुरू करता है, इसलिए यहाँ पॉज़ और रिज़्यूम वह स्टॉप और कोल्ड स्टार्ट नहीं है जिसके आप आदी हो सकते हैं।

सैंडबॉक्स क्या रोकता है और क्या नहीं

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 टोकन क्लाइंट साइड पर पूरी सुरक्षा सीमा है। DORMICE_API_TOKEN रखने वाली कोई भी चीज़ मशीन पर हर सैंडबॉक्स को बना, पढ़ और नष्ट कर सकती है। एजेंट प्रोसेस को अपना VPS पर लीस्ट प्रिविलेज यूजर दें और टोकन के साथ वैसा ही व्यवहार करें जैसा आप SSH की (key) के साथ करते हैं। VPS पर सुरक्षित रूप से Claude Code चलाने की आदतें सीधे यहाँ लागू होती हैं।

डेमन खुद आपके होस्ट पर root के रूप में चलता है। gVisor होस्ट को सैंडबॉक्स के अंदर के कोड से बचाता है, और डेमन या उसके टोकन को रखने वाले किसी भी व्यक्ति से होस्ट को कुछ भी नहीं बचाता है। इसलिए Dormice चलाने वाली मशीन ऐसी होनी चाहिए जो केवल वही काम करे। यदि आपका एजेंट MCP (model context protocol) के माध्यम से टूल्स तक भी पहुँचता है, तो उसी कारण से उन MCP सर्वर्स को एक अलग VPS पर रखें।

4 GB और 8 GB में कितने सैंडबॉक्स समा सकते हैं?

मेमोरी मुख्य रूप से दो चीजों द्वारा खपत होती है: होस्ट का अपना बेसलाइन, और वर्तमान में सक्रिय प्रत्येक सैंडबॉक्स का वर्किंग सेट। Ubuntu, Docker और डेमन के लिए लगभग 1 GB सुरक्षित रखें, फिर शेष मेमोरी को एक सैंडबॉक्स द्वारा वास्तव में उपयोग की जाने वाली मेमोरी से विभाजित करें। एक 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
  }
]

एक 4 GB VPS एक साथ 6 सैंडबॉक्स को सक्रिय रख सकता है यदि प्रत्येक 512 MiB का उपयोग करता है, या 3 यदि प्रत्येक एक पूर्ण gibibyte का उपयोग करता है। एक 8 GB VPS इसे 14 और 7 तक ले जाता है। ये समवर्ती कार्य के लिए अधिकतम सीमाएं हैं, और ये बेंचमार्क के बजाय गणितीय गणना हैं, इसलिए अपना लोड चलाते समय free -m पर नज़र रखें।

फ्रोजन सैंडबॉक्स RAM के बजाय स्वैप (swap) द्वारा सीमित होते हैं, जो इस डिज़ाइन का मुख्य उद्देश्य है। एक फ्रोजन सैंडबॉक्स जो एक gibibyte का उपयोग कर रहा था, वह लगभग उतनी ही मात्रा स्वैप में रखता है और RAM में लगभग कुछ भी नहीं, इसलिए इंस्टॉलर की डिफ़ॉल्ट 16 GB स्वैपफाइल उनमें से लगभग 16 को पार्क कर सकती है। इसके बाद उन्हें 'stopped' स्थिति में जाने की आवश्यकता होती है, जहाँ वे केवल डिस्क स्पेस लेते हैं। यहाँ डिस्क ही वास्तविक दीर्घकालिक सीमा है: प्रत्येक सैंडबॉक्स अपना फाइलसिस्टम रखता है, और कुछ दर्जन एजेंट्स, जिनमें से प्रत्येक में node_modules डायरेक्टरी होती है, मेमोरी के महत्वपूर्ण होने से बहुत पहले ही एक छोटी वॉल्यूम को भर देंगे।

Freeze, stop, archive: lifecycle knobs

Default settings के अनुसार, 10 मिनट idle रहने पर freeze, 3 दिन बाद stop, और archiving configure होने पर 7 दिन बाद archive की प्रक्रिया होती है। stopAfterSeconds को null पर सेट करने से आपको एक resident agent मिलता है: यह idle होने पर freeze हो सकता है, लेकिन कभी भी cold start नहीं होता।

Archiving वैकल्पिक है, और daemon इस बारे में स्पष्ट रहता है। चार DORMICE_S3_* variables को सेट करें, और एक stopped sandbox की disk को tar और zstd के साथ pack किया जाता है, किसी भी S3-compatible bucket पर ship किया जाता है, और स्थानीय रूप से free कर दिया जाता है। वह bucket आपके द्वारा host किया गया MinIO bucket हो सकता है जो आपकी किसी अन्य machine पर स्थित हो। यदि variables को unset छोड़ दिया जाए, तो sandboxes हमेशा के लिए stopped अवस्था में ही रहते हैं, और archive करने की policy को चुपचाप ignore करने के बजाय अस्वीकार कर दिया जाता है। Restores silent होने के बजाय दिखाई देते हैं: अगला acquire तुरंत restoring status और progress value के साथ जवाब देता है, और disk वापस आने पर ready अवस्था में आ जाता है।

क्या आपको अभी इस पर निर्भर रहना चाहिए?

सीधा जवाब: किसी भी ऐसी चीज़ के लिए नहीं जिसे आप दोबारा न बना सकें। रिपॉजिटरी में पहला कमिट 8 July 2026 का है। 4 August 2026 तक इसमें 446 स्टार्स, 37 फोर्क्स, Apache-2.0 लाइसेंस है, और कोई भी टैग किया गया release नहीं है। README की अपनी स्टेटस लाइन कहती है कि वहां कुछ भी production के लिए तैयार नहीं है।

इस संयोजन में जोखिम का एक विशिष्ट स्वरूप है। कोड आपके नीचे बदलता रहता है, क्योंकि इंस्टॉलर main को ट्रैक करता है। इंटरफ़ेस अभी भी स्थिर हो रहा है, और यही कारण है कि एक ही रिपॉजिटरी में दो अलग-अलग फाइलों में delete वर्ब के दो अलग-अलग नाम हैं। और चार सप्ताह पुराना प्रोजेक्ट बस बंद हो सकता है, क्योंकि कोई भी लाइसेंस क्लॉज किसी को भी इसे जारी रखने के लिए बाध्य नहीं करता है।

जो जोखिम को सहनीय बनाता है वह E2B अनुकूलता है। आपका एप्लिकेशन एक ऐसे प्रोटोकॉल से बात करता है जिसके पीछे एक hosted कार्यान्वयन है, इसलिए यदि Dormice रुक जाता है तो आप दो URLs बदलते हैं और काम जारी रखते हैं। अपने एजेंट को native API के बजाय E2B इंटरफ़ेस के विरुद्ध लिखें और आप उस निकास मार्ग को बनाए रखते हैं। native @dormice/sdk पैकेज अभी तक npm पर भी नहीं है, इसलिए इसका उपयोग करने का मतलब है इसे रिपॉजिटरी से बनाना, जो कि compatible path के साथ शुरू करने का दूसरा कारण है।

इसे वहां चलाएं जहां आप इसे खोने का जोखिम उठा सकते हैं। होस्ट को स्क्रिप्ट से दोबारा बनाएं, टोकन को हर प्रॉम्प्ट और हर कमिट से बाहर रखें, और जो कुछ भी रखने लायक है उसे अपने बैकअप शेड्यूल पर सैंडबॉक्स से बाहर निकालें।

FAQ

क्या Dormice production के लिए तैयार है?

नहीं, और प्रोजेक्ट स्वयं भी यही कहता है। README की status line बताती है कि वहां मौजूद कोई भी चीज़ अभी production के लिए तैयार नहीं है, और 4 August 2026 तक यह repository लगभग चार सप्ताह पुरानी है जिसमें कोई git tags और कोई releases नहीं हैं, इसलिए pin करने के लिए कोई version number उपलब्ध नहीं है। Installer main branch को clone करता है, जिसका अर्थ है कि हर बार run करने पर आपको सबसे नया commit मिलता है। हर install के बाद git -C /opt/dormice rev-parse HEAD को record करें, और किसी भी महत्वपूर्ण चीज़ को sandboxes के बाहर रखें।

Dormice मेरे agent को disposable VM देने से किस प्रकार अलग है?

Disposable VM एक ऐसी machine है जिसमें SSH होता है जिसे आप एक session के लिए बनाते हैं और बाद में delete कर देते हैं। Dormice एक execution API है: आपका program acquire, फिर exec को call करता है, और बीच में किसी shell session के बिना stdout और एक exit code प्राप्त करता है। VM उस इंसान या agent के लिए उपयुक्त है जो कुछ समय के लिए पूरी computer चाहता है। Dormice उस application के लिए उपयुक्त है जो दिन में कई बार generated code चलाती है और हर run के लिए machine के setup और teardown की प्रक्रिया नहीं चाहती।

क्या आधिकारिक E2B SDK वास्तव में बिना code बदले काम करता है?

हाँ, configuration में बदलाव के साथ। apiUrl और sandboxUrl को अपने daemon पर /e2b/api और /e2b/envd की ओर point करें, और अपने Dormice token को e2b_ prefix के साथ API key के रूप में pass करें। Command execution, PTY sessions, file transfer, signed URLs और port proxy, सभी प्रोजेक्ट के end-to-end suite द्वारा कवर किए जाते हैं जो आधिकारिक package के माध्यम से चलता है। Template building एक उल्लेखनीय कमी है: e2b template build implement नहीं किया गया है, इसलिए template एक docker image है जिसे आप build करते हैं और dor template add के साथ register करते हैं।

4 GB VPS पर कितने sandboxes आ सकते हैं?

यदि प्रत्येक sandbox 512 MiB का उपयोग करता है, तो एक ही समय में लगभग 6 सक्रिय रह सकते हैं, या यदि प्रत्येक एक full gibibyte का उपयोग करता है, तो 3 सक्रिय रह सकते हैं। यह operating system, Docker और daemon के लिए लगभग 1 GB आरक्षित करने के बाद की संख्या है। Frozen sandboxes की संख्या swap द्वारा सीमित होती है, इसलिए installer की default 16 GB swapfile लगभग 16 sandboxes को park कर सकती है, जिनमें से प्रत्येक एक gibibyte का उपयोग करता है। वास्तविक load के तहत free -m के साथ स्वयं मापें, क्योंकि test suite चलाने वाला sandbox, छोटा script चलाने वाले sandbox की तुलना में कई गुना अधिक memory का उपयोग करता है।

Dormice को vm.swappiness को 100 पर सेट करने की आवश्यकता क्यों है?

Sandbox को freeze करने का अर्थ है उसकी idle memory को swap में धकेलना। gVisor sandbox की memory को shared memory के रूप में रखता है, और Linux kernel default swappiness पर shared memory को swap नहीं करेगा। इसलिए, default settings पर freeze करने से कुछ भी reclaim नहीं होता और sandbox पूरी memory की लागत लेता रहता है। प्रोजेक्ट ने default पर 0 bytes reclaim होने और 100 पर 99.5 प्रतिशत reclaim होने का मापन किया है। Config files को पढ़ने के बजाय sysctl vm.swappiness के साथ प्रभावी value की जाँच करें, क्योंकि कुछ cloud images 0 की value के साथ आती हैं।