Dormice کو self-host کر کے agent sandboxes چلائیں

Dormice کیا ہے، اور کیا نہیں ہے

Dormice ایک self-hosted agent sandbox ہے: آپ کی ملکیت والے Linux VPS پر چلنے والا ایک daemon، جسے آپ کا agent code HTTP کے ذریعے untrusted code کو isolated container کے اندر چلانے کے لیے استعمال کرتا ہے۔ آپ کا پروگرام نام کے ذریعے sandbox کی درخواست کرتا ہے، حالت کچھ بھی ہو وہی sandbox دوبارہ حاصل کرتا ہے، اس کے اندر command چلاتا ہے، اور output پڑھتا ہے۔ Sandbox ایک programmatic resource ہے، ایسی machine نہیں جس میں آپ login کرتے ہیں۔

یہ طریقہ agent کو پورا computer دینے سے مختلف ہے۔ ایک coding agent کے لیے عارضی VM ایسی machine ہے جس میں آپ SSH کے ذریعے داخل ہوتے ہیں، agent کو اسے خراب کرنے دیتے ہیں، پھر اسے delete کر دیتے ہیں۔ Dormice اس سے ایک سطح نیچے کام کرتا ہے: یہ وہ execution API ہے جسے آپ کا پروگرام اس وقت call کرتا ہے جب اس کے پاس پہلے ہی code موجود ہو اور اسے محفوظ execution کے لیے جگہ درکار ہو۔ جب پورا machine کام کی اکائی ہو تو عارضی VM استعمال کریں۔ جب ایک exec call کام کی اکائی ہو اور آپ روزانہ سو calls چلانا چاہتے ہوں، مگر سو VMs نہ بنانا چاہیں، تو Dormice استعمال کریں۔

پروجیکٹ خود کو E2B compatible کہتا ہے۔ E2B ایک hosted sandbox service ہے جس کی client library بہت سے agent frameworks پہلے ہی import کرتے ہیں۔ Dormice اپنی URL prefixes کے تحت وہی protocol فراہم کرتا ہے، اس لیے official e2b package کے خلاف لکھی گئی application اس وقت بھی چلتی رہتی ہے جب آپ اسے اپنے box کی طرف point کرتے ہیں۔ Application code میں تبدیلی نہیں ہوتی۔ صرف دو URLs اور ایک API key prefix تبدیل ہوتے ہیں۔

ایجنٹ sandbox کے "SQLite" سے عملی طور پر کیا مراد ہے

SQLite ایسی database ہے جسے آپ operate کرنے والی service کے بجائے embed کرتے ہیں، اور Dormice اسی تقابل سے براہِ راست فائدہ اٹھاتا ہے۔ ایک daemon، ledger کے لیے ایک SQLite file، اور ایک TCP port۔ Kubernetes نہیں، الگ database نہیں، اور scheduler نہیں۔ daemon اپنے ledger کے ساتھ lock بناتا ہے اور اس وقت start ہونے سے انکار کر دیتا ہے جب اس کا ledger اور اسے ملنے والی machine ایک ہی نظام کا حصہ نہ ہو سکتے ہوں۔ اس طرح split brain خاموشی سے واقع نہیں ہو سکتا۔ یہ design ایک ہی machine کے لیے ہے۔ اگر آپ کو بہت سے hosts پر پھیلا ہوا fleet درکار ہے تو README صاف طور پر کسی اور چیز کا انتخاب کرنے کو کہتی ہے، اور آپ کو اس ہدایت پر عمل کرنا چاہیے۔

اس تصور کا دوسرا حصہ لاگت سے متعلق ہے۔ Hosted sandbox کے موجود رہنے کے ہر second کی billing ہوتی ہے، اس لیے hosted sandboxes بنیادی طور پر عارضی ہوتے ہیں۔ Dormice اس hardware پر چلتا ہے جس کی آپ پہلے ہی ادائیگی کر رہے ہیں، اس لیے اس کے sandboxes مستقل رہتے ہیں اور جتنی دیر غیر فعال رہیں، اتنے ہی کم خرچ پڑتے ہیں۔ ایک sandbox مرحلہ وار idle ہوتا ہے: active، پھر frozen، پھر stopped، اور آخر میں archived۔ acquire کرنے پر وہ جس مرحلے تک پہنچا ہو، وہیں سے دوبارہ فعال ہو جاتا ہے۔

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 freeze ہونے کے بعد صرف 5 MiB resident memory استعمال کرتا ہے، اور تقریباً 50 ms میں دوبارہ فعال ہو جاتا ہے۔ Processes اسی جگہ suspend اور resume ہوتے ہیں، اس لیے طویل عرصے تک چلنے والا agent freeze کے دوران اپنا shell state اور ادھورا کام برقرار رکھتا ہے۔ Capacity planning اسی بنیاد پر کرنے سے پہلے اسے اپنے host پر reproduce کریں۔

انسٹال کرنے سے پہلے host کی ضروریات

host پر x86_64 کے لیے Ubuntu یا Debian ہونا چاہیے، اور installer کو root درکار ہے۔ daemon runtime کے دوران root برقرار رکھتا ہے، کیونکہ یہ loop mounts بناتا اور cgroups میں لکھتا ہے۔

Sandboxes، gVisor کے ساتھ Docker میں چلتے ہیں۔ gVisor ایک container runtime ہے جو container kernel اور host kernel کے درمیان userspace kernel رکھتا ہے۔ یہی ہر sandbox کے لیے runsc runtime فراہم کرتا ہے۔ daemon چلانے کے لیے Node 22 یا اس کے بعد کا ورژن درکار ہے۔ installer اپنی copy شامل کرتا ہے، اس لیے سسٹم کا Node متاثر نہیں ہوتا۔

Swap موجود ہونا چاہیے، اور vm.swappiness کی قدر 100 ہونی چاہیے۔ یہ tuning کا مشورہ نہیں بلکہ functional requirement ہے۔ Freeze کا عمل idle sandbox کی memory کو swap میں منتقل کرتا ہے۔ gVisor sandbox memory کو shared memory کے طور پر رکھتا ہے، اور default swappiness پر kernel shared memory کو swap نہیں کرتا۔ project نے default value پر 0 bytes reclaim ہوتے اور 100 پر 99.5 percent reclaim ہوتے ناپے۔ وہ value چیک کریں جسے kernel واقعی استعمال کر رہا ہے، کیونکہ بعض cloud images vm.swappiness = 0 کو ایسی file میں set کرتی ہیں جسے آپ کبھی پڑھنے کا نہیں سوچیں گے۔

sysctl vm.swappiness
swapon --show

sysctl vm.swappiness کو vm.swappiness = 100 دکھانا چاہیے، اور swapon --show کو swapfile کی فہرست دکھانی چاہیے۔ اگر swappiness 0 دکھائے تو ہر freeze بے اثر ہوگا، اور ہر idle sandbox کے لیے مکمل memory استعمال کی لاگت برقرار رہے گی۔

Ubuntu پر Dormice انسٹال کریں

دستاویزی طریقہ bash میں ایک pipe بھیجنے پر مشتمل ہے:

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

اسے حاصل کریں اور چلانے سے پہلے پڑھیں۔ یہ script root کے طور پر چلتی ہے اور host میں تبدیلیاں کرتی ہے: اگر Docker موجود نہ ہو تو اسے انسٹال کرتی ہے، checksum verification کے ساتھ gVisor اور Caddy download کرتی ہے، swapfile بناتی ہے، systemd units لکھتی ہے، اور firewall rules شامل کرتی ہے۔

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 کا سائز مقرر کرتا ہے اور اس کی default قدر 16 ہے، جو چھوٹے VPS پر مختص کرنے کے لیے disk space کی خاصی بڑی مقدار ہے۔ --mirror cn downloads کو mainland China سے قابل رسائی mirrors پر منتقل کرتا ہے۔ Installer دوبارہ چلانے سے code upgrade ہوتا ہے اور configuration drift درست ہوتی ہے؛ یہ آپ کا API token کبھی rotate نہیں کرتا۔

Code /opt/dormice میں، configuration /etc/dormice/env میں، sandbox data /var/lib/dormice میں، اور dormice اور dor commands /usr/local/bin میں موجود ہوتے ہیں۔ Installer انسٹالیشن کے دوران API token بناتا ہے اور اسے mode 600 کے ساتھ /etc/dormice/env میں لکھتا ہے۔

انسٹالیشن کے لیے کوئی tagged release موجود نہیں۔ 4 August 2026 تک repository میں کوئی git tags یا GitHub releases نہیں ہیں، اس لیے installer main کو clone کرتا ہے اور آپ کو وہی code ملتا ہے جو اس صبح repository میں شامل ہوا ہو۔ اس لیے version pin کرنے کا مطلب ہے کہ آپ نے جو commit واقعی انسٹال کیا، اسے لکھ کر محفوظ کریں۔

git -C /opt/dormice rev-parse HEAD

اس hash کو اپنی deploy notes کے ساتھ محفوظ کریں۔ جب upgrade کے بعد کچھ خراب ہو جائے تو واپسی کا واحد راستہ یہی commit ہے، کیونکہ مانگنے کے لیے کوئی version number موجود نہیں۔

Installer آخر میں dor doctor چلاتا ہے۔ یہ read-only host check ہے جو حقیقی gVisor containers کو boot کر کے ثابت کرتا ہے کہ runtime کام کرتا ہے، بجائے اس کے کہ صرف package list پر اعتماد کرے۔ Daemon کے غیر متوقع طریقے سے کام کرنے پر اسے دوبارہ چلائیں۔

sudo dor doctor
systemctl is-active dormice

systemctl is-active dormice کو active print کرنا چاہیے۔ اگر یہ failed print کرے تو journalctl -u dormice -n 50 میں وجہ موجود ہوتی ہے، اور failed start عموماً daemon کے بجائے swap یا gVisor prerequisite کی وجہ سے ہوتا ہے۔

Installer host پر Caddy بھی انسٹال کرتا ہے، اس لیے firewall configuration مکمل سمجھنے سے پہلے دیکھیں کہ کون سی services listening کر رہی ہیں۔

sudo ss -lntp

Daemon 127.0.0.1:3676 پر bind ہوتا ہے اور اسے تبدیل کرنے کی کوئی setting موجود نہیں؛ یہ جان بوجھ کر ایسا رکھا گیا ہے۔ اپنے laptop سے اس تک پہنچنا ایک دانستہ کارروائی ہے، اور اس کا آسان طریقہ SSH tunnel ہے۔

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

Tunnel کھلا ہونے پر آپ کے laptop میں http://127.0.0.1:3676/console web console ہے۔ ایک بار token کے ذریعے sign in کریں؛ اس کے بعد یہ httpOnly session cookie بن جاتا ہے، اس لیے token خود ایسی جگہ محفوظ نہیں ہوتا جہاں page اسے پڑھ سکے۔ وہاں موجود Connect page copy-and-paste client snippets دکھاتا ہے جو پہلے ہی آپ کے اپنے endpoint کی طرف متوجہ ہوتے ہیں۔

ایک sandbox بنائیں اور اس میں code چلائیں

ایک operation sandbox بناتا ہے: acquire۔ یہ idempotent ہے، اس لیے ایک ہی key ہمیشہ وہی sandbox واپس کرتی ہے۔ ضرورت کے مطابق sandbox بنایا، بیدار، شروع یا restore کیا جاتا ہے۔ ہر دوسرا verb ایسی key کے لیے 404 واپس کرتا ہے جسے اس نے پہلے نہیں دیکھا۔ dor CLI میں acquire verb موجود نہیں، اس لیے آپ کا پہلا sandbox console یا client library سے حاصل ہوتا ہے۔

console route سب سے تیز ہے۔ tunnel کے ذریعے /console کھولیں اور my-agent نام کا sandbox بنائیں۔ اس کے بعد 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 ہر sandbox کو اس کی lifecycle state کے ساتھ دکھاتا ہے۔ اسی سے آپ دیکھ سکتے ہیں کہ کوئی sandbox active سے frozen میں تبدیل ہو رہا ہے۔ dor sandbox exec Python 3.12 کا version دکھاتا ہے، کیونکہ stock image Ubuntu 24.04 پر مبنی ہے اور اس میں Python 3.12، Node 24، git اور ripgrep پہلے سے installed ہیں۔ اس کے بجائے authentication error کا مطلب ہے کہ آپ کی copy کی گئی token line میں variable name بھی شامل تھا۔

Files dor sandbox push my-agent ./script.py کے ذریعے منتقل ہوتی ہیں اور /home/user/script.py پر پہنچتی ہیں، جبکہ dor sandbox pull my-agent notes.txt ایک file واپس لاتا ہے۔ Native file verbs فی file 16 MiB تک محدود ہیں، جبکہ E2B file surface stream کی سہولت دیتی ہے اور sandbox disk quota کو واحد حد بناتی ہے۔

Destroy کرنا واحد ایسا verb ہے جس سے data ضائع ہوتا ہے۔ یہ project کی عمر کی بھی ایک واضح مثال ہے: main README اور bundled agent skill دونوں dor sandbox destroy <key> درج کرتے ہیں، جبکہ CLI package README میں dor sandbox release <key> درج ہے۔ اپنی build پر dor sandbox --help چلائیں اور اسی output کو درست سمجھیں۔

اپنے موجودہ E2B code کو اپنے server کی طرف بھیجیں

یہی اس کی اہم وجہ ہے۔ npm کا official e2b package بغیر کسی ترمیم کے Dormice سے بات کرتا ہے۔ SSH tunnel کھلا رکھ کر یہ command اپنے laptop سے چلائیں، تاکہ server پر کوئی نئی service 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

کامیاب run میں exit code 0 اور 42 ظاہر ہوتا ہے۔ API key آپ کا Dormice token ہے، جس کے آگے e2b_ prefix لگایا جاتا ہے۔ compatibility layer اسی format کی توقع کرتی ہے۔

یہ compatibility صرف stub نہیں ہے۔ Project کی end-to-end suite، official package کے ذریعے، حقیقی Docker اور gVisor daemon کے خلاف streaming stdout اور stderr، background commands، interactive PTY، signed upload اور download URLs، directory watching، اور port proxy سب کی جانچ کرتی ہے۔ حقیقی migration سے پہلے چند اہم فرق ذہن میں رکھیں:

• Template builds implemented نہیں ہیں۔ Template وہ docker image ہے جسے آپ خود build کر کے dor template add کے ساتھ register کرتے ہیں، اور Sandbox.create('name') اسے resolve کرتا ہے۔ غیر registered نام پر دکھاوا کرنے کے بجائے 404 واپس کیا جاتا ہے۔
• E2B surface کے ذریعے بنائے گئے sandboxes کو حقیقی deadlines ملتی ہیں، کیونکہ E2B semantics میں یہ ضروری ہیں۔ Native API کے ذریعے بنائے گئے sandboxes پر کبھی deadlines عائد نہیں کی جاتیں۔
• Frozen sandbox اپنے processes برقرار رکھتا ہے اور انہیں اسی حالت میں دوبارہ resume کرتا ہے۔ اس لیے یہاں pause اور resume، وہ stop اور cold start نہیں ہے جس کے آپ عادی ہو سکتے ہیں۔

سینڈ باکس کیا روکتا ہے، اور کیا نہیں روکتا

gVisor کنٹینر کی system calls کو userspace میں intercept کرتا ہے اور خود handle کرتا ہے، اس لیے sandboxed code آپ کے host kernel سے براہِ راست رابطہ نہیں کرتا۔ sandbox کے اندر ہر چیز unprivileged user، uid 1000، کے طور پر چلتی ہے۔ یہ امتزاج عام صورتِ حال کو سنبھال لیتا ہے: generated script اگر rm -rf / چلائے، disk بھر دے، یا کسی عمل کے ختم ہونے تک مسلسل fork کرے، تو نقصان اسی sandbox تک محدود رہتا ہے اور وہیں رک جاتا ہے۔

یہ چیزیں نہیں رکتیں۔ ان میں سے ہر ایک آپ کی ذمہ داری ہے۔

• sandbox کو outbound network تک رسائی حاصل ہوتی ہے۔ generated code اپنی مرضی کی کوئی بھی چیز download کر سکتا ہے اور جو کچھ ملے اسے post کر سکتا ہے۔ installer کی network hardening دو مخصوص چیزوں کا احاطہ کرتی ہے: یہ cloud metadata service کے لیے container traffic کو 169.254.0.0/16 پر drop کرتی ہے۔ یہی وہ جگہ ہے جہاں cloud ہر اس چیز کو instance credentials فراہم کرتا ہے جو وہاں تک پہنچ سکتی ہو۔ یہ Docker کے daemon.json میں "icc": false استعمال کرکے container-to-container traffic بھی بند کرتی ہے۔ اس کے علاوہ کچھ بھی block نہیں ہوتا۔ sudo iptables -S DOCKER-USER پڑھیں اور ان private ranges کے لیے اپنی DROP rules شامل کریں جہاں sandbox کو رسائی نہیں ہونی چاہیے۔
• Docker آپ کے firewall سے پہلے اپنی rules داخل کرتا ہے، اس لیے published container port انٹرنیٹ سے جواب دے سکتا ہے، جبکہ ufw اسے closed ظاہر کرتا ہے۔ اس host پر کچھ بھی expose کرنے سے پہلے Docker کے ufw سے آگے ports publish کرنے کا طریقہ اور VPS کے لیے ufw firewall کی بنیادی باتیں پڑھیں۔
• gVisor ایک userspace kernel ہے، hypervisor نہیں۔ یہ ایک دانستہ trade-off ہے، کیونکہ freezing کے لیے sandboxes کا processes ہونا ضروری ہے، اور KVM کا تقاضا اس چیز کو ہر جگہ install ہونے سے روک دے گا۔ اگر آپ کے threat model میں hardware virtualisation ضروری ہے تو Firecracker-class isolation استعمال کریں اور اس کے ساتھ آنے والی operational cost قبول کریں۔
• client side پر مکمل security boundary API token ہے۔ DORMICE_API_TOKEN رکھنے والی کوئی بھی چیز machine کے ہر sandbox کو create، read اور destroy کر سکتی ہے۔ agent process کو اپنی VPS پر least privilege user دیں اور token کے ساتھ وہی احتیاط برتیں جو SSH key کے ساتھ برتتے ہیں۔ VPS پر Claude Code محفوظ طریقے سے چلانے کی عادات یہاں بھی براہِ راست لاگو ہوتی ہیں۔

daemon خود آپ کے host پر root کے طور پر چلتا ہے۔ gVisor host کو sandbox کے اندر موجود code سے محفوظ رکھتا ہے، لیکن daemon یا اس کا token رکھنے والے شخص سے host کو کوئی تحفظ حاصل نہیں ہوتا۔ اس لیے Dormice چلانے والی machine کو صرف اسی کام کے لیے مختص ہونا چاہیے۔ اگر آپ کا agent MCP (model context protocol) کے ذریعے tools تک بھی پہنچتا ہے تو اسی وجہ سے وہ MCP servers ایک الگ VPS پر رکھیں۔

4 GB اور 8 GB میں کتنے sandboxes سما سکتے ہیں؟

دو چیزیں memory استعمال کرتی ہیں: host کا اپنا baseline، اور اس وقت فعال ہر sandbox کا working set۔ Ubuntu، Docker اور daemon کے لیے تقریباً 1 GB reserve کریں، پھر باقی memory کو اس مقدار سے تقسیم کریں جو آپ کا ایک sandbox حقیقت میں استعمال کرتا ہے۔ ایسا sandbox جو چند files پڑھنے والا Python script چلا رہا ہو، عموماً 200 سے 300 MiB استعمال کرتا ہے۔ compiler یا مکمل test suite چلانے والا sandbox 1 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
  }
]

اگر ہر sandbox 512 MiB استعمال کرے تو 4 GB VPS میں ایک وقت میں تقریباً 6 sandboxes فعال رہ سکتے ہیں، جبکہ ہر sandbox کے لیے مکمل gibibyte درکار ہو تو یہ تعداد 3 رہ جاتی ہے۔ 8 GB VPS میں یہ تعداد بالترتیب 14 اور 7 ہو جاتی ہے۔ یہ concurrent work کی زیادہ سے زیادہ حدیں ہیں، benchmark نہیں؛ اس لیے اپنے load کے دوران free -m کو monitor کریں۔

Frozen sandboxes کو RAM کے بجائے swap محدود کرتی ہے، اور یہی اس design کا بنیادی مقصد ہے۔ جو frozen sandbox 1 gibibyte استعمال کر رہا تھا، وہ تقریباً اتنی ہی مقدار swap میں رکھتا ہے اور resident memory میں تقریباً کچھ نہیں رکھتا۔ اس لیے installer کی default 16 GB swapfile تقریباً 16 sandboxes کو عارضی طور پر رکھ سکتی ہے۔ اس حد کے بعد انہیں stopped rung تک پہنچنا ہوگا، جہاں وہ صرف disk استعمال کرتے ہیں۔ طویل مدت میں اصل حد disk ہے: ہر sandbox اپنا filesystem برقرار رکھتا ہے، اور چند درجن agents، جن میں ہر ایک کا node_modules directory ہو، memory اہم مسئلہ بننے سے بہت پہلے چھوٹا volume بھر دیں گے۔

فریز، روکنا، آرکائیو کرنا: لائف سائیکل کے اختیارات

پہلے سے طے شدہ رویہ یہ ہے کہ 10 منٹ تک غیر فعال رہنے کے بعد فریز کیا جائے، 3 دن بعد روکا جائے، اور آرکائیونگ configured ہونے کی صورت میں 7 دن بعد آرکائیو کیا جائے۔ stopAfterSeconds کو null پر سیٹ کرنے سے آپ کے پاس resident agent آ جاتا ہے: یہ غیر فعال حالت میں فریز ہو سکتا ہے، لیکن cold start کبھی نہیں کرتا۔

آرکائیونگ optional ہے، اور daemon اس بارے میں واضح رہتا ہے۔ چاروں DORMICE_S3_* variables سیٹ کریں؛ پھر stopped sandbox کی disk کو tar اور zstd کے ذریعے pack کیا جاتا ہے، کسی بھی S3-compatible bucket میں منتقل کیا جاتا ہے، اور مقامی طور پر خالی کر دیا جاتا ہے۔ یہ bucket آپ کی کسی دوسری machine پر موجود خود host کیا ہوا MinIO bucket بھی ہو سکتا ہے۔ variables unset چھوڑنے پر sandboxes ہمیشہ stopped حالت میں رہتے ہیں، اور archive کرنے کی درخواست والی policy کو خاموشی سے نظرانداز کرنے کے بجائے مسترد کر دیا جاتا ہے۔ Restores خاموش نہیں رہتے بلکہ واضح طور پر نظر آتے ہیں: اگلا acquire فوراً restoring status اور progress value کے ساتھ جواب دیتا ہے، پھر disk واپس آنے کے بعد حالت ready ہو جاتی ہے۔

کیا ابھی اس پر انحصار کرنا چاہیے؟

سیدھا جواب: ایسی کسی چیز کے لیے نہیں جسے آپ دوبارہ build نہ کر سکیں۔ Repository میں پہلا commit 8 July 2026 کا ہے۔ 4 August 2026 تک اس کے 446 stars، 37 forks، Apache-2.0 licence ہیں، اور کوئی tagged release موجود نہیں۔ README کی اپنی status line بھی کہتی ہے کہ ابھی کچھ بھی production کے لیے تیار نہیں۔

اس امتزاج سے خطرے کی ایک مخصوص صورت بنتی ہے۔ Code آپ کے نیچے بدلتا رہتا ہے، کیونکہ installer main کو track کرتا ہے۔ Interface ابھی مستحکم ہو رہا ہے۔ اسی لیے اسی repository کی دو files میں delete verb کے دو مختلف نام ہیں۔ چار ہفتے پرانا project اچانک رک بھی سکتا ہے، کیونکہ کوئی licence clause کسی کو کام جاری رکھنے کا پابند نہیں کرتی۔

E2B compatibility خطرے کو قابلِ انتظام بناتی ہے۔ آپ کی application ایسے protocol سے بات کرتی ہے جس کے پیچھے hosted implementation موجود ہے۔ اس لیے اگر Dormice رک جائے تو آپ دو URLs تبدیل کرکے کام جاری رکھ سکتے ہیں۔ اپنے agent کو native API کے بجائے E2B surface کے مطابق لکھیں۔ اس طرح یہ متبادل راستہ برقرار رہتا ہے۔ Native @dormice/sdk package ابھی npm پر بھی موجود نہیں۔ اسے استعمال کرنے کے لیے repository سے build کرنا پڑتا ہے۔ یہ compatible path سے شروع کرنے کی دوسری وجہ ہے۔

اسے وہاں چلائیں جہاں اسے کھو دینا قابلِ برداشت ہو۔ Host کو script سے دوبارہ build کریں، token کو ہر prompt اور ہر commit سے باہر رکھیں، اور جو بھی چیز محفوظ رکھنی ہو اسے اپنے backup schedule کے مطابق sandboxes سے باہر نکالتے رہیں۔

FAQ

کیا Dormice production کے لیے تیار ہے؟

نہیں، اور project خود بھی یہی کہتا ہے۔ 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 کریں، اور قیمتی data کو sandboxes کے باہر رکھیں۔

Dormice میرے agent کو disposable VM دینے سے کیسے مختلف ہے؟

Disposable VM ایک ایسی machine ہے جس میں SSH ہوتا ہے، جسے آپ session کے لیے بناتے ہیں اور بعد میں delete کر دیتے ہیں۔ Dormice ایک execution API ہے: آپ کا program acquire کو call کرتا ہے، پھر exec کو call کرتا ہے، اور درمیان میں shell session کے بغیر stdout اور exit code حاصل کرتا ہے۔ VM ایسے human یا agent کے لیے موزوں ہے جسے کچھ وقت کے لیے مکمل computer چاہیے۔ Dormice ایسی application کے لیے موزوں ہے جو دن میں کئی بار generated code چلاتی ہے اور ہر run کے ساتھ machine جتنا setup اور teardown نہیں چاہتی۔

کیا official E2B SDK واقعی code changes کے بغیر کام کرتا ہے؟

ہاں، configuration changes کے ساتھ۔ اپنے daemon پر apiUrl اور sandboxUrl کو /e2b/api اور /e2b/envd کی طرف point کریں، اور e2b_ prefix کے ساتھ اپنا Dormice token API key کے طور پر pass کریں۔ Command execution، PTY sessions، file transfer، signed URLs اور port proxy، سب official package کے ذریعے project کے end-to-end suite میں شامل ہیں۔ Template building نمایاں کمی ہے: e2b template build implemented نہیں ہے، اس لیے template وہ docker image ہے جسے آپ build کر کے dor template add کے ساتھ register کرتے ہیں۔

4 GB VPS پر کتنے sandboxes چل سکتے ہیں؟

اگر ہر sandbox 512 MiB استعمال کرے تو ایک ہی وقت میں تقریباً 6 awake sandboxes چل سکتے ہیں۔ اگر ہر sandbox مکمل gibibyte استعمال کرے تو تقریباً 3، بشرطیکہ operating system، Docker اور daemon کے لیے تقریباً 1 GB محفوظ رکھا جائے۔ Frozen sandboxes swap سے محدود ہوتے ہیں۔ اس لیے installer کی default 16 GB swapfile ایسے تقریباً 16 sandboxes کو park کر سکتی ہے جن میں سے ہر ایک نے ایک gibibyte استعمال کیا ہو۔ حقیقی load کے تحت free -m سے اپنی machine کی پیمائش کریں، کیونکہ test suite چلانے والا sandbox، چھوٹا script چلانے والے sandbox کے مقابلے میں کئی گنا زیادہ memory استعمال کرتا ہے۔

Dormice کو vm.swappiness کی value 100 پر set کرنے کی ضرورت کیوں ہے؟

Sandbox کو freeze کرنے کا مطلب ہے اس کی idle memory کو swap میں منتقل کرنا۔ gVisor sandbox memory کو shared memory کے طور پر رکھتا ہے، اور Linux kernel default swappiness پر shared memory کو swap نہیں کرتا۔ اس لیے default value پر freeze کوئی memory reclaim نہیں کرتا، اور sandbox مکمل memory استعمال کرتا رہتا ہے۔ Project نے default value پر 0 bytes reclaimed اور 100 پر 99.5 percent reclaimed record کیا۔ Config files پڑھنے کے بجائے sysctl vm.swappiness سے effective value check کریں، کیونکہ کچھ cloud images value 0 کے ساتھ ship ہوتی ہیں۔