নিজের VPS-এ Dormice দিয়ে agent sandbox তৈরি করার নিয়ম

Dormice কী এবং কী নয়

Dormice হলো একটি self-hosted agent sandbox: এটি আপনার নিজস্ব Linux VPS-এ চলমান একটি daemon, যা আপনার agent code-এর HTTP অনুরোধের মাধ্যমে অনিরাপদ (untrusted) কোডকে একটি isolated container-এর ভেতরে চালায়। আপনার প্রোগ্রাম নাম ধরে sandbox-এর অনুরোধ করে, আগের যেকোনো অবস্থায় থাকা সেই একই sandbox ফিরে পায়, তার ভেতরে একটি কমান্ড চালায় এবং আউটপুট পড়ে। এই sandbox একটি programmatic resource, এটি এমন কোনো মেশিন নয় যেখানে আপনি লগ-ইন করবেন।

এটি একটি agent-কে পুরো কম্পিউটার দেওয়ার চেয়ে ভিন্ন। একটি coding agent-এর জন্য throwaway VM হলো এমন একটি বক্স যেখানে আপনি SSH করেন, agent-কে সেটি নষ্ট করতে দেন, তারপর মুছে ফেলেন। Dormice এক ধাপ নিচে অবস্থান করে: এটি একটি execution API, যা আপনার প্রোগ্রাম তখন কল করে যখন তার হাতে কোড থাকে এবং সেটি চালানোর জন্য একটি নিরাপদ জায়গা প্রয়োজন হয়। যখন কাজের একক হিসেবে একটি পুরো মেশিনের প্রয়োজন হয়, তখন throwaway VM ব্যবহার করুন। যখন কাজের একক হিসেবে একটি মাত্র exec কল প্রয়োজন হয় এবং আপনি প্রতিদিন শত শত VM তৈরি না করেই তা করতে চান, তখন Dormice ব্যবহার করুন।

এই প্রজেক্টটি নিজেকে E2B compatible বলে দাবি করে। E2B হলো একটি hosted sandbox service, যার client library অনেক agent framework ইতিমধ্যে import করে থাকে। Dormice নিজস্ব URL prefix-এর অধীনে একই protocol প্রদান করে, তাই অফিসিয়াল e2b package ব্যবহার করে লেখা কোনো application আপনার নিজস্ব বক্সে পয়েন্ট করলে তা সচল থাকে। application code-এর কোনো পরিবর্তন করতে হয় না। শুধু দুটি URL এবং একটি API key prefix পরিবর্তন করতে হয়।

"এজেন্ট স্যান্ডবক্সের SQLite" বলতে বাস্তবে কী বোঝায়

SQLite হলো এমন একটি ডাটাবেস যা আপনি কোনো সার্ভিস হিসেবে পরিচালনা করার পরিবর্তে সরাসরি অ্যাপ্লিকেশনের ভেতরে এমবেড (embed) করেন, আর Dormice এই তুলনাটি সরাসরি গ্রহণ করেছে। একটি ডেমোন (daemon), লেজারের জন্য একটি SQLite ফাইল এবং একটি TCP পোর্ট। কোনো Kubernetes নেই, আলাদা কোনো ডাটাবেস নেই, কোনো শিডিউলার নেই। ডেমোনটি তার লেজারের পাশে একটি লক তৈরি করে এবং যখন লেজার ও মেশিন একে অপরের সাথে সামঞ্জস্যপূর্ণ হয় না, তখন এটি চালু হতে অস্বীকার করে; ফলে নীরবে কোনো স্প্লিট-ব্রেইন (split brain) ঘটার সুযোগ থাকে না। একটি মেশিনই এর মূল ডিজাইন। যদি আপনার অনেকগুলো হোস্ট জুড়ে একটি ফ্লিট (fleet) প্রয়োজন হয়, তবে README ফাইলটি আপনাকে স্পষ্টভাবে অন্য কিছু বেছে নিতে বলে, এবং আপনার সেই পরামর্শ শোনা উচিত।

এই ধারণার দ্বিতীয় অংশটি খরচ সম্পর্কিত। একটি হোস্ট করা স্যান্ডবক্স প্রতি সেকেন্ডের জন্য বিল করে, তাই হোস্ট করা স্যান্ডবক্সগুলো ডিজাইনের দিক থেকেই ক্ষণস্থায়ী। Dormice আপনার কেনা হার্ডওয়্যারে চলে, তাই এর স্যান্ডবক্সগুলো স্থায়ী এবং যত বেশি সময় এগুলো অলস অবস্থায় থাকে, খরচ তত কমতে থাকে। একটি স্যান্ডবক্স ধাপে ধাপে শীতল হয়: active, তারপর frozen, তারপর stopped, এবং সবশেষে archived। যেকোনো 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 রেসিডেন্ট মেমরিতে নেমে আসে এবং প্রায় 50 ms সময়ের মধ্যে পুনরায় সচল হয়। প্রসেসগুলো যেখানে ছিল সেখানেই স্থগিত (suspend) এবং পুনরায় শুরু (resume) হয়, তাই দীর্ঘস্থায়ী একটি এজেন্ট ফ্রিজ হওয়ার পরেও তার শেল স্টেট এবং অসম্পূর্ণ কাজগুলো ধরে রাখতে পারে। এর ওপর ভিত্তি করে সক্ষমতা (capacity) পরিকল্পনা করার আগে আপনার নিজের হোস্টে এটি যাচাই করে নিন।

ইনস্টলেশনের আগে হোস্টের যা প্রয়োজন

হোস্টটি অবশ্যই x86_64 আর্কিটেকচারের Ubuntu বা Debian হতে হবে এবং ইনস্টলারের জন্য root প্রিভিলেজ প্রয়োজন। daemon-টি রানটাইমে root হিসেবেই থাকে, কারণ এটি loop mount পরিচালনা করে এবং cgroups-এ রাইট করে।

স্যান্ডবক্সগুলো Docker এবং gVisor-এর অধীনে চলে (এটি একটি কন্টেইনার রানটাইম যা কন্টেইনার এবং হোস্ট কার্নেলের মাঝে একটি ইউজারস্পেস কার্নেল স্থাপন করে), যা প্রতিটি স্যান্ডবক্সের জন্য runsc রানটাইম সরবরাহ করে। daemon চালানোর জন্য Node 22 বা তার চেয়ে নতুন সংস্করণ প্রয়োজন। ইনস্টলার তার নিজস্ব কপি নিয়ে আসে, তাই আপনার সিস্টেমের Node-এ কোনো পরিবর্তন হয় না।

সিস্টেমে অবশ্যই swap থাকতে হবে এবং vm.swappiness এর মান 100 হতে হবে। এটি কোনো টিউনিং পরামর্শ নয়, বরং একটি কার্যকরী প্রয়োজনীয়তা। কোনো idle স্যান্ডবক্সের মেমোরিকে swap-এ পাঠিয়েই মূলত ফ্রিজিং কাজ করে। gVisor স্যান্ডবক্সের মেমোরিকে shared memory হিসেবে ধরে রাখে এবং ডিফল্ট swappiness মানে কার্নেল shared memory সোয়াপ করে না। প্রজেক্টের পরীক্ষায় দেখা গেছে, ডিফল্ট মানে 0 বাইট মেমোরি রিক্লেইম হয়, কিন্তু 100 মানে 99.5 শতাংশ রিক্লেইম হয়। কার্নেল বর্তমানে কোন মান ব্যবহার করছে তা যাচাই করুন, কারণ কিছু ক্লাউড ইমেজে vm.swappiness = 0 এমন একটি ফাইলে থাকে যা আপনি হয়তো কখনোই চেক করবেন না।

sysctl vm.swappiness
swapon --show

sysctl vm.swappiness কমান্ডটি চালালে vm.swappiness = 100 আউটপুট আসা উচিত এবং swapon --show কমান্ডে একটি swapfile তালিকাভুক্ত থাকা উচিত। যদি swappiness-এর মান 0 দেখায়, তবে প্রতিটি ফ্রিজ অপারেশন কোনো কাজ করবে না এবং প্রতিটি idle স্যান্ডবক্সের জন্য আপনাকে পূর্ণ মেমোরির খরচ বহন করতে হবে।

Ubuntu-তে Dormice ইনস্টল করা

নথিভুক্ত ইনস্টলেশন পদ্ধতিটি একটি পাইপের মাধ্যমে bash-এ সম্পন্ন হয়:

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

এটি চালানোর আগে স্ক্রিপ্টটি ডাউনলোড করে পড়ে নিন। এই স্ক্রিপ্টটি root হিসেবে চলে এবং আপনার হোস্টের কনফিগারেশন পরিবর্তন করে: এটি Docker না থাকলে ইনস্টল করে, checksum যাচাই করে gVisor ও Caddy ডাউনলোড করে, একটি swapfile তৈরি করে, systemd unit লেখে এবং 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 ব্যবহার করলে ডাউনলোডগুলো মেইনল্যান্ড চীন থেকে অ্যাক্সেসযোগ্য মিরর থেকে সম্পন্ন হয়। ইনস্টলারটি পুনরায় চালালে কোড আপগ্রেড হয় এবং কনফিগারেশনের অসামঞ্জস্যতা ঠিক হয়, তবে এটি কখনোই আপনার API token পরিবর্তন করে না।

কোড /opt/dormice-এ, কনফিগারেশন /etc/dormice/env-এ, স্যান্ডবক্স ডেটা /var/lib/dormice-এ এবং dormice ও dor কমান্ডগুলো /usr/local/bin-এ থাকে। ইনস্টলারটি ইনস্টলেশনের সময় API token তৈরি করে এবং এটিকে 600 মোডে /etc/dormice/env ফাইলে লিখে রাখে।

ইনস্টল করার জন্য কোনো নির্দিষ্ট tagged release নেই। 4 আগস্ট 2026 পর্যন্ত রিপোজিটরিতে কোনো git tag বা GitHub release নেই, তাই ইনস্টলারটি main ক্লোন করে এবং আপনি সেই সকালে যা আপডেট হয়েছে তা-ই পাবেন। তাই কোনো ভার্সন নির্দিষ্ট (pin) করতে চাইলে আপনাকে সেই নির্দিষ্ট commit-টি লিখে রাখতে হবে যা আপনি ইনস্টল করেছেন।

git -C /opt/dormice rev-parse HEAD

আপনার ডেপ্লয়মেন্ট নোটের সাথে সেই hash-টি সংরক্ষণ করুন। যখন কোনো আপগ্রেড সমস্যা তৈরি করবে, তখন সেই commit-ই হবে আপনার ফিরে যাওয়ার একমাত্র উপায়, কারণ অনুরোধ করার মতো কোনো ভার্সন নম্বর নেই।

ইনস্টলারটি শেষে dor doctor চালায়, যা একটি read-only হোস্ট চেক। এটি প্যাকেজ তালিকার ওপর নির্ভর না করে বাস্তবে gVisor কন্টেইনার চালু করে যাচাই করে যে runtime কাজ করছে কি না। daemon ঠিকমতো কাজ না করলে এটি আবার চালান।

sudo dor doctor
systemctl is-active dormice

systemctl is-active dormice কমান্ডটি active আউটপুট দেওয়া উচিত। যদি এটি failed দেখায়, তবে journalctl -u dormice -n 50 ফাইলে কারণটি পাওয়া যাবে। সাধারণত daemon-এর চেয়ে swap বা gVisor-এর প্রয়োজনীয় শর্ত পূরণ না হওয়ার কারণেই স্টার্ট ব্যর্থ হয়।

ইনস্টলারটি বক্সে Caddy-ও ইনস্টল করে, তাই firewall-এর কাজ শেষ মনে করার আগে দেখে নিন কোন পোর্টগুলো listening অবস্থায় আছে।

sudo ss -lntp

daemon-টি 127.0.0.1:3676-এ bind হয় এবং ডিজাইনের কারণেই এটি পরিবর্তন করার কোনো সেটিং নেই। আপনার ল্যাপটপ থেকে এটি অ্যাক্সেস করা একটি সচেতন কাজ এবং এর সহজ উপায় হলো SSH tunnel ব্যবহার করা।

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

tunnel খোলা থাকলে, আপনার ল্যাপটপে http://127.0.0.1:3676/console হলো ওয়েব কনসোল। একবার token দিয়ে সাইন ইন করলে এটি একটি httpOnly session cookie হিসেবে জমা হয়, তাই token-টি এমন কোথাও সংরক্ষিত থাকে না যেখান থেকে পেজটি তা পড়তে পারে। সেখানকার Connect পেজে কপি-পেস্ট করার উপযোগী ক্লায়েন্ট স্নিপেট থাকে যা সরাসরি আপনার এন্ডপয়েন্টের দিকে নির্দেশ করা থাকে।

একটি স্যান্ডবক্স তৈরি করুন এবং তাতে কোড চালান

একটি অপারেশন স্যান্ডবক্স তৈরি করে: acquire। এটি একটি আইডেমপোটেন্ট (idempotent) অপারেশন, তাই একই কী (key) সবসময় একই স্যান্ডবক্স প্রদান করে; প্রয়োজনে এটি স্যান্ডবক্স তৈরি করে, সজাগ করে, চালু করে বা রিস্টোর করে। অন্য যেকোনো ভার্ব (verb) এমন কোনো কী-এর জন্য 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 আগে থেকেই ইনস্টল করা থাকে। যদি একটি অথেন্টিকেশন এরর (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 tunnel খোলা থাকা অবস্থায় আপনার ল্যাপটপ থেকে এটি চালান, যাতে সার্ভারে নতুন কোনো কিছু 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 token, যার শুরুতে একটি e2b_ prefix যুক্ত থাকবে; compatibility layer এই ফরম্যাটটিই প্রত্যাশা করে।

এই compatibility কোনো stub নয়। অফিসিয়াল প্যাকেজের মাধ্যমে একটি প্রকৃত Docker এবং gVisor daemon-এর বিপরীতে প্রজেক্টের end-to-end suite ব্যবহার করে stdout ও stderr স্ট্রিমিং, background commands, একটি interactive PTY, signed upload ও download URL, directory watching এবং একটি port proxy-এর কার্যকারিতা যাচাই করা হয়। কোনো গুরুত্বপূর্ণ কাজ মাইগ্রেট করার আগে নিচের পার্থক্যগুলো জেনে রাখা জরুরি:

• Template build-এর সুবিধা এখানে নেই। একটি template হলো এমন একটি docker image যা আপনি নিজে তৈরি করেন এবং dor template add দিয়ে register করেন, আর Sandbox.create('name') সেটিকে resolve করে। কোনো unregistered নাম ব্যবহার করলে এটি কোনো ভান না করে সরাসরি 404 error প্রদান করে।
• E2B ইন্টারফেসের মাধ্যমে তৈরি করা sandbox-গুলোর জন্য নির্দিষ্ট সময়সীমা (deadlines) থাকে, কারণ E2B-এর নিয়ম অনুযায়ী এটি প্রয়োজন। কিন্তু native API-এর মাধ্যমে তৈরি করা sandbox-এ কোনো সময়সীমা আরোপ করা হয় না।
• একটি frozen sandbox তার প্রসেসগুলোকে ধরে রাখে এবং মাঝপথ থেকেই পুনরায় শুরু করে। তাই এখানে pause এবং resume মানে আপনার পরিচিত stop এবং cold start নয়।

স্যান্ডবক্স যা আটকায় এবং যা আটকায় না

gVisor কন্টেইনারের সিস্টেম কলগুলোকে ইউজারস্পেসে ইন্টারসেপ্ট করে এবং নিজেই সেগুলো সম্পন্ন করে, তাই স্যান্ডবক্সের ভেতরের কোড সরাসরি আপনার হোস্ট কার্নেলের সাথে যোগাযোগ করতে পারে না। স্যান্ডবক্সের ভেতরে সবকিছু একটি আনপ্রিভিলেজড ইউজার, uid 1000 হিসেবে চলে। এই সমন্বয়টি সাধারণ পরিস্থিতিগুলো সামাল দেয়: একটি জেনারেটেড স্ক্রিপ্ট যা rm -rf / চালায়, ডিস্ক পূর্ণ করে ফেলে, অথবা কোনো কিছু ক্র্যাশ না করা পর্যন্ত ফর্ক (fork) করতে থাকে, তা কেবল নিজের স্যান্ডবক্সের ক্ষতি করে এবং সেখানেই থেমে যায়।

নিচে দেওয়া বিষয়গুলো এটি আটকায় না। এগুলো আপনার দায়িত্ব।

• একটি স্যান্ডবক্সের আউটবাউন্ড নেটওয়ার্ক সচল থাকে। জেনারেটেড কোড যেকোনো কিছু ডাউনলোড করতে পারে এবং যা খুঁজে পায় তা পোস্ট করতে পারে। ইন্সটলারের নেটওয়ার্ক হার্ডেনিং দুটি নির্দিষ্ট বিষয় কভার করে: এটি 169.254.0.0/16 এ ক্লাউড মেটাডেটা সার্ভিসের দিকে কন্টেইনারের ট্রাফিক ড্রপ করে, যেখানে ক্লাউড ইনস্ট্যান্সের ক্রেডেনশিয়াল থাকে, এবং এটি ডকারের daemon.json-এ "icc": false ব্যবহার করে কন্টেইনার-টু-কন্টেইনার ট্রাফিক বন্ধ করে দেয়। অন্য কিছু ব্লক করা হয় না। sudo iptables -S DOCKER-USER পড়ুন এবং প্রাইভেট রেঞ্জগুলোর জন্য আপনার নিজস্ব DROP রুল যোগ করুন যেখানে স্যান্ডবক্সের যাওয়ার কোনো প্রয়োজন নেই।
• ডকার আপনার ফায়ারওয়ালের আগেই নিজস্ব রুল ইনসার্ট করে, তাই একটি পাবলিশড কন্টেইনার পোর্ট ইন্টারনেট থেকে রেসপন্স করতে পারে, যদিও ufw দাবি করে যে সেটি বন্ধ আছে। কোনো কিছু হোস্ট করার আগে কিভাবে ডকার ufw-এর বাইরে পোর্ট পাবলিশ করে এবং একটি VPS-এর জন্য ufw ফায়ারওয়ালের মৌলিক বিষয়গুলো পড়ুন।
• gVisor একটি ইউজারস্পেস কার্নেল, হাইপারভাইজার নয়। এটি একটি সচেতন সিদ্ধান্ত, কারণ ফ্রিজিং করার জন্য স্যান্ডবক্সগুলোকে প্রসেস হতে হয় এবং KVM-এর প্রয়োজনীয়তা থাকলে তা যেকোনো জায়গায় ইন্সটল করা সম্ভব হতো না। যদি আপনার থ্রেট মডেল হার্ডওয়্যার ভার্চুয়ালাইজেশন দাবি করে, তবে Firecracker-ক্লাস আইসোলেশন ব্যবহার করুন এবং এর সাথে আসা অপারেশনাল খরচ মেনে নিন।
• ক্লায়েন্ট সাইডে API টোকেনই হলো নিরাপত্তার একমাত্র সীমানা। যার কাছে DORMICE_API_TOKEN আছে, সে মেশিনের প্রতিটি স্যান্ডবক্স তৈরি, পড়তে এবং ধ্বংস করতে পারে। এজেন্ট প্রসেসটিকে তার নিজস্ব VPS-এ ন্যূনতম প্রিভিলেজড ইউজার দিন এবং টোকেনটিকে SSH কী-এর মতো গুরুত্ব দিন। একটি VPS-এ নিরাপদে Claude Code চালানো থেকে শেখা অভ্যাসগুলো এখানে সরাসরি কাজে লাগবে।

ডেমনটি নিজে আপনার হোস্টে root হিসেবে চলে। gVisor হোস্টকে স্যান্ডবক্সের ভেতরের কোড থেকে রক্ষা করে, কিন্তু ডেমন বা যার কাছে টোকেন আছে তার হাত থেকে হোস্টকে রক্ষা করার কিছু নেই। তাই Dormice যে মেশিনে চলবে, সেই মেশিনে অন্য কোনো কাজ করা উচিত নয়। যদি আপনার এজেন্ট MCP (model context protocol)-এর মাধ্যমে টুলস ব্যবহার করে, তবে একই কারণে সেই MCP সার্ভারগুলোকে আলাদা একটি VPS-এ রাখুন।

4 GB এবং 8 GB র‍্যামে কয়টি স্যান্ডবক্স চালানো সম্ভব?

মেমরি মূলত দুটি জিনিসের ওপর নির্ভর করে: হোস্টের নিজস্ব বেসলাইন এবং বর্তমানে সচল প্রতিটি স্যান্ডবক্সের ওয়ার্কিং সেট। Ubuntu, Docker এবং ডেমনের জন্য প্রায় 1 GB মেমরি আলাদা রাখুন। এরপর অবশিষ্ট মেমরিকে একটি স্যান্ডবক্সের প্রকৃত ব্যবহারযোগ্য মেমরি দিয়ে ভাগ করুন। একটি পাইথন স্ক্রিপ্ট যা কয়েকটি ফাইল পড়ে, সেটি সাধারণত 200 থেকে 300 MiB মেমরি ব্যবহার করে। কিন্তু একটি কম্পাইলার বা পূর্ণাঙ্গ টেস্ট স্যুট চললে তা এক গিবিবাইট (GiB) ছাড়িয়ে যেতে পারে।

[
  {
    "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 টি স্যান্ডবক্স সচল রাখা সম্ভব যদি প্রতিটি এক গিবিবাইট মেমরি ব্যবহার করে। 8 GB VPS-এর ক্ষেত্রে এই সংখ্যা যথাক্রমে 14 এবং 7। এগুলো মূলত সমসাময়িক কাজের সর্বোচ্চ সীমা এবং এটি একটি গাণিতিক হিসাব, কোনো বেঞ্চমার্ক নয়। তাই আপনার নিজস্ব লোড চলার সময় free -m মনিটর করুন।

ফ্রোজেন (frozen) স্যান্ডবক্সগুলো র‍্যামের পরিবর্তে সোয়াপ (swap) দ্বারা সীমাবদ্ধ, যা এই ডিজাইনের মূল উদ্দেশ্য। একটি ফ্রোজেন স্যান্ডবক্স যা এক গিবিবাইট মেমরি দখল করে ছিল, তা সোয়াপে প্রায় সমপরিমাণ জায়গা নেয় এবং র‍্যামে প্রায় কিছুই রাখে না। তাই ইনস্টলারের ডিফল্ট 16 GB সোয়াপফাইল প্রায় 16 টি স্যান্ডবক্স ধরে রাখতে পারে। এর চেয়ে বেশি স্যান্ডবক্স হলে সেগুলোকে 'stopped' অবস্থায় রাখতে হবে, যেখানে সেগুলো শুধুমাত্র ডিস্কের জায়গা দখল করে। দীর্ঘমেয়াদে ডিস্কের ধারণক্ষমতাই এখানে আসল সীমাবদ্ধতা: প্রতিটি স্যান্ডবক্স তার নিজস্ব ফাইলসিস্টেম বজায় রাখে এবং কয়েক ডজন এজেন্ট, যার প্রতিটিতে একটি করে node_modules ডিরেক্টরি থাকে, তা মেমরি সমস্যার আগেই একটি ছোট ভলিউম পূর্ণ করে ফেলতে পারে।

Freeze, stop, archive: the lifecycle knobs

ডিফল্ট সেটিংস অনুযায়ী, 10 মিনিট নিষ্ক্রিয় থাকলে sandbox freeze হয়, 3 দিন পর stop হয় এবং archiving কনফিগার করা থাকলে 7 দিন পর archive হয়। stopAfterSeconds-কে null সেট করলে আপনি একটি resident agent পাবেন: এটি নিষ্ক্রিয় অবস্থায় freeze হতে পারে, কিন্তু কখনোই cold start হয় না।

Archiving ঐচ্ছিক এবং daemon এ বিষয়ে স্বচ্ছ। চারটি DORMICE_S3_* ভেরিয়েবল সেট করলে একটি stopped sandbox-এর ডিস্ক tar এবং zstd দিয়ে প্যাক করা হয়, যেকোনো S3-compatible বাকেটে পাঠানো হয় এবং লোকাল স্টোরেজ থেকে মুছে ফেলা হয়। সেই বাকেটটি হতে পারে আপনার নিজের হোস্ট করা একটি MinIO bucket যা অন্য কোনো মেশিনে রয়েছে। ভেরিয়েবলগুলো সেট না করলে sandbox চিরকাল stopped অবস্থায় থাকবে এবং archive করার কোনো পলিসি অনুরোধ করা হলে তা নীরবে উপেক্ষা না করে সরাসরি প্রত্যাখ্যান করা হবে। Restore প্রক্রিয়াটি নীরবে না হয়ে দৃশ্যমান হয়: পরবর্তী acquire অনুরোধে তাৎক্ষণিকভাবে একটি restoring স্ট্যাটাস এবং progress ভ্যালু দেখা যায়, এবং ডিস্ক ফিরে আসার পর তা ready অবস্থায় চলে আসে।

এটি কি এখনই ব্যবহার করা উচিত?

সরাসরি উত্তর: এমন কোনো কাজে এটি ব্যবহার করবেন না যা আপনি পুনরায় তৈরি করতে পারবেন না। রিপোজিটরির প্রথম কমিটটি 8 জুলাই 2026 তারিখের। 4 আগস্ট 2026 পর্যন্ত এতে 446টি স্টার, 37টি ফর্ক, একটি Apache-2.0 লাইসেন্স রয়েছে এবং কোনো tagged release নেই। README ফাইলের স্ট্যাটাস লাইন অনুযায়ী, এর কোনো কিছুই প্রোডাকশনের জন্য প্রস্তুত নয়।

এই সংমিশ্রণটি এক বিশেষ ধরনের ঝুঁকির সৃষ্টি করে। কোডটি প্রতিনিয়ত পরিবর্তিত হচ্ছে, কারণ ইনস্টলারটি main ট্র্যাক করে। ইন্টারফেসটি এখনও স্থিতিশীল নয়, যার কারণেই একই রিপোজিটরির দুটি ভিন্ন ফাইলে 'delete' ভার্বটির দুটি আলাদা নাম রয়েছে। চার সপ্তাহ বয়সী একটি প্রজেক্ট যেকোনো সময় বন্ধ হয়ে যেতে পারে, কারণ কোনো লাইসেন্স শর্ত কাউকে এটি চালিয়ে যেতে বাধ্য করে না।

এই ঝুঁকিটি মেনে নেওয়ার মতো হওয়ার কারণ হলো E2B সামঞ্জস্যতা। আপনার অ্যাপ্লিকেশনটি এমন একটি প্রোটোকলের সাথে যোগাযোগ করে যার পেছনে একটি hosted implementation রয়েছে। তাই যদি Dormice থমকে যায়, তবে আপনি কেবল দুটি URL পরিবর্তন করেই কাজ চালিয়ে যেতে পারবেন। আপনার এজেন্টকে native API-এর পরিবর্তে E2B ইন্টারফেসের বিপরীতে তৈরি করুন, এতে আপনি একটি এক্সিট পয়েন্ট পাবেন। native @dormice/sdk প্যাকেজটি এখনও npm-এ নেই, তাই এটি ব্যবহার করার অর্থ হলো রিপোজিটরি থেকে বিল্ড করা, যা সামঞ্জস্যপূর্ণ পথে শুরু করার দ্বিতীয় কারণ।

এটি এমন জায়গায় চালান যেখানে এটি হারিয়ে গেলেও আপনার কোনো সমস্যা নেই। স্ক্রিপ্ট থেকে হোস্টটি পুনরায় তৈরি করার ব্যবস্থা রাখুন, প্রতিটি প্রম্পট এবং কমিট থেকে টোকেনটি দূরে রাখুন এবং আপনার নিজস্ব ব্যাকআপ শিডিউল অনুযায়ী স্যান্ডবক্স থেকে প্রয়োজনীয় সবকিছু সরিয়ে নিন।

FAQ

Dormice কি প্রোডাকশন ব্যবহারের জন্য প্রস্তুত?

না, এবং প্রজেক্টটি নিজেই এটি উল্লেখ করেছে। README-এর স্ট্যাটাস লাইনে বলা হয়েছে যে এর কোনো কিছুই এখনো প্রোডাকশনের জন্য প্রস্তুত নয়। 4 আগস্ট 2026 তারিখ পর্যন্ত রিপোজিটরিটির বয়স মাত্র চার সপ্তাহ, এতে কোনো git tag বা release নেই, তাই পিন করার মতো কোনো ভার্সন নম্বরও নেই। ইনস্টলারটি main ব্রাঞ্চ ক্লোন করে, যার অর্থ প্রতিবার চালানোর সময় আপনি নতুন কমিটটি পাবেন। প্রতিটি ইনস্টলের পর git -C /opt/dormice rev-parse HEAD রেকর্ড করুন এবং মূল্যবান যেকোনো কিছু স্যান্ডবক্সের বাইরে রাখুন।

আমার এজেন্টকে একটি ডিসপোজেবল VM দেওয়ার চেয়ে Dormice কীভাবে আলাদা?

একটি ডিসপোজেবল VM হলো SSH সহ এমন একটি মেশিন যা আপনি একটি সেশনের জন্য তৈরি করেন এবং পরে মুছে ফেলেন। Dormice হলো একটি এক্সিকিউশন API: আপনার প্রোগ্রাম acquire এবং তারপর exec কল করে, এবং মাঝখানে কোনো শেল সেশন ছাড়াই stdout ও একটি exit code ফেরত পায়। VM এমন কোনো মানুষ বা এজেন্টের জন্য উপযুক্ত যারা কিছু সময়ের জন্য একটি পূর্ণাঙ্গ কম্পিউটার চায়। Dormice এমন অ্যাপ্লিকেশনের জন্য উপযুক্ত যা দিনে অনেকবার জেনারেট করা কোড চালায় এবং প্রতিটি রানের জন্য একটি মেশিনের সেটআপ ও টিয়ারডাউনের ঝামেলা চায় না।

অফিসিয়াল E2B SDK কি সত্যিই কোনো কোড পরিবর্তন ছাড়াই কাজ করে?

হ্যাঁ, কনফিগারেশন পরিবর্তনের মাধ্যমে। আপনার ডেমন-এ apiUrl এবং sandboxUrl কে /e2b/api এবং /e2b/envd এর দিকে নির্দেশ করুন এবং আপনার Dormice টোকেনটিকে e2b_ প্রিফিক্সসহ API কী হিসেবে পাস করুন। কমান্ড এক্সিকিউশন, PTY সেশন, ফাইল ট্রান্সফার, সাইন করা URL এবং পোর্ট প্রক্সি—সবই প্রজেক্টের এন্ড-টু-এন্ড সুইট দ্বারা অফিসিয়াল প্যাকেজের মাধ্যমে কভার করা হয়। টেমপ্লেট বিল্ডিংয়ের ক্ষেত্রে একটি উল্লেখযোগ্য ঘাটতি রয়েছে: e2b template build এখনো ইমপ্লিমেন্ট করা হয়নি, তাই একটি টেমপ্লেট হলো একটি ডকার ইমেজ যা আপনি তৈরি করেন এবং dor template add দিয়ে রেজিস্টার করেন।

4 GB RAM-এর একটি VPS-এ কয়টি স্যান্ডবক্স রাখা সম্ভব?

অপারেটিং সিস্টেম, ডকার এবং ডেমনের জন্য প্রায় 1 GB জায়গা বাদ দেওয়ার পর, যদি প্রতিটি স্যান্ডবক্স 512 MiB ব্যবহার করে তবে একই সময়ে 6 টি স্যান্ডবক্স সচল রাখা সম্ভব, অথবা প্রতিটি 1 gibibyte ব্যবহার করলে 3 টি স্যান্ডবক্স রাখা সম্ভব। ফ্রোজেন স্যান্ডবক্সগুলোর সীমাবদ্ধতা মূলত সোয়াপের ওপর নির্ভর করে, তাই ইনস্টলারের ডিফল্ট 16 GB সোয়াপফাইল প্রায় 16 টি স্যান্ডবক্স রাখতে পারে, যেখানে প্রতিটি 1 gibibyte জায়গা দখল করে। বাস্তব লোডের অধীনে free -m ব্যবহার করে আপনার নিজের পরিমাপ নিন, কারণ একটি টেস্ট সুইট চালানো স্যান্ডবক্স ছোট স্ক্রিপ্ট চালানো স্যান্ডবক্সের চেয়ে কয়েক গুণ বেশি রিসোর্স ব্যবহার করে।

Dormice-এর কেন vm.swappiness 100 সেট করা প্রয়োজন?

একটি স্যান্ডবক্স ফ্রিজ করার অর্থ হলো এর অলস মেমোরিকে সোয়াপে পাঠিয়ে দেওয়া। gVisor স্যান্ডবক্সের মেমোরিকে শেয়ার্ড মেমোরি হিসেবে ধরে রাখে এবং লিনাক্স কার্নেল ডিফল্ট swappiness-এ শেয়ার্ড মেমোরি সোয়াপ করে না। তাই ডিফল্ট সেটিংসে ফ্রিজ করলে কোনো মেমোরি রিক্লেইম হয় না এবং স্যান্ডবক্সটি পূর্ণ মেমোরির খরচ বজায় রাখে। প্রজেক্টের পরিমাপ অনুযায়ী, ডিফল্ট সেটিংসে 0 বাইট রিক্লেইম হয়, কিন্তু 100 সেটিংসে 99.5 শতাংশ রিক্লেইম হয়। কনফিগারেশন ফাইল পড়ার পরিবর্তে sysctl vm.swappiness দিয়ে কার্যকর মানটি যাচাই করুন, কারণ কিছু ক্লাউড ইমেজে ডিফল্ট মান 0 থাকে।