آموزش راه اندازی Dormice برای اجرای ایزوله کد عامل

Dormice چیست و چه چیزی نیست

Dormice یک sandbox عامل (agent) با قابلیت میزبانی شخصی (self-hosted) است: یک daemon روی یک VPS لینوکسی که مالک آن هستید و کد عامل شما از طریق HTTP آن را فراخوانی می‌کند تا کدهای غیرقابل‌اعتماد را درون یک container ایزوله اجرا کند. برنامه شما یک sandbox را با نام درخواست می‌کند، همان sandbox را با هر وضعیتی که داشته باشد تحویل می‌گیرد، دستوری را درون آن اجرا کرده و خروجی را می‌خواند. این sandbox یک منبع برنامه‌نویسی است، نه ماشینی که به آن SSH بزنید.

این مدل با در اختیار گذاشتن یک کامپیوتر کامل به یک عامل متفاوت است. یک ماشین مجازی یک‌بارمصرف برای عامل کدنویسی جعبه‌ای است که به آن SSH می‌زنید، اجازه می‌دهید عامل آن را تخریب کند و سپس آن را حذف می‌کنید. Dormice یک سطح پایین‌تر قرار دارد: این یک API اجرایی است که برنامه شما زمانی که کد را در اختیار دارد و به مکانی امن برای اجرای آن نیاز دارد، فراخوانی می‌کند. زمانی که یک ماشین کامل واحد کاری شماست، از ماشین مجازی یک‌بارمصرف استفاده کنید. زمانی که یک فراخوانی exec واحد کاری شماست و می‌خواهید روزانه صدها مورد از آن را بدون داشتن صدها ماشین مجازی انجام دهید، از Dormice استفاده کنید.

این پروژه خود را با E2B سازگار می‌داند. E2B یک سرویس sandbox میزبانی‌شده است که کتابخانه کلاینت آن توسط بسیاری از فریم‌ورک‌های عامل استفاده می‌شود. Dormice همان پروتکل را تحت پیشوندهای URL اختصاصی خود ارائه می‌دهد، بنابراین برنامه‌ای که برای پکیج رسمی e2b نوشته شده است، هنگام اشاره به سرور شخصی شما همچنان کار می‌کند. کد برنامه تغییری نمی‌کند. فقط دو URL و یک پیشوند API key تغییر می‌کنند.

معنای عملی «SQLite برای sandboxهای عامل» چیست

SQLite یک پایگاه‌داده است که آن را به جای سرویسی که مدیریت می‌کنید، در برنامه تعبیه (embed) می‌کنید؛ Dormice مستقیماً از همین مقایسه وام گرفته است. یک دیمون، یک فایل SQLite برای دفتر کل (ledger) و یک پورت TCP. نه خبری از Kubernetes است، نه پایگاه‌داده مجزا و نه زمان‌بند (scheduler). دیمون در کنار دفتر کل خود یک قفل ایجاد می‌کند و اگر تشخیص دهد که دفتر کل و ماشینی که روی آن اجرا شده با هم همخوانی ندارند، از اجرا خودداری می‌کند تا پدیده split brain به‌صورت بی‌سروصدا رخ ندهد. طراحی این ابزار برای یک ماشین واحد است. اگر به ناوگانی از ماشین‌ها در چندین میزبان نیاز دارید، فایل README صراحتاً به شما می‌گوید که گزینه دیگری انتخاب کنید و باید به این توصیه عمل کنید.

بخش دوم این ایده درباره هزینه است. یک sandbox میزبانی‌شده (hosted) برای هر ثانیه‌ای که وجود دارد هزینه دریافت می‌کند، بنابراین sandboxهای میزبانی‌شده ذاتاً یک‌بارمصرف هستند. Dormice روی سخت‌افزاری اجرا می‌شود که شما از قبل هزینه آن را پرداخت کرده‌اید، بنابراین sandboxهای آن دائمی هستند و هرچه بیشتر بدون استفاده بمانند، ارزان‌تر می‌شوند. یک sandbox مرحله‌به‌مرحله خنک می‌شود: فعال، سپس فریز شده، سپس متوقف و در نهایت آرشیو شده. هر عملیات acquire آن را از هر مرحله‌ای که به آن رسیده باشد، دوباره به حالت فعال بازمی‌گرداند.

فریز کردن بخشی است که ارزش درک کردن دارد، زیرا همان چیزی است که نگهداری دائمی sandbox هر عامل را مقرون‌به‌صرفه می‌کند. این‌ها ارقام منتشرشده توسط خود پروژه هستند که روی سخت‌افزار آن‌ها اندازه‌گیری شده‌اند، نه سخت‌افزار شما.

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

یک sandbox غیرفعال که 1024 مگابایت حافظه اشغال کرده است، پس از فریز شدن به 5 مگابایت حافظه مقیم (resident) کاهش می‌یابد و در حدود 50 میلی‌ثانیه دوباره به حالت قبل بازمی‌گردد. فرآیندها در همان وضعیت تعلیق و از سر گرفته می‌شوند، بنابراین یک عامل با طول عمر بالا، وضعیت shell و کارهای نیمه‌تمام خود را در طول فرآیند فریز حفظ می‌کند. پیش از برنامه‌ریزی برای ظرفیت سیستم خود، این مورد را روی میزبان خود بازتولید کنید.

پیش‌نیازهای میزبان برای نصب

میزبان باید Ubuntu یا Debian روی معماری x86_64 باشد و نصب‌کننده به دسترسی root نیاز دارد. Daemon در زمان اجرا دسترسی root را حفظ می‌کند، زیرا عملیات loop mount را انجام داده و در cgroups می‌نویسد.

سندباکس‌ها تحت Docker با استفاده از gVisor (یک container runtime که یک هسته در فضای کاربری بین کانتینر و هسته میزبان قرار می‌دهد) اجرا می‌شوند که runsc مورد استفاده هر سندباکس را فراهم می‌کند. Node 22 یا جدیدتر، daemon را اجرا می‌کند و نصب‌کننده نسخه اختصاصی خود را به همراه دارد، بنابراین Node سیستم شما دست‌نخورده باقی می‌ماند.

Swap باید وجود داشته باشد و مقدار vm.swappiness باید روی 100 تنظیم شود. این یک توصیه برای بهینه‌سازی نیست، بلکه یک الزام عملکردی است. فرآیند فریز کردن (freezing) با انتقال حافظه یک سندباکس بیکار به swap انجام می‌شود؛ gVisor حافظه سندباکس را به عنوان حافظه اشتراکی (shared memory) نگه می‌دارد و هسته در مقدار پیش‌فرض swappiness، حافظه اشتراکی را swap نمی‌کند. این پروژه اندازه‌گیری کرده است که در مقدار پیش‌فرض 0 بایت و در مقدار 100، حدود 99.5 درصد از حافظه بازیابی می‌شود. مقداری را که هسته واقعاً استفاده می‌کند بررسی کنید، زیرا برخی ایمیج‌های ابری vm.swappiness = 0 را در فایلی قرار می‌دهند که هرگز به فکر خواندن آن نخواهید افتاد.

sysctl vm.swappiness
swapon --show

دستور sysctl vm.swappiness باید مقدار vm.swappiness = 100 را چاپ کند و swapon --show باید یک swapfile را فهرست نماید. اگر swappiness مقدار 0 را نشان دهد، هر عملیات فریز کردن بی‌اثر خواهد بود و باعث می‌شود برای هر سندباکس بیکار، هزینه کامل حافظه را بپردازید.

نصب Dormice روی Ubuntu

روش نصب مستندشده، ارسال یک دستور به bash است:

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

پیش از اجرا، اسکریپت را دریافت و مطالعه کنید. این اسکریپت با دسترسی root اجرا شده و میزبان شما را بازآرایی می‌کند: اگر Docker نصب نباشد آن را نصب می‌کند، gVisor و Caddy را با بررسی checksum دانلود می‌کند، یک swapfile می‌سازد، unitهای 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 دانلودها را به mirrorهایی تغییر می‌دهد که از داخل چین در دسترس هستند. اجرای مجدد نصب‌کننده، کد را به‌روزرسانی کرده و انحرافات پیکربندی (drift) را اصلاح می‌کند، اما هرگز API token شما را تغییر نمی‌دهد.

کد در /opt/dormice، پیکربندی در /etc/dormice/env، داده‌های sandbox در /var/lib/dormice و دستورات dormice و dor در /usr/local/bin قرار می‌گیرند. نصب‌کننده در حین نصب، API token را تولید کرده و با مجوز 600 در /etc/dormice/env ذخیره می‌کند.

هیچ نسخه تگ‌شده‌ای برای نصب وجود ندارد. تا تاریخ 4 August 2026، مخزن فاقد git tag یا GitHub release است، بنابراین نصب‌کننده مخزن main را clone می‌کند و شما آخرین تغییرات همان روز را دریافت می‌کنید. بنابراین، برای ثابت نگه‌داشتن نسخه (pinning)، باید commitای که واقعاً نصب کرده‌اید را یادداشت کنید.

git -C /opt/dormice rev-parse HEAD

آن hash را در یادداشت‌های استقرار خود ذخیره کنید. هنگامی که یک به‌روزرسانی باعث بروز مشکل شود، آن commit تنها راه بازگشت شماست، زیرا هیچ شماره نسخه‌ای برای درخواست وجود ندارد.

نصب‌کننده در انتها dor doctor را اجرا می‌کند؛ یک بررسی‌کننده میزبان که فقط خواندنی است و containerهای واقعی 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 را روی سیستم قرار می‌دهد، بنابراین پیش از آنکه تصور کنید کار فایروال تمام شده است، بررسی کنید چه چیزی در حال گوش دادن (listening) است.

sudo ss -lntp

این daemon به 127.0.0.1:3676 متصل می‌شود و طبق طراحی، هیچ تنظیمی برای تغییر آن وجود ندارد. دسترسی به آن از لپ‌تاپ شما یک اقدام عمدی است و ارزان‌ترین روش، استفاده از SSH tunnel است.

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

با باز بودن tunnel، آدرس http://127.0.0.1:3676/console در لپ‌تاپ شما همان کنسول وب است. یک بار با token وارد شوید تا به یک session cookie از نوع httpOnly تبدیل شود؛ بنابراین token هرگز در جایی که صفحه وب بتواند آن را بخواند، ذخیره نمی‌شود. صفحه Connect در آنجا، قطعه‌کدهای کلاینت آماده برای کپی را نمایش می‌دهد که از قبل به endpoint اختصاصی شما اشاره دارند.

ایجاد یک sandbox و اجرای کد در آن

یک عملیات برای ایجاد sandbox وجود دارد: acquire. این عملیات idempotent است، بنابراین یک کلید مشخص همیشه sandbox یکسانی را برمی‌گرداند و بسته به نیاز، آن را ایجاد، بیدار، شروع یا بازیابی می‌کند. سایر دستورات برای کلیدی که قبلاً دیده نشده است، خطای 404 برمی‌گردانند. رابط خط فرمان dor فاقد دستور acquire است، بنابراین اولین sandbox شما باید از طریق کنسول یا یک کتابخانه کلاینت ایجاد شود.

مسیر کنسول سریع‌ترین روش است. /console را از طریق تونل باز کنید و یک sandbox با نام 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 هر sandbox را به همراه وضعیت چرخه حیات آن فهرست می‌کند؛ این همان روشی است که می‌توانید تغییر وضعیت آن از active به frozen را مشاهده کنید. دستور dor sandbox exec نسخه Python 3.12 را چاپ می‌کند، زیرا image پیش‌فرض، 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 از استریم استفاده می‌کند و تنها محدودیت آن، سهمیه دیسک sandbox است.

Destroying تنها دستوری است که باعث از دست رفتن داده‌ها می‌شود و همچنین نمونه مناسبی از قدمت پروژه است: فایل README اصلی و مهارت agent همراه آن، هر دو dor sandbox destroy <key> را مستند کرده‌اند، در حالی که README بسته CLI به dor sandbox release <key> اشاره دارد. دستور dor sandbox --help را روی build خود اجرا کنید و به آن اعتماد کنید.

هدایت کدهای موجود E2B به سمت سرور شخصی خود

این همان دلیلی است که باید به آن اهمیت دهید. بسته رسمی e2b از npm، بدون هیچ تغییری، با Dormice ارتباط برقرار می‌کند. این دستور را از روی لپ‌تاپ خود در حالی که تونل SSH باز است اجرا کنید تا هیچ سرویس جدیدی روی سرور شما گوش ندهد.

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_ به ابتدای آن اضافه شده است؛ این همان قالبی است که لایه سازگاری انتظار دارد.

این سازگاری یک پیاده‌سازی ناقص (stub) نیست. استریم کردن stdout و stderr، دستورات پس‌زمینه، PTY تعاملی، URLهای امضاشده برای آپلود و دانلود، نظارت بر دایرکتوری و پروکسی پورت، همگی از طریق بسته رسمی و در برابر یک Docker و gVisor واقعی توسط مجموعه تست‌های end-to-end پروژه بررسی می‌شوند. پیش از مهاجرت هر سرویس واقعی، به چند تفاوت توجه کنید:

• ساخت Templateها پیاده‌سازی نشده است. Template یک ایمیج داکر است که خودتان می‌سازید و با dor template add ثبت می‌کنید، و Sandbox.create('name') آن را شناسایی می‌کند. نام‌های ثبت‌نشده به جای شبیه‌سازی، خطای 404 برمی‌گردانند.
• Sandboxهایی که از طریق رابط E2B ایجاد می‌شوند دارای مهلت زمانی (deadline) واقعی هستند، زیرا قواعد E2B آن‌ها را الزامی می‌کند. هیچ مهلت زمانی برای Sandboxهایی که از طریق API بومی ایجاد می‌شوند، اعمال نمی‌شود.
• یک Sandbox منجمد (frozen)، پردازش‌های خود را حفظ کرده و آن‌ها را از همان نقطه میانی از سر می‌گیرد؛ بنابراین pause و resume در اینجا به معنای توقف و cold start که ممکن است به آن عادت داشته باشید، نیست.

محدودیت‌های sandbox و آنچه تحت پوشش آن نیست

ابزار gVisor فراخوانی‌های سیستم (system calls) کانتینر را در فضای کاربری (userspace) رهگیری کرده و خود به آن‌ها پاسخ می‌دهد؛ بنابراین کد موجود در sandbox مستقیماً با هسته (kernel) میزبان شما در ارتباط نیست. در داخل sandbox، همه چیز با یک کاربر بدون امتیاز (unprivileged) با uid 1000 اجرا می‌شود. این ترکیب، موارد معمول را مدیریت می‌کند: یک اسکریپت تولیدشده که rm -rf / را اجرا می‌کند، دیسک را پر می‌کند یا تا زمان از کار افتادن سیستم fork ایجاد می‌کند، تنها به sandbox خود آسیب می‌زند و در همان‌جا متوقف می‌شود.

در اینجا مواردی که توسط این ابزار متوقف نمی‌شوند ذکر شده است. مسئولیت هر یک از این موارد بر عهده شماست.

• یک sandbox دسترسی شبکه خروجی فعال دارد. کد تولیدشده می‌تواند هر چیزی را دانلود کرده و هر داده‌ای که می‌یابد را ارسال کند. سخت‌سازی شبکه در نصب‌کننده دو مورد خاص را پوشش می‌دهد: ترافیک کانتینر به سرویس متادیتای ابری در محدوده 169.254.0.0/16 را مسدود می‌کند (جایی که سرویس‌های ابری اعتبارنامه‌های instance را به هر چیزی که به آن دسترسی داشته باشد ارائه می‌دهند) و ترافیک بین کانتینرها را با "icc": false در daemon.json داکر غیرفعال می‌کند. هیچ چیز دیگری مسدود نمی‌شود. sudo iptables -S DOCKER-USER را مطالعه کنید و قوانین DROP اختصاصی خود را برای محدوده‌های خصوصی که sandbox نباید به آن‌ها دسترسی داشته باشد، اضافه کنید.
• داکر قوانین خود را پیش از فایروال شما اعمال می‌کند؛ بنابراین یک پورت کانتینر که منتشر (publish) شده باشد، می‌تواند از اینترنت پاسخ دهد، حتی اگر ufw اصرار داشته باشد که آن پورت بسته است. پیش از آنکه هر چیزی را روی این میزبان در معرض دید قرار دهید، نحوه انتشار پورت‌های داکر با عبور از ufw و اصول اولیه فایروال ufw برای VPS را مطالعه کنید.
• ابزار gVisor یک هسته در فضای کاربری است، نه یک hypervisor. این یک انتخاب آگاهانه است، زیرا قابلیت freezing مستلزم آن است که sandboxها به صورت process اجرا شوند و الزام به استفاده از KVM مانع از نصب آن در بسیاری از محیط‌ها می‌شد. اگر مدل تهدید شما نیازمند مجازی‌سازی سخت‌افزاری است، از ایزولاسیون در سطح Firecracker استفاده کنید و هزینه‌های عملیاتی آن را بپذیرید.
• توکن API تنها مرز امنیتی در سمت کلاینت است. هر چیزی که DORMICE_API_TOKEN را در اختیار داشته باشد، می‌تواند تمام sandboxهای موجود روی دستگاه را ایجاد، مشاهده یا نابود کند. برای فرآیند agent، یک کاربر با حداقل امتیاز روی VPS تعریف کنید و با توکن همانند یک کلید SSH رفتار کنید. عادت‌های ذکر شده در اجرای ایمن Claude Code روی VPS مستقیماً در اینجا نیز کاربرد دارند.

خود daemon با دسترسی root روی میزبان شما اجرا می‌شود. gVisor میزبان را در برابر کد داخل sandbox محافظت می‌کند، اما هیچ چیزی از میزبان در برابر خود daemon یا کسی که توکن آن را در اختیار دارد، محافظت نمی‌کند. بنابراین، دستگاهی که Dormice را اجرا می‌کند باید صرفاً به همین کار اختصاص داده شود. اگر agent شما از طریق MCP (پروتکل مدل کانتکست) به ابزارهای دیگر دسترسی دارد، به همان دلایل ذکر شده، آن سرورهای MCP را روی یک VPS جداگانه نگهداری کنید.

در 4 گیگابایت و 8 گیگابایت رم، چند sandbox جای می‌گیرد؟

دو عامل حافظه را مصرف می‌کنند: پایهٔ سیستم‌عامل میزبان و مجموعهٔ کاری (working set) هر sandbox که در حال حاضر فعال است. حدود 1 گیگابایت را برای Ubuntu، Docker و دیمون رزرو کنید، سپس باقی‌مانده را بر میزان مصرف واقعی یکی از sandboxهای خود تقسیم کنید. یک sandbox که اسکریپت پایتونی را اجرا می‌کند که چند فایل را می‌خواند، حدود 200 تا 300 مگابایت مصرف دارد. موردی که کامپایلر یا یک مجموعه تست کامل را اجرا می‌کند، ممکن است از یک گیبی‌بایت فراتر رود.

[
  {
    "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 گیگابایت رم می‌تواند 6 sandbox را به‌طور همزمان فعال نگه دارد، اگر هر کدام 512 مگابایت مصرف کنند، یا 3 اگر هر کدام یک گیبی‌بایت کامل مصرف کنند. یک VPS با 8 گیگابایت رم این تعداد را به 14 و 7 می‌رساند. این‌ها سقف‌های کاری همزمان هستند و محاسباتی‌اند، نه یک بنچمارک؛ بنابراین هنگام اجرای بار کاری خود، free -m را مانیتور کنید.

sandboxهای فریز شده (Frozen) به‌جای رم، توسط swap محدود می‌شوند که هدف اصلی این طراحی است. یک sandbox فریز شده که یک گیبی‌بایت را اشغال کرده بود، تقریباً همان مقدار را در swap نگه می‌دارد و تقریباً هیچ فضای residentای اشغال نمی‌کند؛ بنابراین فایل swap پیش‌فرض 16 گیگابایتی نصب‌کننده، حدود 16 از آن‌ها را در خود جای می‌دهد. فراتر از آن، آن‌ها باید به وضعیت متوقف (stopped) برسند که در آن فقط فضای دیسک را اشغال می‌کنند. در اینجا دیسک محدودیت واقعی در بلندمدت است: هر sandbox سیستم فایل خود را حفظ می‌کند و چند ده agent که هر کدام یک دایرکتوری node_modules دارند، یک حجم کوچک را بسیار زودتر از آنکه حافظه به چالش تبدیل شود، پر خواهند کرد.

توقف موقت، توقف کامل، آرشیو: تنظیمات چرخه حیات

مقادیر پیش‌فرض عبارتند از: توقف موقت (freeze) پس از 10 دقیقه بیکاری، توقف کامل (stop) پس از 3 روز، و آرشیو پس از 7 روز (در صورتی که آرشیو پیکربندی شده باشد). تنظیم stopAfterSeconds روی null باعث می‌شود یک agent مقیم (resident) داشته باشید: ممکن است هنگام بیکاری متوقف شود، اما هرگز cold start نخواهد داشت.

آرشیو کردن اختیاری است و daemon در این مورد شفاف عمل می‌کند. چهار متغیر DORMICE_S3_* را تنظیم کنید تا دیسک یک sandbox متوقف‌شده با tar و zstd فشرده‌سازی شود، به هر bucket سازگار با S3 ارسال گردد و فضای محلی آزاد شود. آن bucket می‌تواند یک bucket MinIO باشد که خودتان میزبانی می‌کنید و روی دستگاه دیگری از شما قرار دارد. اگر متغیرها را تنظیم‌نشده باقی بگذارید، sandboxها برای همیشه در وضعیت stopped باقی می‌مانند و هر سیاستی که درخواست آرشیو کند، به‌جای نادیده گرفته شدن بی‌سروصدا، رد می‌شود. بازیابی‌ها به‌جای سکوت، قابل مشاهده هستند: درخواست acquire بعدی بلافاصله با وضعیت restoring و یک مقدار progress پاسخ می‌دهد و پس از بازگشت دیسک، به وضعیت ready تغییر حالت می‌دهد.

آیا باید در حال حاضر به آن تکیه کرد؟

پاسخ صریح: خیر، برای هیچ چیزی که نتوانید دوباره آن را بازسازی کنید. اولین commit در این مخزن مربوط به تاریخ 8 July 2026 است. تا تاریخ 4 August 2026، این پروژه دارای 446 ستاره، 37 فورک، مجوز Apache-2.0 و فاقد هرگونه release برچسب‌گذاری‌شده است. در خط وضعیت فایل README نیز ذکر شده که هیچ بخشی از آن برای محیط production آماده نیست.

این ترکیب، نوع خاصی از ریسک را به همراه دارد. کدها دائماً در حال تغییر هستند، زیرا installer پروژه، main را دنبال می‌کند. رابط کاربری هنوز در حال تثبیت است؛ دقیقاً به همین دلیل است که فعل delete در دو فایل مختلف در یک مخزن، دو نام متفاوت دارد. همچنین پروژه‌ای که تنها چهار هفته از عمر آن می‌گذرد، ممکن است به سادگی متوقف شود، چرا که هیچ بند قانونی در مجوز پروژه، کسی را ملزم به ادامه توسعه نمی‌کند.

آنچه این ریسک را قابل‌تحمل می‌کند، سازگاری با E2B است. برنامه شما با پروتکلی صحبت می‌کند که یک پیاده‌سازی میزبانی‌شده (hosted) در پشت خود دارد؛ بنابراین اگر Dormice متوقف شد، کافی است دو URL را تغییر دهید و به کار خود ادامه دهید. عامل (agent) خود را بر اساس سطح دسترسی E2B بنویسید، نه API بومی (native)؛ با این کار راه خروج خود را حفظ خواهید کرد. بسته بومی @dormice/sdk نیز هنوز در npm قرار نگرفته است، بنابراین استفاده از آن مستلزم ساخت از روی مخزن است که این خود دلیل دومی برای شروع از طریق مسیر سازگار است.

آن را در جایی اجرا کنید که از دست رفتن آن برایتان هزینه‌ای نداشته باشد. میزبان را با استفاده از اسکریپت بازسازی کنید، توکن‌ها را از تمامی promptها و commitها دور نگه دارید و هر چیزی که ارزش نگهداری دارد را طبق برنامه پشتیبان‌گیری خود، از محیط‌های sandbox خارج کنید.

FAQ

آیا Dormice برای استفاده در محیط عملیاتی (production) آماده است؟

خیر، و خود پروژه نیز به این موضوع اشاره کرده است. وضعیت پروژه در فایل README بیان می‌کند که هیچ‌کدام از بخش‌ها هنوز برای محیط عملیاتی آماده نیستند. تا تاریخ 4 August 2026، این مخزن حدود چهار هفته قدمت دارد، هیچ git tag یا release رسمی برای آن منتشر نشده و بنابراین نسخه مشخصی برای ثابت نگه‌داشتن (pin) وجود ندارد. نصب‌کننده، شاخه main را کلون می‌کند، به این معنی که هر بار اجرا، جدیدترین commit را دریافت می‌کنید. پس از هر بار نصب، رکورد git -C /opt/dormice rev-parse HEAD را ثبت کنید و هر دادهٔ ارزشمندی را خارج از sandboxها نگهداری کنید.

تفاوت Dormice با اختصاص یک VM یک‌بارمصرف به agent من چیست؟

یک VM یک‌بارمصرف، ماشینی با دسترسی SSH است که برای یک نشست (session) ایجاد و پس از آن حذف می‌شود. Dormice یک API برای اجرا است: برنامهٔ شما دستور acquire و سپس exec را فراخوانی می‌کند و خروجی استاندارد (stdout) و کد خروج (exit code) را دریافت می‌کند، بدون آنکه نشست shell در میان باشد. VM برای انسان یا agentای مناسب است که برای مدتی به یک کامپیوتر کامل نیاز دارد. Dormice برای برنامه‌ای مناسب است که کدهای تولیدشده را چندین بار در روز اجرا می‌کند و نمی‌خواهد برای هر اجرا درگیر راه‌اندازی و حذف یک ماشین کامل شود.

آیا SDK رسمی E2B واقعاً بدون تغییر کد کار می‌کند؟

بله، با اعمال تغییرات در پیکربندی. apiUrl و sandboxUrl را به سمت /e2b/api و /e2b/envd روی daemon خود هدایت کنید و توکن Dormice خود را با پیشوند e2b_ به عنوان API key ارسال کنید. اجرای دستورات، نشست‌های PTY، انتقال فایل، URLهای امضاشده و port proxy همگی توسط مجموعه تست‌های end-to-end پروژه که از طریق پکیج رسمی اجرا می‌شوند، پوشش داده شده‌اند. ساخت قالب (template) تنها شکاف قابل‌توجه است: e2b template build پیاده‌سازی نشده است، بنابراین قالب در واقع یک docker image است که شما می‌سازید و با dor template add ثبت می‌کنید.

روی یک VPS با 4 GB رم، چند sandbox جای می‌گیرد؟

اگر هر sandbox از 512 MiB رم استفاده کند، حدود 6 sandbox همزمان فعال، و اگر هر کدام از یک گیبی‌بایت کامل استفاده کنند، 3 sandbox جای می‌گیرد؛ این محاسبات پس از رزرو حدود 1 GB رم برای سیستم‌عامل، Docker و daemon انجام شده است. محدودیت sandboxهای فریز شده (frozen) توسط swap تعیین می‌شود، بنابراین فایل swap پیش‌فرض 16 GB در نصب‌کننده، می‌تواند حدود 16 sandbox که هر کدام یک گیبی‌بایت اشغال کرده‌اند را میزبانی کند. ظرفیت خود را با free -m تحت بار واقعی بسنجید، زیرا sandboxای که یک مجموعه تست را اجرا می‌کند، چندین برابر بیشتر از sandboxای که یک اسکریپت کوچک را اجرا می‌کند، منابع مصرف می‌کند.

چرا Dormice نیاز دارد که vm.swappiness روی 100 تنظیم شود؟

فریز کردن یک sandbox به معنای انتقال حافظهٔ غیرفعال آن به swap است. gVisor حافظهٔ sandbox را به صورت حافظهٔ اشتراکی (shared memory) نگه می‌دارد و هستهٔ Linux در حالت swappiness پیش‌فرض، حافظهٔ اشتراکی را swap نمی‌کند. بنابراین در حالت پیش‌فرض، فریز کردن هیچ حافظه‌ای را آزاد نمی‌کند و sandbox همچنان تمام حافظه را اشغال می‌کند. این پروژه اندازه‌گیری کرده است که در حالت پیش‌فرض 0 بایت و در حالت 100، حدود 99.5 درصد حافظه آزاد می‌شود. مقدار مؤثر را به جای خواندن فایل‌های پیکربندی، با sysctl vm.swappiness بررسی کنید، زیرا برخی imageهای ابری مقدار 0 را به صورت پیش‌فرض دارند.