Dormice மூலம் உங்கள் சொந்த VPS-ல் Agent Sandbox

Dormice என்றால் என்ன, அது எதல்ல

Dormice என்பது ஒரு self-hosted agent sandbox ஆகும். இது நீங்கள் வைத்திருக்கும் Linux VPS-ல் இயங்கும் ஒரு daemon. உங்கள் agent code, நம்பகத்தன்மையற்ற குறியீடுகளை (untrusted code) தனிமைப்படுத்தப்பட்ட container-க்குள் இயக்க, HTTP வழியாக இந்த daemon-ஐ அழைக்கும். உங்கள் நிரல் ஒரு sandbox-ஐ அதன் பெயரைக் கொண்டு கோரும்; அது எந்த நிலையில் இருந்தாலும் அதே sandbox-ஐத் திரும்பப் பெறும். அதில் ஒரு கட்டளையை (command) இயக்கி, அதன் வெளியீட்டை (output) வாசிக்கும். இந்த sandbox என்பது ஒரு நிரல் சார்ந்த வளமே (programmatic resource) தவிர, நீங்கள் SSH மூலம் நுழையும் ஒரு machine அல்ல.

இது ஒரு agent-க்கு முழு கணினியைக் கொடுப்பதிலிருந்து மாறுபட்டது. ஒரு coding agent-க்கான தற்காலிக VM என்பது நீங்கள் SSH மூலம் நுழைந்து, agent-ஐப் பயன்படுத்தி சிதைக்க விட்டு, பின் அழித்துவிடும் ஒரு பெட்டி. Dormice ஒரு படி கீழே இயங்குகிறது: உங்களிடம் ஏற்கனவே குறியீடு இருக்கும்போது, அதை பாதுகாப்பாக இயக்க உங்கள் நிரல் அழைக்கும் ஒரு execution API இது. ஒரு முழு கணினியே வேலையின் அலகாக (unit of work) இருக்கும்போது தற்காலிக VM-ஐப் பயன்படுத்தவும். ஒரு ஒற்றை exec அழைப்பு வேலையின் அலகாக இருக்கும்போதும், நூற்றுக்கணக்கான VM-களை உருவாக்காமல் ஒரு நாளில் நூறு முறை இயக்க விரும்பும்போதும் Dormice-ஐப் பயன்படுத்தவும்.

இந்தத் திட்டம் தன்னை E2B compatible என்று அழைத்துக் கொள்கிறது. E2B என்பது ஒரு hosted sandbox சேவை; இதன் client library-ஐப் பல agent frameworks ஏற்கனவே பயன்படுத்துகின்றன. Dormice அதே protocol-ஐத் தனது சொந்த URL prefixes-ன் கீழ் வழங்குகிறது. எனவே, அதிகாரப்பூர்வமான e2b package-ஐப் பயன்படுத்தி எழுதப்பட்ட ஒரு application, அதை உங்கள் சொந்த server-க்கு மாற்றும்போது தொடர்ந்து இயங்கும். Application code-ல் எந்த மாற்றமும் செய்யத் தேவையில்லை. இரண்டு URL-களும் ஒரு API key prefix-ம் மட்டுமே மாறும்.

"ஏஜென்ட் சாண்ட்பாக்ஸ்களின் SQLite" என்பது நடைமுறையில் எதைக் குறிக்கிறது

SQLite என்பது நீங்கள் இயக்கும் ஒரு service அல்ல, மாறாக நீங்கள் உட்பொதிக்கும் (embed) ஒரு database ஆகும். Dormice இந்த ஒப்பீட்டை அப்படியே பயன்படுத்துகிறது. ஒரே ஒரு daemon, ledger-க்காக ஒரே ஒரு SQLite கோப்பு, ஒரே ஒரு TCP port. Kubernetes தேவையில்லை, தனி database தேவையில்லை, scheduler தேவையில்லை. இந்த daemon தனது ledger-க்கு அருகில் ஒரு lock-ஐ எடுத்துக்கொள்கிறது. ledger-ம் அது கண்டறியும் கணினியும் ஒன்றாக இருக்க முடியாது எனில், அது தொடங்க மறுத்துவிடும்; எனவே split brain சிக்கல் அமைதியாக நடக்காது. ஒரே ஒரு கணினி என்பதே இதன் வடிவமைப்பு. பல host-களில் உங்களுக்கு ஒரு fleet தேவைப்பட்டால், வேறு எதையாவது தேர்வு செய்யுமாறு README தெளிவாகக் கூறுகிறது, அதை நீங்கள் பின்பற்ற வேண்டும்.

இந்தக் கருத்தின் இரண்டாம் பகுதி செலவைப் பற்றியது. ஒரு hosted sandbox அது இருக்கும் ஒவ்வொரு நொடிக்கும் கட்டணம் வசூலிக்கிறது, எனவே hosted sandboxes வடிவமைப்பிலேயே தூக்கி எறியக்கூடியவை (disposable) ஆகும். Dormice நீங்கள் ஏற்கனவே பணம் செலுத்தும் hardware-ல் இயங்குவதால், அதன் sandboxes நிரந்தரமானவை மற்றும் அவை எவ்வளவு காலம் பயன்பாடின்றி இருக்கிறதோ அவ்வளவு மலிவானவை. ஒரு sandbox படிப்படியாகத் தனது செயல்பாட்டைக் குறைக்கும்: active, பிறகு frozen, பிறகு stopped, இறுதியாக archived. எந்தவொரு acquire செயலும் அது எந்த நிலையில் இருந்தாலும் அதை மீண்டும் பழைய நிலைக்குக் கொண்டுவரும்.

Freezing என்பது புரிந்துகொள்ள வேண்டிய ஒரு முக்கிய அம்சம், ஏனெனில் இதுவே ஒவ்வொரு ஏஜென்ட்டின் sandbox-ஐயும் எப்போதும் மலிவாக வைத்திருக்க உதவுகிறது. இவை திட்டத்தின் சொந்த தரவுகள், உங்கள் 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 நினைவகத்தை வைத்திருக்கும் ஒரு idle sandbox, frozen நிலைக்கு வந்தவுடன் 5 MiB resident நினைவகமாகக் குறைகிறது, மேலும் சுமார் 50 ms நேரத்தில் மீண்டும் செயல்பாட்டுக்கு வருகிறது. செயல்முறைகள் (processes) அப்படியே நிறுத்தப்பட்டு மீண்டும் தொடங்கப்படுவதால், நீண்ட காலம் இயங்கும் ஒரு ஏஜென்ட் தனது shell நிலையையும், பாதியில் நின்ற வேலையையும் freeze நிலைக்குப் பிறகும் தக்கவைத்துக் கொள்கிறது. இதை உங்கள் host-ல் நீங்களே சோதித்துப் பார்த்து, அதன் பிறகு உங்கள் capacity-ஐத் திட்டமிடுங்கள்.

நிறுவுவதற்கு முன் host-க்குத் தேவையானவை

Host என்பது x86_64 கட்டமைப்பில் உள்ள Ubuntu அல்லது Debian ஆக இருக்க வேண்டும், மேலும் installer-க்கு root அனுமதி தேவை. Daemon, loop mounts மற்றும் cgroups-ல் எழுதுவதால், runtime-ன் போதும் root உரிமையைத் தக்கவைத்துக் கொள்கிறது.

Sandboxes, gVisor (container-க்கும் host kernel-க்கும் இடையே userspace kernel-ஐ வைக்கும் ஒரு container runtime) உடன் Docker-ன் கீழ் இயங்குகின்றன. இது ஒவ்வொரு sandbox-ம் பயன்படுத்தும் runsc runtime-ஐ வழங்குகிறது. Node 22 அல்லது அதற்குப் பிந்தைய பதிப்பு daemon-ஐ இயக்குகிறது; installer தனது சொந்த நகலை எடுத்து வருவதால், உங்கள் system-ல் உள்ள Node பாதிக்கப்படாது.

Swap கண்டிப்பாக இருக்க வேண்டும், மேலும் vm.swappiness மதிப்பு 100 ஆக இருக்க வேண்டும். இது செயல்திறனை மேம்படுத்துவதற்கான ஆலோசனை அல்ல, இது ஒரு செயல்பாட்டுத் தேவை (functional requirement). ஒரு idle sandbox-ன் நினைவகத்தை swap-க்குத் தள்ளுவதன் மூலமே freezing செயல்படுகிறது. gVisor, sandbox நினைவகத்தை shared memory-ஆக வைத்திருக்கிறது; இயல்பான swappiness மதிப்பில் kernel shared memory-ஐ swap செய்யாது. இயல்பான மதிப்பில் 0 bytes மட்டுமே மீட்கப்பட்டதையும், 100 என்ற மதிப்பில் 99.5 சதவீதம் மீட்கப்பட்டதையும் இந்தத் திட்டம் உறுதிப்படுத்தியுள்ளது. Kernel உண்மையில் எந்த மதிப்பை பயன்படுத்துகிறது என்பதைச் சரிபார்க்கவும், ஏனெனில் சில cloud images-ல் vm.swappiness = 0 மதிப்பு நீங்கள் கவனிக்காத ஒரு கோப்பில் இருக்கலாம்.

sysctl vm.swappiness
swapon --show

sysctl vm.swappiness கட்டளை vm.swappiness = 100 என்பதை அச்சிட வேண்டும், மேலும் swapon --show கட்டளை ஒரு swapfile-ஐப் பட்டியலிட வேண்டும். Swappiness மதிப்பு 0 என்று காட்டினால், ஒவ்வொரு freeze செயல்பாடும் பயனற்றதாகிவிடும்; இதனால் ஒவ்வொரு idle sandbox-க்கும் நீங்கள் முழு நினைவகத்திற்கான கட்டணத்தைச் செலுத்த வேண்டியிருக்கும்.

Ubuntu-வில் Dormice-ஐ நிறுவுதல்

ஆவணப்படுத்தப்பட்ட நிறுவல் முறை bash-க்கு ஒரு pipe மூலம் செய்யப்படுகிறது:

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

இதை இயக்கும் முன், பதிவிறக்கம் செய்து படித்துப் பார்க்கவும். இந்த script root பயனர் உரிமையுடன் இயங்கி உங்கள் host-ஐ மாற்றியமைக்கும்: Docker இல்லையெனில் அதை நிறுவும், gVisor மற்றும் Caddy-ஐ checksum சரிபார்ப்புடன் பதிவிறக்கும், swapfile-ஐ உருவாக்கும், systemd units-ஐ எழுதும், மற்றும் 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 அளவை அமைக்கிறது, இதன் default மதிப்பு 16 ஆகும். சிறிய VPS-களில் இது அதிக disk இடத்தை எடுத்துக்கொள்ளும். --mirror cn என்பது பதிவிறக்கங்களை mainland China-விலிருந்து அணுகக்கூடிய mirrors-க்கு மாற்றும். நிறுவியை மீண்டும் இயக்குவது code-ஐ upgrade செய்யவும், மாற்றங்களைச் சரிசெய்யவும் உதவும்; இது உங்கள் API token-ஐ ஒருபோதும் மாற்றாது.

Code /opt/dormice-லும், configuration /etc/dormice/env-லும், sandbox தரவுகள் /var/lib/dormice-லும், dormice மற்றும் dor கட்டளைகள் /usr/local/bin-லும் அமையும். நிறுவி, நிறுவலின் போது API token-ஐ உருவாக்கி, அதை 600 mode-ல் /etc/dormice/env-ல் எழுதும்.

நிறுவுவதற்கு tagged release எதுவும் இல்லை. 4 August 2026 நிலவரப்படி, repository-ல் git tags அல்லது GitHub releases எதுவும் இல்லை. எனவே, நிறுவி main-ஐ clone செய்யும், அந்த நாளில் என்ன code உள்ளதோ அதுவே உங்களுக்குக் கிடைக்கும். எனவே, ஒரு version-ஐ நிலைநிறுத்த (pinning), நீங்கள் நிறுவிய commit-ஐக் குறித்து வைத்துக்கொள்ள வேண்டும்.

git -C /opt/dormice rev-parse HEAD

அந்த hash-ஐ உங்கள் deploy குறிப்புகளில் சேமிக்கவும். ஒரு upgrade சிக்கலை ஏற்படுத்தினால், அந்த commit மட்டுமே நீங்கள் பின்னோக்கிச் செல்ல உதவும் ஒரே வழி, ஏனெனில் குறிப்பிடுவதற்கு version எண் எதுவும் இல்லை.

நிறுவி dor doctor-ஐ இயக்குவதன் மூலம் முடிவடையும். இது ஒரு read-only host check ஆகும்; இது package பட்டியலை மட்டும் நம்பாமல், runtime சரியாக வேலை செய்கிறதா என்பதை உறுதிப்படுத்த உண்மையான gVisor containers-ஐ இயக்கும். daemon சரியாகச் செயல்படாதபோது இதை மீண்டும் இயக்கவும்.

sudo dor doctor
systemctl is-active dormice

systemctl is-active dormice கட்டளை active-ஐ அச்சிட வேண்டும். அது failed-ஐ அச்சிட்டால், journalctl -u dormice -n 50-ல் அதற்கான காரணம் இருக்கும். தொடக்கம் தோல்வியடைவது பெரும்பாலும் daemon-ன் குறைபாடு அல்ல, மாறாக swap அல்லது gVisor முன்நிபந்தனைகள் சரியாக இல்லாததே காரணம்.

நிறுவி Caddy-யையும் நிறுவுவதால், firewall வேலை முடிந்துவிட்டதாகக் கருதும் முன், எவை listen செய்கின்றன என்பதைச் சரிபார்க்கவும்.

sudo ss -lntp

daemon 127.0.0.1:3676-ஐ bind செய்கிறது, இதை மாற்ற எந்த அமைப்பும் இல்லை, இது வடிவமைப்பிலேயே உள்ளது. உங்கள் 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-ஐப் பயன்படுத்தி ஒருமுறை உள்நுழையவும்; அது httpOnly session cookie-ஆக மாறும். எனவே, token எந்த இடத்திலும் page-ஆல் வாசிக்கக்கூடிய வகையில் சேமிக்கப்படாது. அங்குள்ள Connect பக்கத்தில், உங்கள் endpoint-ஐக் குறிக்கும் client snippets-ஐ copy-and-paste செய்து கொள்ளலாம்.

Sandbox-ஐ உருவாக்கி அதில் code-ஐ இயக்குதல்

Sandbox-ஐ உருவாக்க ஒரு செயல்பாடு மட்டுமே உள்ளது: acquire. இது idempotent தன்மையுடையது, எனவே ஒரே key எப்போதும் ஒரே sandbox-ஐயே வழங்கும்; தேவைக்கேற்ப அதை உருவாக்குதல், எழுப்புதல், தொடங்குதல் அல்லது மீட்டெடுத்தல் போன்றவற்றை இது செய்யும். மற்ற அனைத்து verbs-களும், இதுவரை கண்டிராத ஒரு key-க்கு 404 பிழையை வழங்கும். dor CLI-ல் acquire verb கிடையாது, எனவே உங்கள் முதல் sandbox-ஐ console அல்லது client library மூலமே பெற முடியும்.

Console வழிமுறையே வேகமானது. 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 நிலையையும் பட்டியலிடும்; இதன் மூலம் ஒரு sandbox active நிலையிலிருந்து frozen நிலைக்கு மாறுவதை நீங்கள் கண்காணிக்கலாம். dor sandbox exec ஒரு Python 3.12 பதிப்பை அச்சிடும், ஏனெனில் இதன் stock image-ல் Ubuntu 24.04 உடன் Python 3.12, Node 24, git மற்றும் ripgrep ஏற்கனவே நிறுவப்பட்டிருக்கும். ஒருவேளை authentication error ஏற்பட்டால், நீங்கள் நகலெடுத்த token வரியில் variable பெயரும் சேர்ந்துள்ளது என்று அர்த்தம்.

கோப்புகளை dor sandbox push my-agent ./script.py மூலம் நகர்த்தலாம், அது /home/user/script.py-ல் சேமிக்கப்படும்; dor sandbox pull my-agent notes.txt மூலம் கோப்புகளைத் திரும்பப் பெறலாம். Native file verbs ஒரு கோப்பிற்கு 16 MiB வரை மட்டுமே அனுமதிக்கும், ஆனால் E2B file surface கோப்புகளை stream செய்வதால், sandbox disk quota மட்டுமே அதன் எல்லையாக இருக்கும்.

Destroying என்பது மட்டுமே தரவுகளை அழிக்கும் செயல்பாடு; இது இந்த project-ன் காலத்தைப் பற்றிய ஒரு சிறந்த உதாரணம்: முதன்மை README மற்றும் அதனுடன் இணைந்த agent skill ஆகிய இரண்டும் dor sandbox destroy <key>-ஐக் குறிப்பிடுகின்றன, ஆனால் CLI package README dor sandbox release <key>-ஐக் குறிப்பிடுகிறது. உங்கள் சொந்த build-ல் dor sandbox --help-ஐ இயக்கி, அதையே நம்புங்கள்.

உங்கள் சொந்த சர்வரில் ஏற்கனவே உள்ள E2B குறியீட்டைப் பயன்படுத்துதல்

இதற்காகவே நீங்கள் இதை கவனிக்க வேண்டும். npm-லிருந்து பெறப்படும் அதிகாரப்பூர்வ e2b தொகுப்பு, எந்த மாற்றமும் செய்யப்படாமல், Dormice உடன் தொடர்பு கொள்கிறது. உங்கள் லேப்டாப்பில் SSH tunnel-ஐத் திறந்து வைத்துக்கொண்டு இதை இயக்கவும்; இதனால் சர்வரில் புதிதாக எந்த போர்ட்டும் திறக்கப்படாது.

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 என்பது ஒரு சாதாரண stub அல்ல. stdout மற்றும் stderr-ஐ ஸ்ட்ரீமிங் செய்தல், பின்னணியில் கட்டளைகளை இயக்குதல், interactive PTY, கையொப்பமிடப்பட்ட upload மற்றும் download URL-கள், directory கண்காணிப்பு மற்றும் port proxy என அனைத்தும் அதிகாரப்பூர்வ தொகுப்பின் மூலம், உண்மையான Docker மற்றும் gVisor daemon-ல் இந்தத் திட்டத்தின் end-to-end suite மூலம் சோதிக்கப்படுகின்றன. நீங்கள் எதையும் உண்மையான பயன்பாட்டிற்கு மாற்றும் முன் சில வேறுபாடுகளைக் கவனத்தில் கொள்ள வேண்டும்:

• Template உருவாக்கங்கள் செயல்படுத்தப்படவில்லை. Template என்பது நீங்கள் சொந்தமாக உருவாக்கி dor template add மூலம் பதிவு செய்யும் ஒரு docker image ஆகும்; இதை Sandbox.create('name') கண்டறியும். பதிவு செய்யப்படாத பெயரைப் பயன்படுத்தினால், அது போலியாகச் செயல்படாமல் 404 பிழையைத் தரும்.
• E2B இடைமுகம் வழியாக உருவாக்கப்படும் sandboxes-க்கு உண்மையான காலக்கெடு (deadlines) உண்டு, ஏனெனில் E2B-ன் செயல்பாட்டு முறை அதை அவசியமாக்குகிறது. native API மூலம் உருவாக்கப்படும் sandboxes-க்கு எந்த காலக்கெடுவும் விதிக்கப்படுவதில்லை.
• ஒரு frozen sandbox அதன் செயல்முறைகளை (processes) அப்படியே வைத்திருந்து, பாதியிலேயே மீண்டும் தொடங்கும். எனவே, இங்கே pause மற்றும் resume என்பது நீங்கள் வழக்கமாகப் பயன்படுத்தும் stop மற்றும் cold start போன்றது அல்ல.

Sandbox எவற்றைத் தடுக்கிறது, எவற்றைத் தடுப்பதில்லை

gVisor, container-ன் system calls-ஐ userspace-ல் இடைமறித்து, அவற்றை தானே கையாள்கிறது. எனவே, sandbox-க்குள் இருக்கும் code உங்கள் host kernel-உடன் நேரடியாகத் தொடர்புகொள்வதில்லை. Sandbox-க்குள் அனைத்தும் uid 1000 என்ற unprivileged user-ஆகவே இயங்குகின்றன. இந்த அமைப்பு சாதாரண சூழல்களைக் கையாள்கிறது: உருவாக்கப்படும் ஒரு script rm -rf /-ஐ இயக்கினாலும், disk-ஐ நிரப்பினாலும் அல்லது ஏதேனும் செயலிழக்கும் வரை fork செய்தாலும், அது தனது சொந்த sandbox-ஐ மட்டுமே பாதிக்கும், அங்கேயே நின்றுவிடும்.

இது தடுக்காத விஷயங்கள் கீழே உள்ளன. இவை ஒவ்வொன்றையும் கவனிப்பது உங்கள் பொறுப்பு.

• Sandbox-க்கு வெளிச்செல்லும் network வசதி உண்டு. உருவாக்கப்படும் code எதை வேண்டுமானாலும் download செய்யலாம், எதைக் கண்டறிந்தாலும் அதை post செய்யலாம். Installer-ன் network hardening இரண்டு குறிப்பிட்ட விஷயங்களைச் செய்கிறது: இது 169.254.0.0/16 என்ற cloud metadata service-க்கான container traffic-ஐத் தடுக்கிறது (இங்கிருந்துதான் cloud instance-ன் credentials பெறப்படும்). மேலும், Docker-ன் daemon.json-ல் "icc": false மூலம் container-களுக்கு இடையிலான traffic-ஐயும் இது முடக்குகிறது. மற்றவை எதுவும் தடுக்கப்படுவதில்லை. sudo iptables -S DOCKER-USER-ஐப் படித்து, sandbox அணுகத் தேவையில்லாத private ranges-க்கு உங்கள் சொந்த DROP விதிகளைச் சேர்க்கவும்.
• Docker தனது சொந்த விதிகளை உங்கள் firewall-க்கு முன்னால் செருகுகிறது. எனவே, ufw மூடியிருப்பதாகக் காட்டினாலும், ஒரு published container port இணையத்திலிருந்து பதிலளிக்கக்கூடும். எதையும் இந்த host-ல் expose செய்வதற்கு முன் Docker எவ்வாறு ufw-ஐத் தாண்டி ports-ஐ வெளியிடுகிறது மற்றும் VPS-க்கான ufw firewall அடிப்படைகள் ஆகியவற்றைப் படிக்கவும்.
• gVisor என்பது ஒரு userspace kernel, hypervisor அல்ல. இது ஒரு திட்டமிட்ட சமரசம்; ஏனெனில், freezing செய்வதற்கு sandbox-கள் process-களாக இருக்க வேண்டும். KVM-ஐக் கட்டாயப்படுத்தினால், அது எங்கும் நிறுவப்படாமல் போகும். உங்கள் threat model-க்கு hardware virtualisation தேவைப்பட்டால், Firecracker-வகை isolation-ஐப் பயன்படுத்தவும், அதனுடன் வரும் செயல்பாட்டுச் செலவை ஏற்றுக்கொள்ளவும்.
• API token என்பது client பக்கத்தில் உள்ள முழுமையான பாதுகாப்பு எல்லையாகும். DORMICE_API_TOKEN-ஐ வைத்திருக்கும் எவரும் இந்த machine-ல் உள்ள ஒவ்வொரு sandbox-ஐயும் உருவாக்க, படிக்க மற்றும் அழிக்க முடியும். Agent process-க்கு என்று தனி VPS-ல் குறைந்தபட்ச அதிகாரம் கொண்ட user-ஐ உருவாக்கவும், அந்த token-ஐ ஒரு SSH key-ஐப் போலவே கையாளவும். VPS-ல் Claude Code-ஐப் பாதுகாப்பாக இயக்குதல் என்பதிலிருந்து பெறப்பட்ட பழக்கங்கள் இதற்கும் நேரடியாகப் பொருந்தும்.

Daemon ஆனது உங்கள் host-ல் root-ஆக இயங்குகிறது. gVisor, sandbox-க்குள் இருக்கும் code-லிருந்து host-ஐப் பாதுகாக்கிறது. ஆனால், daemon-லிருந்தோ அல்லது அதன் token-ஐ வைத்திருப்பவரிடமிருந்தோ host-ஐப் பாதுகாக்க எதுவுமில்லை. எனவே, Dormice இயங்கும் machine, அந்த வேலையை மட்டுமே செய்ய வேண்டும். உங்கள் agent MCP (model context protocol) வழியாகக் கருவிகளை அணுகினால், அதே காரணத்திற்காக அந்த MCP servers-ஐத் தனி VPS-ல் வைத்திருக்கவும்.

4 GB மற்றும் 8 GB நினைவகத்தில் எத்தனை sandboxes-களை இயக்க முடியும்?

இரண்டு காரணிகள் நினைவகத்தை அதிகம் பயன்படுத்துகின்றன: host-ன் அடிப்படைத் தேவை மற்றும் தற்போது இயங்கிக்கொண்டிருக்கும் ஒவ்வொரு sandbox-ன் working set. Ubuntu, Docker மற்றும் daemon-க்காக சுமார் 1 GB நினைவகத்தை ஒதுக்கிவிட்டு, மீதமுள்ளதை ஒரு sandbox உண்மையில் பயன்படுத்தும் அளவைக் கொண்டு வகுக்க வேண்டும். சில கோப்புகளை வாசிக்கும் Python script-ஐ இயக்கும் ஒரு sandbox, 200 முதல் 300 MiB வரை நினைவகத்தைப் பயன்படுத்தும். ஒரு compiler அல்லது முழுமையான test suite-ஐ இயக்கும் sandbox ஒரு 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-ல், ஒவ்வொரு sandbox-ம் 512 MiB பயன்படுத்தினால் ஒரே நேரத்தில் 6 sandboxes-களையும், ஒவ்வொன்றும் ஒரு முழு gibibyte பயன்படுத்தினால் 3 sandboxes-களையும் இயக்க முடியும். 8 GB VPS-ல் இது முறையே 14 மற்றும் 7 ஆக உயரும். இவை ஒரே நேரத்தில் இயங்கக்கூடிய பணிகளுக்கான உச்ச வரம்புகள் மட்டுமே; இவை கணக்கீட்டு அளவீடுகள் என்பதால், உங்கள் பணிச்சுமை இயங்கும்போது free -m-ஐக் கண்காணிப்பது அவசியம்.

Frozen sandboxes-கள் RAM-க்கு பதிலாக swap-ஐப் பயன்படுத்துகின்றன; இதுவே இந்த வடிவமைப்பின் முக்கிய நோக்கமாகும். ஒரு gibibyte நினைவகத்தைப் பயன்படுத்திய ஒரு sandbox, frozen நிலைக்குச் செல்லும்போது அந்த அளவு தரவை swap-ல் வைத்துக்கொண்டு, RAM-ல் மிகக் குறைந்த அளவே இருக்கும். எனவே, installer-ன் default 16 GB swapfile சுமார் 16 sandboxes-களைத் தாங்கும். அதற்கு மேல் தேவைப்பட்டால், அவற்றை stopped நிலைக்கு மாற்ற வேண்டும்; அப்போது அவை disk இடத்தை மட்டுமே பயன்படுத்தும். நீண்ட கால அடிப்படையில் disk இடமே உண்மையான வரம்பாகும்: ஒவ்வொரு sandbox-ம் அதன் சொந்த filesystem-ஐ வைத்திருக்கும். பல டஜன் agents ஒவ்வொன்றும் ஒரு node_modules directory-ஐக் கொண்டிருக்கும்போது, நினைவகப் பற்றாக்குறை ஏற்படும் முன்பே சிறிய volume நிரம்பிவிடும்.

Freeze, stop, archive: வாழ்க்கைச் சுழற்சி கட்டுப்பாடுகள்

இயல்பான அமைப்புகளின்படி, 10 நிமிடங்கள் செயலற்று இருந்தால் freeze ஆகும், 3 நாட்களுக்குப் பிறகு stop ஆகும், மேலும் archiving அமைக்கப்பட்டிருந்தால் 7 நாட்களுக்குப் பிறகு archive செய்யப்படும். stopAfterSeconds-ஐ null என அமைத்தால், அது resident agent-ஆகச் செயல்படும்: இது செயலற்று இருக்கும்போது freeze ஆகலாம், ஆனால் ஒருபோதும் cold start ஆகாது.

Archiving என்பது விருப்பத்திற்குரியது, மேலும் daemon இது குறித்து வெளிப்படையாகச் செயல்படுகிறது. நான்கு DORMICE_S3_* மாறிகளையும் அமைத்தால், நிறுத்தப்பட்ட sandbox-ன் வட்டு tar மற்றும் zstd மூலம் சுருக்கப்பட்டு, S3-compatible bucket-க்கு அனுப்பப்பட்டு, உள்ளூர் சேமிப்பகத்திலிருந்து நீக்கப்படும். அந்த bucket-ஐ நீங்கள் மற்றொரு கணினியில் நடத்தும் MinIO bucket-ஆக வைத்திருக்கலாம். இந்த மாறிகளை அமைக்காமல் விட்டால், sandbox-கள் நிரந்தரமாக stopped நிலையிலேயே இருக்கும், மேலும் archive செய்யக் கோரும் கொள்கை நிராகரிக்கப்படும் (அமைதியாகப் புறக்கணிக்கப்படாது). மீட்டெடுப்பு (restore) செயல்முறை வெளிப்படையானது: அடுத்த முறை acquire செய்யும்போது, அது உடனடியாக restoring நிலையையும் progress மதிப்பையும் காட்டும், வட்டு திரும்பியவுடன் அது ready நிலைக்கு மாறும்.

இதை இப்போதே பயன்படுத்தத் தொடங்கலாமா?

நேரடியான பதில்: மீண்டும் உருவாக்க முடியாத எதற்கும் இதைப் பயன்படுத்த வேண்டாம். இந்த repository-ன் முதல் commit 8 July 2026 தேதியிட்டது. 4 August 2026 நிலவரப்படி, இது 446 stars, 37 forks மற்றும் Apache-2.0 உரிமத்தைக் கொண்டுள்ளது, ஆனால் எந்தவொரு tagged release-ம் வெளியிடப்படவில்லை. README-ல் உள்ள status வரியே, இதில் எதுவும் production பயன்பாட்டிற்குத் தயாராக இல்லை என்பதைத் தெரிவிக்கிறது.

இந்தக் கலவை ஒரு குறிப்பிட்ட வகை அபாயத்தைக் கொண்டுள்ளது. installer main-ஐத் தொடர்ந்து கண்காணிப்பதால், code உங்கள் கட்டுப்பாடின்றி மாறக்கூடும். interface இன்னும் நிலையற்றதாக உள்ளது; இதனால்தான் ஒரே repository-ல் உள்ள இரண்டு வெவ்வேறு கோப்புகளில் delete என்ற வினைச்சொல் இரண்டு பெயர்களில் உள்ளது. நான்கு வாரங்களே ஆன ஒரு திட்டம் எந்த நேரத்திலும் நின்றுவிடலாம், ஏனெனில் எந்தவொரு உரிம விதியும் யாரையும் இதைத் தொடர்ந்து பராமரிக்கக் கட்டாயப்படுத்தவில்லை.

இந்த அபாயத்தைச் சமாளிக்கக்கூடியதாக மாற்றுவது E2B இணக்கத்தன்மை (compatibility) ஆகும். உங்கள் application ஒரு protocol-உடன் தொடர்பு கொள்கிறது, அதன் பின்னால் ஒரு hosted implementation உள்ளது. எனவே, Dormice நின்றுவிட்டால், நீங்கள் இரண்டு URL-களை மட்டும் மாற்றிவிட்டு வேலையைத் தொடரலாம். native API-க்கு பதிலாக E2B surface-ஐப் பயன்படுத்தி உங்கள் agent-ஐ உருவாக்குங்கள், அப்போதுதான் இந்த வெளியேறும் வழியை (exit path) நீங்கள் வைத்திருக்க முடியும். native @dormice/sdk package இன்னும் npm-ல் இல்லை, எனவே அதைப் பயன்படுத்த வேண்டுமென்றால் repository-லிருந்து நீங்களே build செய்ய வேண்டும். இதுவே இணக்கமான பாதையில் (compatible path) தொடங்குவதற்கான இரண்டாவது காரணம்.

இழப்பு ஏற்பட்டாலும் பரவாயில்லை என்ற சூழலில் இதை இயக்குங்கள். host-ஐ ஒரு script மூலம் மீண்டும் உருவாக்கக்கூடியதாக வைத்திருங்கள், token-ஐ எந்தவொரு prompt அல்லது commit-லும் சேர்க்காதீர்கள், மேலும் பாதுகாக்க வேண்டிய எதையும் உங்கள் சொந்த backup அட்டவணைப்படி sandbox-லிருந்து வெளியே எடுத்துவிடுங்கள்.

FAQ

Dormice தயாரிப்பு சூழலுக்கு (production) தயாரா?

இல்லை, இந்தத் திட்டமே அவ்வாறுதான் குறிப்பிடுகிறது. README-ன் status வரியில், இதில் உள்ள எதுவும் இன்னும் தயாரிப்பு சூழலுக்குத் தயாராக இல்லை என்று கூறப்பட்டுள்ளது. 4 August 2026 நிலவரப்படி, இந்த repository நான்கு வாரங்களே ஆகிறது; இதில் git tags அல்லது releases எதுவும் இல்லை, எனவே குறிப்பிடுவதற்கு version எண் எதுவும் இல்லை. installer ஆனது main branch-ஐ clone செய்கிறது, அதாவது ஒவ்வொரு முறையும் நீங்கள் இயக்கும்போது புதிய commit கிடைக்கிறது. ஒவ்வொரு install-க்கு பிறகும் git -C /opt/dormice rev-parse HEAD-ஐப் பதிவு செய்யவும், மதிப்புமிக்க எதையும் sandbox-களுக்கு வெளியே வைத்திருக்கவும்.

எனது agent-க்கு ஒரு disposable VM-ஐ வழங்குவதற்கும் Dormice-க்கும் என்ன வித்தியாசம்?

Disposable VM என்பது நீங்கள் ஒரு session-க்காக உருவாக்கி, பிறகு அழித்துவிடும் SSH வசதி கொண்ட ஒரு machine ஆகும். Dormice என்பது ஒரு execution API: உங்கள் நிரல் acquire, பிறகு exec ஆகியவற்றை அழைக்கும், அதன் மூலம் stdout மற்றும் exit code-ஐப் பெறும்; இடையில் shell session எதுவும் இருக்காது. ஒரு மனிதருக்கோ அல்லது சிறிது நேரம் முழு கணினியும் தேவைப்படும் agent-க்கோ VM பொருத்தமானது. ஒரு நாளில் பலமுறை உருவாக்கப்பட்ட code-ஐ இயக்கும் மற்றும் ஒவ்வொரு முறையும் ஒரு machine-ஐ அமைத்து அழிக்கும் வேலையைத் தவிர்க்க விரும்பும் application-களுக்கு Dormice பொருத்தமானது.

அதிகாரப்பூர்வ E2B SDK எந்த மாற்றமும் இன்றி உண்மையிலேயே வேலை செய்யுமா?

ஆம், configuration மாற்றங்களுடன் வேலை செய்யும். உங்கள் daemon-ல் apiUrl மற்றும் sandboxUrl ஆகியவற்றை /e2b/api மற்றும் /e2b/envd-க்கு சுட்டிக்காட்டவும், மேலும் உங்கள் Dormice token-ஐ e2b_ prefix-உடன் API key-ஆக வழங்கவும். Command execution, PTY sessions, file transfer, signed URLs மற்றும் port proxy ஆகிய அனைத்தும் அதிகாரப்பூர்வ package மூலம் இயங்கும் திட்டத்தின் end-to-end suite-ல் அடங்கும். Template building-ல் ஒரு குறிப்பிடத்தக்க இடைவெளி உள்ளது: e2b template build செயல்படுத்தப்படவில்லை, எனவே template என்பது நீங்கள் உருவாக்கி dor template add மூலம் பதிவு செய்யும் ஒரு docker image ஆகும்.

4 GB VPS-ல் எத்தனை sandbox-கள் பொருந்தும்?

ஒவ்வொரு sandbox-ம் 512 MiB பயன்படுத்தினால், ஒரே நேரத்தில் சுமார் 6 sandbox-கள் இயங்கும். அல்லது ஒவ்வொன்றும் ஒரு முழு gibibyte பயன்படுத்தினால் 3 sandbox-கள் இயங்கும். இதற்காக operating system, Docker மற்றும் daemon-க்கு சுமார் 1 GB ஒதுக்கப்படுகிறது. Frozen sandbox-கள் swap மூலம் கட்டுப்படுத்தப்படுகின்றன, எனவே installer-ன் default 16 GB swapfile, தலா ஒரு gibibyte கொண்ட சுமார் 16 sandbox-களைத் தாங்கும். உண்மையான சுமையின் கீழ் free -m மூலம் நீங்களே அளவிடவும், ஏனெனில் ஒரு test suite-ஐ இயக்கும் sandbox, ஒரு சிறிய script-ஐ இயக்கும் sandbox-ஐ விட பல மடங்கு அதிக வளங்களைப் பயன்படுத்தும்.

Dormice-க்கு ஏன் vm.swappiness 100-ஆக இருக்க வேண்டும்?

ஒரு sandbox-ஐ freeze செய்வது என்பது அதன் idle memory-ஐ swap-க்குத் தள்ளுவதாகும். gVisor, sandbox memory-ஐ shared memory-ஆக வைத்திருக்கிறது. Linux kernel, default swappiness-ல் shared memory-ஐ swap செய்யாது. எனவே, default நிலையில் freeze செய்தால் எதுவும் reclaim ஆகாது, மேலும் அந்த sandbox முழு memory-க்கான செலவை ஏற்படுத்தும். default நிலையில் 0 bytes மட்டுமே reclaim ஆனதாகவும், 100-ல் 99.5 சதவீதம் reclaim ஆனதாகவும் இந்தத் திட்டம் கண்டறிந்துள்ளது. configuration கோப்புகளைப் படிப்பதற்குப் பதிலாக, sysctl vm.swappiness மூலம் அதன் உண்மையான மதிப்பைச் சரிபார்க்கவும், ஏனெனில் சில cloud images 0 என்ற மதிப்போடு வருகின்றன.