วิธีติดตั้ง Dormice รัน Agent Sandbox บน VPS ของคุณเอง

Dormice คืออะไรและไม่ใช่สิ่งใด

Dormice คือ sandbox สำหรับ agent ที่คุณโฮสต์เอง โดยเป็น daemon ตัวหนึ่งบน Linux VPS ของคุณ ซึ่งโค้ดของ agent จะเรียกใช้งานผ่าน HTTP เพื่อรันโค้ดที่ไม่น่าเชื่อถือภายใน container ที่แยกส่วนออกมา โปรแกรมของคุณจะร้องขอ sandbox โดยระบุชื่อ และจะได้รับ sandbox เดิมกลับมาไม่ว่าสถานะก่อนหน้าจะเป็นอย่างไร จากนั้นจึงรันคำสั่งภายในและอ่านผลลัพธ์ที่ได้ sandbox นี้เป็นทรัพยากรที่เรียกใช้ผ่านโปรแกรม ไม่ใช่เครื่องที่คุณต้องล็อกอินเข้าไปใช้งาน

รูปแบบการทำงานนี้แตกต่างจากการมอบคอมพิวเตอร์ทั้งเครื่องให้กับ agent โดย VM แบบใช้แล้วทิ้งสำหรับ coding agent คือเครื่องที่คุณ SSH เข้าไป ปล่อยให้ agent ทำลายทิ้ง แล้วค่อยลบออก แต่ Dormice อยู่ในระดับที่ต่ำกว่านั้น คือเป็น API สำหรับการประมวลผลที่โปรแกรมของคุณเรียกใช้เมื่อมีโค้ดอยู่แล้วและต้องการพื้นที่ปลอดภัยในการรัน ให้ใช้ VM แบบใช้แล้วทิ้งเมื่อหน่วยของงานคือคอมพิวเตอร์ทั้งเครื่อง และใช้ Dormice เมื่อหน่วยของงานคือการเรียกใช้งาน exec เพียงครั้งเดียว ซึ่งคุณต้องการรันวันละร้อยครั้งโดยไม่ต้องใช้ VM ถึงร้อยเครื่อง

โปรเจกต์นี้เรียกตัวเองว่ารองรับมาตรฐาน E2B โดย E2B เป็นบริการ sandbox แบบโฮสต์ที่ไลบรารีฝั่งไคลเอนต์ของเฟรมเวิร์ก agent หลายตัวรองรับอยู่แล้ว Dormice ให้บริการด้วยโปรโตคอลเดียวกันภายใต้ URL prefix ของตัวเอง ดังนั้นแอปพลิเคชันที่เขียนโดยใช้แพ็กเกจ e2b อย่างเป็นทางการจึงยังคงทำงานได้ตามปกติเมื่อคุณชี้เป้าหมายไปยังเซิร์ฟเวอร์ของคุณเอง โดยไม่ต้องแก้ไขโค้ดของแอปพลิเคชัน เพียงแค่เปลี่ยน URL สองรายการและ prefix ของ API key เท่านั้น

ความหมายในทางปฏิบัติของ "SQLite แห่งโลก agent sandboxes"

SQLite คือฐานข้อมูลที่คุณฝังไว้ในแอปพลิเคชันแทนที่จะต้องดูแลเป็นบริการแยกต่างหาก ซึ่ง Dormice ได้นำแนวคิดนี้มาใช้โดยตรง โดยมี daemon หนึ่งตัว, ไฟล์ SQLite หนึ่งไฟล์สำหรับบันทึก ledger และพอร์ต TCP หนึ่งพอร์ต ไม่ต้องใช้ Kubernetes, ไม่ต้องมีฐานข้อมูลแยก และไม่ต้องมีตัวจัดตารางเวลา (scheduler) daemon จะทำการล็อกไฟล์ไว้ข้าง ledger ของตนเอง และปฏิเสธที่จะเริ่มทำงานหากพบว่า ledger นั้นกับเครื่องที่ใช้งานอยู่ไม่ตรงกัน เพื่อป้องกันไม่ให้เกิดปัญหา split brain โดยไม่ได้ตั้งใจ การออกแบบนี้เน้นการใช้งานบนเครื่องเดียวเป็นหลัก หากคุณต้องการใช้งานแบบกลุ่มบนหลายโฮสต์ ไฟล์ README ได้ระบุไว้อย่างชัดเจนให้คุณเลือกใช้เครื่องมืออื่นแทน และคุณควรปฏิบัติตามคำแนะนำนั้น

ส่วนที่สองของแนวคิดนี้คือเรื่องของต้นทุน sandbox แบบ hosted จะคิดค่าบริการทุกวินาทีที่เปิดใช้งาน ดังนั้น sandbox เหล่านี้จึงถูกออกแบบมาให้ใช้แล้วทิ้ง แต่ Dormice ทำงานบนฮาร์ดแวร์ที่คุณจ่ายเงินค่าเช่าหรือครอบครองอยู่แล้ว sandbox ของมันจึงมีความถาวรและมีต้นทุนถูกลงเรื่อยๆ เมื่อปล่อยทิ้งไว้นานขึ้น sandbox จะค่อยๆ ลดระดับการทำงานลงทีละขั้น ได้แก่: กำลังทำงาน (active), ถูกแช่แข็ง (frozen), หยุดทำงาน (stopped) และถูกจัดเก็บ (archived) การเรียกใช้งาน (acquire) ใดๆ จะดึง sandbox กลับขึ้นมาสู่สถานะพร้อมใช้งานจากระดับที่มันอยู่

การแช่แข็ง (freezing) คือส่วนที่ควรทำความเข้าใจ เพราะเป็นสิ่งที่ทำให้การเก็บ sandbox ของ agent ทุกตัวไว้ตลอดไปนั้นมีราคาที่จับต้องได้ ข้อมูลต่อไปนี้เป็นตัวเลขที่โครงการเผยแพร่ โดยวัดจากฮาร์ดแวร์ของผู้พัฒนาเอง ไม่ใช่ฮาร์ดแวร์ของคุณ

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

sandbox ที่ไม่ได้ใช้งานซึ่งใช้หน่วยความจำ 1024 MiB จะลดการใช้หน่วยความจำเหลือเพียง 5 MiB เมื่อถูกแช่แข็ง และจะกลับมาทำงานได้ภายในเวลาประมาณ 50 ms กระบวนการต่างๆ จะถูกระงับและกลับมาทำงานต่อในสถานะเดิม ดังนั้น agent ที่มีอายุการใช้งานยาวนานจะยังคงสถานะ shell และงานที่ทำค้างไว้ได้แม้จะผ่านการแช่แข็งมาแล้ว คุณควรทดสอบบนโฮสต์ของคุณเองก่อนที่จะวางแผนการจัดการทรัพยากรตามตัวเลขนี้

สิ่งที่โฮสต์จำเป็นต้องมีก่อนการติดตั้ง

โฮสต์ต้องเป็น Ubuntu หรือ Debian บนสถาปัตยกรรม x86_64 และตัวติดตั้งต้องการสิทธิ์ root ตัว daemon จำเป็นต้องคงสิทธิ์ root ไว้ในขณะทำงานเนื่องจากต้องทำ loop mounts และเขียนข้อมูลลงใน cgroups

Sandbox จะทำงานภายใต้ Docker ร่วมกับ gVisor (ซึ่งเป็น container runtime ที่แทรก kernel ระดับ userspace ไว้ระหว่าง container กับ kernel ของโฮสต์) เพื่อจัดเตรียม runsc runtime ที่แต่ละ sandbox ใช้งาน โดย daemon จะทำงานบน Node 22 หรือใหม่กว่า และตัวติดตั้งจะมาพร้อมกับ Node ของตนเอง ดังนั้นระบบ Node ของคุณจะไม่ได้รับผลกระทบใดๆ

ระบบต้องมี Swap และค่า vm.swappiness ต้องตั้งไว้ที่ 100 นี่ไม่ใช่คำแนะนำในการปรับแต่งประสิทธิภาพ แต่เป็นข้อกำหนดเชิงฟังก์ชัน การทำ freezing จะทำงานโดยการผลักหน่วยความจำของ sandbox ที่ไม่ได้ใช้งานออกไปยัง swap เนื่องจาก gVisor เก็บหน่วยความจำของ sandbox ไว้ในรูปแบบ shared memory และ kernel จะไม่ทำ swap ข้อมูลที่เป็น shared memory หากใช้ค่า swappiness ตามค่าเริ่มต้น จากการวัดผลของโครงการพบว่าไม่มีการคืนหน่วยความจำเลยที่ค่าเริ่มต้น แต่สามารถคืนได้ถึง 99.5 เปอร์เซ็นต์เมื่อตั้งค่าเป็น 100 โปรดตรวจสอบค่าที่ kernel ใช้งานจริง เนื่องจาก cloud image บางตัวอาจกำหนดค่า vm.swappiness = 0 ไว้ในไฟล์ที่คุณอาจคาดไม่ถึง

sysctl vm.swappiness
swapon --show

sysctl vm.swappiness ควรแสดงผลเป็น vm.swappiness = 100 และ swapon --show ควรแสดงรายการ swapfile หากค่า swappiness แสดงเป็น 0 การทำ freeze ทุกครั้งจะไม่มีผลใดๆ และคุณจะต้องเสียค่าใช้จ่ายสำหรับหน่วยความจำเต็มจำนวนสำหรับทุก sandbox ที่ไม่ได้ใช้งาน

การติดตั้ง Dormice บน Ubuntu

วิธีการติดตั้งตามเอกสารคือการใช้ pipe ไปยัง bash:

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

ให้ดาวน์โหลดสคริปต์มาอ่านก่อนดำเนินการ สคริปต์นี้ทำงานในฐานะ root และปรับแต่งโฮสต์ของคุณ โดยจะติดตั้ง 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 โดยค่าเริ่มต้นคือ 16 ซึ่งถือว่าใช้พื้นที่ดิสก์ค่อนข้างมากสำหรับ VPS ขนาดเล็ก --mirror cn ใช้เปลี่ยนแหล่งดาวน์โหลดไปยัง mirror ที่เข้าถึงได้จากจีนแผ่นดินใหญ่ การรันตัวติดตั้งซ้ำจะเป็นการอัปเกรดโค้ดและแก้ไขค่าที่คลาดเคลื่อน โดยจะไม่เปลี่ยน API token ของคุณ

โค้ดจะถูกติดตั้งใน /opt/dormice, การตั้งค่าใน /etc/dormice/env, ข้อมูล sandbox ใน /var/lib/dormice และคำสั่ง dormice กับ dor จะอยู่ใน /usr/local/bin ตัวติดตั้งจะสร้าง API token ระหว่างการติดตั้งและเขียนลงใน /etc/dormice/env ด้วยสิทธิ์ 600

ไม่มีการระบุเวอร์ชัน (tagged release) สำหรับการติดตั้ง ณ วันที่ 4 สิงหาคม 2026 repository ไม่มี git tags และไม่มี GitHub releases ดังนั้นตัวติดตั้งจะทำการ clone main ซึ่งคุณจะได้โค้ดเวอร์ชันล่าสุดของวันนั้น การล็อกเวอร์ชัน (pinning) จึงทำได้โดยการจดบันทึก commit ที่คุณติดตั้งจริงไว้

git -C /opt/dormice rev-parse HEAD

ให้บันทึก hash ดังกล่าวไว้กับบันทึกการ deploy ของคุณ เมื่อการอัปเกรดทำให้ระบบมีปัญหา commit นั้นจะเป็นหนทางเดียวที่คุณจะย้อนกลับได้ เนื่องจากไม่มีเลขเวอร์ชันให้เรียกใช้

ตัวติดตั้งจะจบการทำงานด้วยการรัน dor doctor ซึ่งเป็นการตรวจสอบโฮสต์แบบอ่านอย่างเดียว โดยจะบูตคอนเทนเนอร์ 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 ลงบนเครื่องด้วย ดังนั้นให้ตรวจสอบว่ามีอะไรกำลังฟังพอร์ตอยู่บ้างก่อนจะสรุปว่าการตั้งค่า firewall เสร็จสิ้นแล้ว

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 หนึ่งครั้ง จากนั้นระบบจะเปลี่ยนเป็น httpOnly session cookie เพื่อไม่ให้ token ถูกเก็บไว้ในที่ที่หน้าเว็บสามารถอ่านได้ หน้า Connect ในคอนโซลจะแสดงตัวอย่างโค้ดสำหรับ client ที่ชี้ไปยัง endpoint ของคุณโดยตรง ซึ่งคุณสามารถคัดลอกไปใช้งานได้ทันที

การสร้างแซนด์บ็อกซ์และการรันโค้ดภายใน

การดำเนินการสร้างแซนด์บ็อกซ์มีเพียงคำสั่งเดียวคือ acquire ซึ่งเป็น idempotent หมายความว่าคีย์เดิมจะส่งคืนแซนด์บ็อกซ์เดิมเสมอ ไม่ว่าจะอยู่ในสถานะสร้างใหม่ ปลุกให้ตื่น เริ่มทำงาน หรือกู้คืนก็ตาม คำสั่งอื่นทั้งหมดจะตอบกลับด้วย 404 หากพบกับคีย์ที่ไม่เคยรู้จักมาก่อน ตัว CLI ของ dor ไม่มีคำสั่ง 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 ไว้ล่วงหน้าแล้ว หากพบข้อผิดพลาดด้านการยืนยันตัวตน แสดงว่าบรรทัดโทเค็นที่คุณคัดลอกมานั้นรวมชื่อตัวแปรติดมาด้วย

การย้ายไฟล์ทำได้ด้วย dor sandbox push my-agent ./script.py ซึ่งจะไปเก็บไว้ที่ /home/user/script.py และใช้ dor sandbox pull my-agent notes.txt เพื่อดึงไฟล์กลับมา คำสั่งจัดการไฟล์แบบเนทีฟจำกัดขนาดไว้ที่ 16 MiB ต่อไฟล์ ในขณะที่การจัดการไฟล์ผ่าน E2B จะใช้วิธีสตรีมข้อมูล ทำให้มีเพียงโควตาพื้นที่ดิสก์ของแซนด์บ็อกซ์เท่านั้นที่เป็นข้อจำกัด

การทำลาย (destroy) เป็นคำสั่งเดียวที่ทำให้ข้อมูลสูญหาย และยังเป็นตัวอย่างที่ดีของอายุโครงการนี้: ทั้งไฟล์ README หลักและทักษะของเอเจนต์ที่มาพร้อมกันต่างระบุถึง dor sandbox destroy <key> ในขณะที่ไฟล์ README ของแพ็กเกจ CLI ระบุถึง dor sandbox release <key> ให้รัน dor sandbox --help บนบิลด์ของคุณเองและยึดตามข้อมูลนั้นแทน

ชี้โค้ด E2B ที่มีอยู่ของคุณไปยังเซิร์ฟเวอร์ของคุณเอง

นี่คือเหตุผลที่คุณควรให้ความสนใจ แพ็กเกจ e2b อย่างเป็นทางการจาก npm ที่ไม่ได้ผ่านการแก้ไขจะสื่อสารกับ 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 token ของคุณที่มีคำนำหน้าเป็น e2b_ ซึ่งเป็นรูปแบบที่เลเยอร์ความเข้ากันได้ (compatibility layer) ต้องการ

ความเข้ากันได้นี้ไม่ใช่แค่ส่วนประกอบจำลอง (stub) การสตรีม stdout และ stderr, การรันคำสั่งเบื้องหลัง, PTY แบบโต้ตอบ, URL สำหรับอัปโหลดและดาวน์โหลดที่มีการลงลายเซ็น, การเฝ้าดูไดเรกทอรี และพอร์ตพร็อกซี ทั้งหมดนี้ถูกทดสอบผ่านแพ็กเกจอย่างเป็นทางการโดยทำงานร่วมกับ Docker และ gVisor daemon จริงๆ ด้วยชุดทดสอบ end-to-end ของโปรเจกต์ มีข้อแตกต่างเล็กน้อยที่คุณควรทราบก่อนย้ายงานจริง:

• การ build template ยังไม่ถูกนำมาใช้งาน Template คือ docker image ที่คุณสร้างขึ้นเองและลงทะเบียนด้วย dor template add โดยที่ Sandbox.create('name') จะทำหน้าที่แก้ไขชื่อเหล่านั้น หากชื่อที่ระบุไม่ได้ลงทะเบียนไว้ ระบบจะส่งค่า 404 กลับมาแทนที่จะทำงานแบบจำลอง
• Sandbox ที่สร้างผ่านอินเทอร์เฟซของ E2B จะมีกำหนดเวลา (deadline) จริง เนื่องจากข้อกำหนดของ E2B จำเป็นต้องมีสิ่งนี้ แต่จะไม่มีการกำหนด deadline สำหรับ sandbox ที่สร้างผ่าน native API
• Sandbox ที่ถูกแช่แข็ง (frozen) จะคงสถานะของกระบวนการไว้และกลับมาทำงานต่อจากจุดเดิม ดังนั้นการหยุดและเริ่มทำงานต่อในที่นี้จึงไม่ใช่การสั่ง stop และ cold start แบบที่คุณอาจคุ้นเคย

สิ่งที่ sandbox ป้องกันและสิ่งที่ไม่สามารถป้องกันได้

gVisor จะดักจับ system call ของ container ในระดับ userspace และประมวลผลด้วยตนเอง ดังนั้นโค้ดที่อยู่ใน sandbox จึงไม่ได้สื่อสารโดยตรงกับ kernel ของโฮสต์ ภายใน sandbox ทุกอย่างจะทำงานในฐานะผู้ใช้ที่ไม่มีสิทธิ์ (unprivileged user) คือ uid 1000 การรวมกันนี้ช่วยจัดการกรณีทั่วไปได้: สคริปต์ที่ถูกสร้างขึ้นมาซึ่งรัน rm -rf /, เขียนข้อมูลจนเต็มดิสก์ หรือทำ fork จนกระทั่งระบบล่ม จะสร้างความเสียหายได้เพียงภายใน sandbox ของตัวเองเท่านั้นและหยุดอยู่แค่นั้น

นี่คือสิ่งที่ sandbox ไม่สามารถป้องกันได้ ซึ่งเป็นหน้าที่ของคุณที่ต้องจัดการ:

• Sandbox สามารถเชื่อมต่อเครือข่ายขาออกได้ โค้ดที่ถูกสร้างขึ้นสามารถดาวน์โหลดสิ่งที่ต้องการและส่งข้อมูลที่พบออกไปได้ การทำ network hardening ของตัวติดตั้งครอบคลุมสองส่วนหลัก: มันจะบล็อก traffic ของ container ที่พยายามเข้าถึง cloud metadata service ที่ 169.254.0.0/16 ซึ่งเป็นจุดที่ cloud ใช้ส่ง instance credentials ให้กับสิ่งที่เข้าถึงได้ และมันจะปิดการสื่อสารระหว่าง container ด้วย "icc": false ใน daemon.json ของ Docker นอกเหนือจากนี้ไม่มีการบล็อกใดๆ โปรดอ่าน sudo iptables -S DOCKER-USER และเพิ่มกฎ DROP ของคุณเองสำหรับช่วง IP ภายในที่ sandbox ไม่ควรเข้าถึง
• Docker จะแทรกกฎของตัวเองไว้หน้า firewall ของคุณ ดังนั้นพอร์ตของ container ที่ถูกเผยแพร่ (published) อาจตอบสนองจากอินเทอร์เน็ตได้แม้ว่า ufw จะระบุว่าปิดอยู่ก็ตาม โปรดอ่าน วิธีที่ Docker เผยแพร่พอร์ตข้าม ufw และ พื้นฐาน ufw firewall สำหรับ VPS ก่อนที่คุณจะเปิดเผยบริการใดๆ บนโฮสต์นี้
• gVisor เป็น kernel ระดับ userspace ไม่ใช่ hypervisor นี่เป็นการแลกเปลี่ยนที่ตั้งใจไว้ เพราะการทำ freezing จำเป็นต้องให้ sandbox เป็น process และการบังคับใช้ KVM จะทำให้ไม่สามารถติดตั้งในสภาพแวดล้อมทั่วไปได้ หากโมเดลภัยคุกคามของคุณต้องการการทำ hardware virtualisation ให้ใช้การแยกส่วนระดับ Firecracker และยอมรับต้นทุนในการดำเนินงานที่ตามมา
• API token คือขอบเขตความปลอดภัยทั้งหมดในฝั่ง client สิ่งใดก็ตามที่ถือครอง DORMICE_API_TOKEN สามารถสร้าง อ่าน และทำลาย sandbox ทุกตัวบนเครื่องได้ ให้สิทธิ์ process ของ agent เป็น ผู้ใช้ที่มีสิทธิ์น้อยที่สุดบน VPS และปฏิบัติต่อ token เช่นเดียวกับที่คุณปฏิบัติต่อ SSH key แนวทางปฏิบัติจาก การรัน Claude Code บน VPS อย่างปลอดภัย สามารถนำมาปรับใช้ได้โดยตรง

ตัว daemon เองรันในฐานะ root บนโฮสต์ของคุณ gVisor ปกป้องโฮสต์จากโค้ดภายใน sandbox แต่ไม่มีสิ่งใดปกป้องโฮสต์จากตัว daemon หรือจากผู้ที่ถือครอง token ของมัน ดังนั้นเครื่องที่รัน Dormice ควรเป็นเครื่องที่ทำหน้าที่นั้นเพียงอย่างเดียว หาก agent ของคุณเข้าถึงเครื่องมือผ่าน MCP (model context protocol) ด้วย ให้แยก MCP servers เหล่านั้นไว้บน VPS อีกเครื่อง ด้วยเหตุผลเดียวกัน

Sandbox จำนวนเท่าใดที่รองรับได้ในหน่วยความจำ 4 GB และ 8 GB?

มีปัจจัยสองประการที่ใช้หน่วยความจำ คือ ค่าพื้นฐานของโฮสต์เอง และชุดข้อมูลการทำงาน (working set) ของ sandbox แต่ละตัวที่กำลังทำงานอยู่ ให้สำรองหน่วยความจำไว้ประมาณ 1 GB สำหรับ Ubuntu, Docker และ daemon จากนั้นให้นำส่วนที่เหลือหารด้วยปริมาณการใช้งานจริงของ sandbox หนึ่งตัว Sandbox ที่รันสคริปต์ Python ซึ่งอ่านไฟล์เพียงไม่กี่ไฟล์จะใช้หน่วยความจำประมาณ 200 ถึง 300 MiB ส่วน 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
  }
]

VPS ขนาด 4 GB สามารถรองรับ sandbox ที่ทำงานพร้อมกันได้ประมาณ 6 ตัว หากแต่ละตัวใช้หน่วยความจำ 512 MiB หรือ 3 ตัว หากแต่ละตัวใช้หน่วยความจำเต็ม 1 gibibyte สำหรับ VPS ขนาด 8 GB จะรองรับได้เพิ่มขึ้นเป็น 14 และ 7 ตัวตามลำดับ ค่าเหล่านี้เป็นขีดจำกัดสำหรับการทำงานพร้อมกันและเป็นการคำนวณเชิงคณิตศาสตร์ไม่ใช่ผลการทดสอบประสิทธิภาพ ดังนั้นควรตรวจสอบ free -m ในขณะที่โหลดงานของคุณกำลังทำงานอยู่

Sandbox ที่ถูกแช่แข็ง (frozen) จะถูกจำกัดด้วย swap แทนที่จะเป็น RAM ซึ่งเป็นจุดประสงค์หลักของการออกแบบนี้ Sandbox ที่ถูกแช่แข็งซึ่งเคยใช้หน่วยความจำ 1 gibibyte จะคงข้อมูลไว้ใน swap ในปริมาณใกล้เคียงกันและแทบไม่ใช้หน่วยความจำหลัก ดังนั้น swapfile ขนาด 16 GB ตามค่าเริ่มต้นของตัวติดตั้งจึงสามารถรองรับ sandbox เหล่านี้ได้ประมาณ 16 ตัว หากเกินกว่านั้น sandbox จำเป็นต้องเข้าสู่สถานะหยุดทำงาน (stopped) ซึ่งจะใช้เพียงพื้นที่ดิสก์เท่านั้น พื้นที่ดิสก์คือข้อจำกัดที่แท้จริงในระยะยาว เนื่องจาก sandbox แต่ละตัวจะเก็บระบบไฟล์ของตนเองไว้ และ agent จำนวนหลายสิบตัวที่แต่ละตัวมีไดเรกทอรี node_modules จะทำให้พื้นที่จัดเก็บข้อมูลขนาดเล็กเต็มก่อนที่หน่วยความจำจะกลายเป็นประเด็นสำคัญเสียอีก

การหยุดชั่วคราว การหยุดทำงาน และการจัดเก็บถาวร: การตั้งค่าวงจรชีวิต

ค่าเริ่มต้นคือการหยุดชั่วคราว (freeze) หลังจากไม่มีการใช้งาน 10 นาที การหยุดทำงาน (stop) หลังจาก 3 วัน และการจัดเก็บถาวร (archive) หลังจาก 7 วันหากมีการกำหนดค่าการจัดเก็บไว้ การตั้งค่า stopAfterSeconds ให้เป็น null จะทำให้คุณได้ agent ที่ทำงานอยู่ตลอดเวลา: มันอาจหยุดชั่วคราวเมื่อไม่มีการใช้งาน แต่จะไม่เริ่มทำงานใหม่จากสถานะ cold start

การจัดเก็บถาวรเป็นทางเลือกเสริม และ daemon จะแจ้งสถานะตามจริง ให้ตั้งค่าตัวแปร DORMICE_S3_* ทั้งสี่รายการ แล้วดิสก์ของ sandbox ที่หยุดทำงานจะถูกบีบอัดด้วย tar และ zstd จากนั้นจะถูกส่งไปยัง bucket ที่รองรับ S3 และลบข้อมูลออกจากเครื่องต้นทาง bucket ดังกล่าวสามารถเป็น MinIO bucket ที่คุณโฮสต์เอง บนเครื่องอื่นของคุณได้ หากไม่ตั้งค่าตัวแปรเหล่านี้ sandbox จะคงสถานะหยุดทำงานไว้ตลอดไป และนโยบายที่ร้องขอให้จัดเก็บถาวรจะถูกปฏิเสธแทนที่จะถูกละเลยโดยไม่มีการแจ้งเตือน การกู้คืนข้อมูลจะแสดงสถานะให้เห็นแทนที่จะทำงานเงียบๆ: การเรียกใช้งาน (acquire) ครั้งถัดไปจะตอบกลับทันทีด้วยสถานะกำลังกู้คืนและค่าความคืบหน้า จากนั้นจะเปลี่ยนเป็นพร้อมใช้งานเมื่อดิสก์ถูกกู้คืนกลับมาเรียบร้อยแล้ว

ควรเริ่มใช้งานแล้วหรือยัง?

คำตอบตรงไปตรงมาคือ: อย่าใช้กับงานใดก็ตามที่คุณไม่สามารถสร้างใหม่ได้ commit แรกใน repository ลงวันที่ 8 กรกฎาคม 2026 ณ วันที่ 4 สิงหาคม 2026 โครงการนี้มี 446 stars, 37 forks, ใช้สัญญาอนุญาต Apache-2.0 และยังไม่มีการทำ tagged release ใดๆ ทั้งสิ้น บรรทัดสถานะใน README ระบุชัดเจนว่าไม่มีส่วนใดที่พร้อมสำหรับการใช้งานจริง (production)

การรวมกันของปัจจัยเหล่านี้สร้างความเสี่ยงในรูปแบบเฉพาะ โค้ดมีการเปลี่ยนแปลงอยู่ตลอดเวลาเนื่องจากตัวติดตั้งติดตาม main อินเทอร์เฟซยังอยู่ในช่วงปรับเปลี่ยน ซึ่งเป็นเหตุผลว่าทำไมคำสั่ง delete ถึงมีชื่อเรียกต่างกันในสองไฟล์ภายใน repository เดียวกัน และโครงการที่มีอายุเพียงสี่สัปดาห์อาจหยุดพัฒนาลงได้ทุกเมื่อ เนื่องจากไม่มีข้อกำหนดในสัญญาอนุญาตใดที่บังคับให้ผู้พัฒนาต้องทำต่อ

สิ่งที่ทำให้ความเสี่ยงนี้ยังพอรับได้คือความเข้ากันได้กับ E2B แอปพลิเคชันของคุณสื่อสารผ่านโปรโตคอลที่มีการใช้งานจริงรองรับอยู่เบื้องหลัง ดังนั้นหาก Dormice หยุดชะงัก คุณเพียงแค่เปลี่ยน URL สองจุดก็สามารถทำงานต่อได้ ให้เขียน agent ของคุณโดยอิงกับพื้นฐานของ E2B แทนที่จะใช้ native API เพื่อรักษาช่องทางสำรองนี้ไว้ แพ็กเกจ @dormice/sdk แบบ native ยังไม่มีบน npm ดังนั้นการใช้งานจึงหมายถึงการ build จาก repository ซึ่งเป็นเหตุผลประการที่สองที่ควรเริ่มต้นด้วยแนวทางที่เข้ากันได้

ให้รันในสภาพแวดล้อมที่คุณสามารถสูญเสียข้อมูลได้โดยไม่กระทบงานหลัก สร้าง host ขึ้นใหม่จากสคริปต์ เก็บ token ให้ห่างจาก prompt และ commit ทุกครั้ง และสำรองข้อมูลใดก็ตามที่มีค่าออกจาก sandbox ตามตารางเวลาสำรองข้อมูลของคุณเอง

FAQ

Dormice พร้อมสำหรับการใช้งานจริง (production) หรือยัง?

ยังไม่พร้อม และตัวโครงการเองก็ได้ระบุไว้เช่นนั้น สถานะใน README ระบุว่ายังไม่มีส่วนใดที่พร้อมสำหรับ production และ ณ วันที่ 4 สิงหาคม 2026 ตัว repository มีอายุเพียงประมาณสี่สัปดาห์ ยังไม่มี git tags และยังไม่มีการออก releases ดังนั้นจึงไม่มีหมายเลขเวอร์ชันให้ระบุ (pin) ตัวติดตั้งจะทำการ clone สาขา main ซึ่งหมายความว่าการรันแต่ละครั้งคุณจะได้ commit ล่าสุดเสมอ ให้บันทึก git -C /opt/dormice rev-parse HEAD ไว้หลังการติดตั้งทุกครั้ง และเก็บข้อมูลที่มีค่าไว้ภายนอก sandbox

Dormice แตกต่างจากการให้ VM แบบใช้แล้วทิ้งแก่ agent อย่างไร?

VM แบบใช้แล้วทิ้งคือเครื่องที่เข้าถึงผ่าน SSH ซึ่งคุณสร้างขึ้นเพื่อใช้งานในเซสชันหนึ่งแล้วลบออกหลังจากนั้น ส่วน Dormice คือ API สำหรับการประมวลผล โดยโปรแกรมของคุณจะเรียกใช้คำสั่ง acquire ตามด้วย exec แล้วรับค่า stdout และ exit code กลับมาโดยไม่มี shell session คั่นกลาง VM เหมาะสำหรับมนุษย์หรือ agent ที่ต้องการใช้งานคอมพิวเตอร์ทั้งเครื่องในช่วงเวลาหนึ่ง ส่วน Dormice เหมาะสำหรับแอปพลิเคชันที่รันโค้ดที่สร้างขึ้นใหม่หลายครั้งต่อวันและไม่ต้องการขั้นตอนการตั้งค่าและลบเครื่องทิ้งในทุกครั้งที่รัน

E2B SDK อย่างเป็นทางการใช้งานได้โดยไม่ต้องแก้ไขโค้ดจริงหรือ?

ได้ โดยต้องมีการปรับเปลี่ยนการตั้งค่า ให้ชี้ apiUrl และ sandboxUrl ไปที่ /e2b/api และ /e2b/envd บน daemon ของคุณ และส่ง Dormice token โดยมี prefix เป็น e2b_ ในฐานะ API key การรันคำสั่ง, PTY sessions, การโอนย้ายไฟล์, signed URLs และ port proxy ทั้งหมดนี้ครอบคลุมโดยชุดทดสอบ end-to-end ของโครงการที่รันผ่านแพ็กเกจอย่างเป็นทางการ ส่วนการสร้าง template เป็นจุดที่ยังขาดอยู่ คือ e2b template build ยังไม่ได้ถูกนำมาใช้งาน ดังนั้น template จึงเป็น docker image ที่คุณต้องสร้างและลงทะเบียนด้วย dor template add

VPS ขนาด 4 GB สามารถรองรับ sandbox ได้กี่ตัว?

สามารถรองรับ sandbox ที่ทำงานอยู่พร้อมกันได้ประมาณ 6 ตัว หากแต่ละ sandbox ใช้หน่วยความจำ 512 MiB หรือ 3 ตัว หากแต่ละตัวใช้หน่วยความจำเต็ม 1 gibibyte โดยหักลบหน่วยความจำประมาณ 1 GB สำหรับระบบปฏิบัติการ, Docker และ daemon ออกแล้ว สำหรับ sandbox ที่ถูกแช่แข็ง (frozen) จะถูกจำกัดด้วย swap แทน ดังนั้น swapfile ขนาด 16 GB ที่ตัวติดตั้งกำหนดไว้เป็นค่าเริ่มต้นจะรองรับ sandbox ได้ประมาณ 16 ตัว โดยที่แต่ละตัวใช้หน่วยความจำ 1 gibibyte ให้วัดค่าด้วยตัวคุณเองโดยใช้ free -m ภายใต้ภาระงานจริง เนื่องจาก sandbox ที่รันชุดทดสอบจะใช้ทรัพยากรมากกว่า sandbox ที่รันสคริปต์ขนาดเล็กหลายเท่า

ทำไม Dormice ถึงต้องการให้ตั้งค่า vm.swappiness เป็น 100?

การแช่แข็ง (freezing) sandbox หมายถึงการผลักหน่วยความจำที่ไม่ได้ใช้งานออกไปยัง swap โดย gVisor จะเก็บหน่วยความจำของ sandbox ไว้ในรูปแบบ shared memory และ kernel ของ Linux จะไม่ยอมทำ swap ให้กับ shared memory หากใช้ค่า swappiness เริ่มต้น ดังนั้นหากใช้ค่าเริ่มต้น การแช่แข็งจะไม่สามารถคืนพื้นที่หน่วยความจำได้เลยและ sandbox จะยังคงใช้หน่วยความจำเต็มจำนวน โครงการได้ทำการวัดผลพบว่าไม่มีการคืนพื้นที่เลยที่ค่าเริ่มต้น แต่มีการคืนพื้นที่ถึง 99.5 เปอร์เซ็นต์เมื่อตั้งค่าเป็น 100 ให้ตรวจสอบค่าที่ใช้งานจริงด้วย sysctl vm.swappiness แทนการอ่านจากไฟล์ config เนื่องจาก cloud image บางตัวอาจตั้งค่าเริ่มต้นไว้ที่ 0