SSD Nodes Learn 🎉 VPS kutoka $5.50/mwezi
Mwongozo Matt ConnorNa Matt Connor · Imeboreshwa 2026-08-13

Jinsi ya kujiendeshea Dormice kwa ajili ya agent sandboxes

Dormice inakuwezesha kuendesha E2B-compatible sandboxes kwenye VPS yako mwenyewe. Jifunze jinsi ya kusakinisha daemon, kutekeleza msimbo kwa usalama, na kusimamia rasilimali.

Dormice ni nini, na si nini

Dormice ni sandbox ya wakala inayojiendesha (self-hosted): ni daemon moja kwenye Linux VPS unayomiliki, ambayo msimbo wa wakala wako huita kupitia HTTP ili kuendesha msimbo usioaminika ndani ya kontena lililotengwa. Programu yako huomba sandbox kwa jina, hupata sandbox ileile bila kujali hali iliyokuwa nayo, huendesha amri ndani yake, na kusoma matokeo. Sandbox hii ni rasilimali ya programu, si mashine unayoingia (login).

Hii ni tofauti na kumpa wakala kompyuta nzima. VM ya muda kwa ajili ya wakala wa uandishi wa msimbo ni sanduku unaloliingia kupitia SSH, unaloliacha wakala aliharibu, kisha unalifuta. Dormice inakaa ngazi moja chini: ni API ya utekelezaji ambayo programu yako huita inapokuwa tayari na msimbo na inahitaji mahali salama pa kuuendesha. Tumia VM ya muda wakati mashine nzima ndiyo kitengo cha kazi. Tumia Dormice wakati wito mmoja wa exec ndio kitengo cha kazi, na unataka mamia ya wito kwa siku bila kuwa na mamia ya VM.

Mradi huu unajiita kuwa unaoana na E2B. E2B ni huduma ya sandbox inayopangishwa (hosted) ambayo maktaba yake ya mteja tayari inatumiwa na mifumo mingi ya wakala. Dormice hutoa itifaki ileile chini ya viambishi awali vyake vya URL, hivyo programu iliyoandikwa kwa kutumia kifurushi rasmi cha e2b itaendelea kufanya kazi unapoelekeza kwenye sanduku lako mwenyewe. Msimbo wa programu haubadiliki. URL mbili na kiambishi awali kimoja cha API key ndivyo vinavyobadilika.

Maana ya "SQLite ya sandboxes za mawakala" katika utendaji

SQLite ni database unayoiingiza ndani ya programu badala ya huduma unayoiendesha, na Dormice inachukua ulinganifu huo moja kwa moja. Daemon moja, faili moja la SQLite kwa ajili ya leja, na port moja ya TCP. Hakuna Kubernetes, hakuna database tofauti, na hakuna scheduler. Daemon huweka lock kando ya leja yake na hukataa kuanza wakati leja hiyo na mashine inayopatikana haviwezi kuoana, hivyo hali ya split brain haiwezi kutokea kimyakimya. Muundo wake ni wa mashine moja. Ikiwa unahitaji kundi la mashine nyingi, README inakuambia wazi uchague kitu kingine, na unapaswa kusikiliza.

Nusu ya pili ya wazo hili inahusu gharama. Sandbox inayohudumiwa (hosted) hutoza ada kwa kila sekunde inayokuwepo, kwa hivyo sandboxes za aina hiyo zimeundwa ili zitupewe. Dormice inaendeshwa kwenye maunzi (hardware) ambayo tayari unayagharamia, kwa hivyo sandboxes zake ni za kudumu na huwa nafuu kadiri zinavyokaa bila kutumika. Sandbox hupoa hatua kwa hatua: inafanya kazi (active), kisha inaganda (frozen), kisha inasimama (stopped), na hatimaye inahifadhiwa (archived). Kitendo chochote cha kuipata (acquire) huirejesha juu kutoka hatua yoyote iliyofikia.

Kugandisha (freezing) ni sehemu inayostahili kueleweka, kwa sababu ndiyo inayofanya uwezekano wa kuhifadhi sandbox ya kila wakala milele kuwa nafuu. Hizi ni takwimu zilizochapishwa na mradi wenyewe, zilizopimwa kwenye maunzi yake na siyo yako.

ChartOne idle sandbox before and after freezing, figures published by the project
The data behind this chart
[
  {
    "label": "Active, holding 1 GiB",
    "resident_memory_mib": 1024,
    "wake_ms": 0
  },
  {
    "label": "Frozen",
    "resident_memory_mib": 5,
    "wake_ms": 50
  }
]

Sandbox isiyo na kazi inayoshikilia 1024 MiB ya kumbukumbu hushuka hadi 5 MiB ya kumbukumbu resident mara tu inapogandishwa, na hurudi katika hali ya kawaida ndani ya takriban 50 ms. Michakato husitishwa na kurejea pale ilipoishia, kwa hivyo wakala wa muda mrefu huhifadhi hali yake ya shell na kazi yake iliyokamilika nusu wakati wa mchakato wa kugandisha. Ijaribu kwenye host yako mwenyewe kabla ya kupanga uwezo wa mfumo wako kuizunguka.

Mahitaji ya seva kabla ya usakinishaji

Seva lazima iwe Ubuntu au Debian kwenye x86_64, na kisakinishi kinahitaji ruhusa za root. Daemon huendelea kutumia root wakati wa utekelezaji kwa sababu hufanya loop mounts na kuandika kwenye cgroups.

Sandboxes huendeshwa chini ya Docker kwa kutumia gVisor (runtime ya container inayoweka kernel ya userspace kati ya container na kernel ya seva), ambayo hutoa runsc runtime inayotumiwa na kila sandbox. Node 22 au toleo jipya zaidi huendesha daemon, na kisakinishi huleta nakala yake yenyewe, hivyo Node ya mfumo wako haitaathiriwa.

Swap lazima iwepo, na vm.swappiness lazima iwe 100. Hii si ushauri wa kuboresha utendaji, ni hitaji la kiufundi ili mfumo ufanye kazi. Ufanyaji kazi wa freezing hutegemea kusukuma kumbukumbu ya sandbox iliyo idle kwenda kwenye swap; gVisor huhifadhi kumbukumbu ya sandbox kama shared memory, na kernel haitafanya swap ya shared memory kwa swappiness ya kawaida. Mradi huu ulipima 0 bytes zilizorejeshwa kwa thamani ya kawaida na asilimia 99.5 zilizorejeshwa kwa 100. Hakikisha thamani ambayo kernel inatumia kweli, kwa sababu baadhi ya cloud images husafirisha vm.swappiness = 0 kwenye faili ambalo hutaweza kulifikiria kulisoma.

sysctl vm.swappiness
swapon --show

sysctl vm.swappiness inapaswa kuonyesha vm.swappiness = 100, na swapon --show inapaswa kuorodhesha swapfile. Ikiwa swappiness inaonyesha 0, kila freeze itashindwa kufanya kazi na kukuacha ukilipia kumbukumbu kamili kwa kila sandbox iliyo idle.

Kusakinisha Dormice kwenye Ubuntu

Usakinishaji uliothibitishwa unahusisha kutumia pipe moja kwenda kwenye bash:

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

Ipakue na uisome kabla ya kuiendesha. Hati hii huendeshwa kama root na hufanya mabadiliko kwenye seva yako: husakinisha Docker ikiwa haipo, hupakua gVisor na Caddy kwa kuthibitisha checksum, hutengeneza swapfile, huandika units za systemd, na huongeza sheria za 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 huweka ukubwa wa swapfile na thamani yake ya kawaida ni 16, ambayo ni nafasi kubwa ya diski kwa VPS ndogo. --mirror cn hubadilisha upakuaji kwenda kwenye vioo (mirrors) vinavyoweza kufikiwa kutoka China bara. Kuendesha kisakinishi tena huboresha msimbo na kurekebisha hitilafu, na hakibadilishi kamwe API token yako.

Msimbo huwekwa kwenye /opt/dormice, usanidi kwenye /etc/dormice/env, data ya sandbox kwenye /var/lib/dormice, na amri za dormice na dor kwenye /usr/local/bin. Kisakinishi hutengeneza API token wakati wa usakinishaji na kuiandika kwenye /etc/dormice/env kwa mode 600.

Hakuna toleo lililowekewa tag (tagged release) la kusakinisha. Kufikia tarehe 4 Agosti 2026, hazina (repository) haina git tags wala GitHub releases, kwa hivyo kisakinishi hufanya clone ya main na unapata chochote kilichoongezwa asubuhi hiyo. Kwa hiyo, kuweka toleo maalum (pinning) kunamaanisha kuandika commit uliyosakinisha.

git -C /opt/dormice rev-parse HEAD

Hifadhi hash hiyo pamoja na maelezo yako ya deploy. Wakati uboreshaji unaposababisha tatizo, commit hiyo ndiyo njia yako pekee ya kurudi nyuma, kwa sababu hakuna namba ya toleo ya kuomba.

Kisakinishi humalizia kwa kuendesha dor doctor, ukaguzi wa seva wa kusoma pekee (read-only) ambao huwasha containers halisi za gVisor ili kuthibitisha kuwa runtime inafanya kazi badala ya kuamini orodha ya vifurushi. Iendeshe tena wakati wowote daemon inapofanya kazi vibaya.

sudo dor doctor
systemctl is-active dormice

systemctl is-active dormice inapaswa kuchapisha active. Ikiwa inachapisha failed, journalctl -u dormice -n 50 ina sababu ya tatizo hilo, na kushindwa kuanza kwa kawaida husababishwa na swap au sharti la gVisor badala ya daemon yenyewe.

Kisakinishi pia huweka Caddy kwenye seva, kwa hivyo angalia nini kinasikiliza (listening) kabla ya kuamua kuwa kazi ya firewall imekamilika.

sudo ss -lntp

Daemon hufunga 127.0.0.1:3676 na haina mpangilio wa kubadilisha hilo, kwa muundo wake. Kuifikia kutoka kwenye laptop yako ni kitendo cha makusudi, na njia rahisi ni kutumia SSH tunnel.

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

Tunnel ikiwa wazi, http://127.0.0.1:3676/console kwenye laptop yako ndiyo web console. Ingia na token mara moja na itakuwa httpOnly session cookie, kwa hivyo token yenyewe haihifadhiwi kamwe mahali ambapo ukurasa unaweza kuisoma. Ukurasa wa Connect hapo huchapisha vipande vya msimbo wa mteja (client snippets) vilivyoelekezwa tayari kwenye endpoint yako mwenyewe.

Tengeneza sandbox na uendeshe msimbo ndani yake

Operesheni moja hutengeneza sandbox: acquire. Ni ya aina ya idempotent, kwa hivyo ufunguo uleule hurejesha sandbox ileile kila wakati, kwa kuitengeneza, kuiamsha, kuianzisha au kuirejesha inavyohitajika. Kitenzi kingine chochote hujibu 404 kwa ufunguo ambao haujawahi kuona. CLI ya dor haina kitenzi cha acquire, kwa hivyo sandbox yako ya kwanza hutoka kwenye console au kutoka kwa maktaba ya mteja (client library).

Njia ya console ndiyo ya haraka zaidi. Fungua /console kupitia tunnel na utengeneze sandbox yenye jina my-agent. CLI kisha itafanya kazi kwenye sandbox hiyo.

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 huorodhesha kila sandbox pamoja na hali yake ya mzunguko wa maisha (lifecycle state), ambayo ndiyo njia unayotumia kufuatilia sandbox ikishuka kutoka hali ya active hadi frozen. dor sandbox exec huchapisha toleo la Python 3.12, kwa sababu image ya kawaida ni Ubuntu 24.04 ikiwa na Python 3.12, Node 24, git na ripgrep zilizokwisha kusakinishwa. Hitilafu ya uthibitishaji (authentication error) badala yake inamaanisha kuwa mstari wa token uliounakili ulijumuisha jina la variable.

Faili husogezwa kwa kutumia dor sandbox push my-agent ./script.py, ambayo huweka faili kwenye /home/user/script.py, na dor sandbox pull my-agent notes.txt huleta faili moja kurudi. Vitenzi vya asili vya faili vina kikomo cha 16 MiB kwa kila faili, wakati mfumo wa faili wa E2B hutiririsha data na kuruhusu quota ya diski ya sandbox kuwa kikomo pekee.

Kuharibu (destroying) ndicho kitenzi pekee kinachopoteza data, na pia ni mfano mzuri wa umri wa mradi huu: README kuu na ujuzi wa wakala (agent skill) uliounganishwa vyote huandika dor sandbox destroy <key>, wakati README ya kifurushi cha CLI huandika dor sandbox release <key>. Endesha dor sandbox --help kwenye build yako mwenyewe na uamini hilo badala yake.

Elekeza msimbo wako wa sasa wa E2B kwenye seva yako mwenyewe

Hii ndiyo sababu ya kujali. Kifurushi rasmi cha e2b kutoka npm, bila kubadilishwa, huwasiliana na Dormice. Endesha hii kutoka kwenye laptop yako huku SSH tunnel ikiwa wazi, ili hakuna kitu kipya kinachoweza kusikiliza kwenye seva.

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

Uendeshaji mzuri hutoa exit code 0 na 42. API key ni token yako ya Dormice ikiwa na kiambishi awali cha e2b_ mbele yake, ambayo ndiyo umbo linalotarajiwa na tabaka la utangamano (compatibility layer).

Utangamano huu si wa muda mfupi tu. Utiririshaji wa stdout na stderr, amri za usuli (background commands), PTY shirikishi, URL zilizotiwa saini za kupakia na kupakua, ufuatiliaji wa saraka (directory watching) na port proxy vyote hutekelezwa kupitia kifurushi rasmi dhidi ya Docker na gVisor daemon halisi na suite ya mwisho-hadi-mwisho ya mradi huu. Kuna tofauti chache unazopaswa kuzingatia kabla ya kuhama na kitu chochote cha kweli:

  • Ujenzi wa template haujatekelezwa. Template ni docker image unayojijengea mwenyewe na kuisajili na dor template add, na Sandbox.create('name') huitatua. Jina lisilosajiliwa hurejesha 404 badala ya kujifanya lipo.
  • Sandboxes zilizoundwa kupitia mfumo wa E2B hupata muda wa mwisho (deadlines) halisi, kwa sababu semantiki za E2B zinazihitaji. Muda wa mwisho hauwekwi kamwe kwenye sandboxes zilizoundwa kupitia API asilia.
  • Sandbox iliyogandishwa (frozen) huhifadhi michakato yake na kuirejesha katikati ya safari, kwa hivyo kusitisha na kurejesha hapa si sawa na kusimamisha na kuanza upya (cold start) ambayo huenda umeizoea.

Mambo ambayo sandbox inazuia, na yale isiyozuia

gVisor huzuia system calls za container katika userspace na kuzihudumia yenyewe, hivyo msimbo (code) uliopo kwenye sandbox hauwasiliani moja kwa moja na kernel ya seva yako. Ndani ya sandbox, kila kitu huendeshwa kama mtumiaji asiye na upendeleo (unprivileged user), uid 1000. Mchanganyiko huo hushughulikia hali ya kawaida: hati (script) iliyozalishwa inayotekeleza rm -rf /, inayojaza diski, au inayofanya fork hadi kitu kishindwe kufanya kazi, huharibu sandbox yake yenyewe na kuishia hapo.

Haya ndiyo mambo ambayo haizuii. Kila moja ya haya ni jukumu lako.

  • Sandbox ina mtandao wa nje unaofanya kazi. Msimbo uliozalishwa unaweza kupakua chochote kinachotaka na kutuma chochote kinachokipata. Uimarishaji wa mtandao wa kisakinishi (installer) unashughulikia mambo mawili mahususi: unakata trafiki ya container kwenda kwenye huduma ya metadata ya cloud katika 169.254.0.0/16, ambapo cloud hutoa vitambulisho vya instance kwa chochote kinachoweza kuifikia, na unazima trafiki ya container-kwa-container kwa kutumia "icc": false katika daemon.json ya Docker. Hakuna kingine kinachozuiwa. Soma sudo iptables -S DOCKER-USER na uongeze sheria zako za DROP kwa ajili ya masafa ya private ambayo sandbox haina sababu ya kuyafikia.
  • Docker huweka sheria zake mbele ya firewall yako, kwa hivyo port ya container iliyochapishwa inaweza kujibu kutoka kwenye Internet wakati ufw ikisisitiza kuwa imefungwa. Soma jinsi Docker inavyochapisha ports kupita ufw na misingi ya ufw firewall kwa VPS kabla ya kufichua chochote kwenye seva hii.
  • gVisor ni kernel ya userspace, si hypervisor. Hiyo ni biashara ya makusudi, kwa sababu kufungia (freezing) kunahitaji sandboxes ziwe michakato (processes), na kuhitaji KVM kungezuia kitu hicho kusakinishwa popote. Ikiwa mtindo wako wa vitisho unahitaji virtualisation ya maunzi (hardware), tumia isolation ya daraja la Firecracker na ukubali gharama za kiutendaji zinazoambatana nayo.
  • API token ndiyo mpaka mzima wa usalama kwa upande wa mteja. Chochote kinachoshikilia DORMICE_API_TOKEN kinaweza kuunda, kusoma na kuharibu kila sandbox kwenye mashine. Ipe mchakato wa agent mtumiaji mwenye upendeleo mdogo (least privilege user) kwenye VPS na uichukulie token hiyo kama unavyochukulia SSH key. Mazoea kutoka kwa kuendesha Claude Code kwa usalama kwenye VPS yanahamishika moja kwa moja.

Daemon yenyewe huendeshwa kama root kwenye seva yako. gVisor hulinda seva dhidi ya msimbo uliopo ndani ya sandbox, na hakuna kinacholinda seva dhidi ya daemon au dhidi ya yeyote anayeshikilia token yake. Kwa hivyo, mashine inayoendesha Dormice inapaswa kuwa mashine inayofanya kazi hiyo pekee. Ikiwa agent wako pia anafikia zana kupitia MCP (model context protocol), weka MCP servers hizo kwenye VPS tofauti kwa sababu hiyo hiyo.

Sandboxes ngapi zinafaa katika 4 GB na 8 GB?

Mambo mawili hutumia kumbukumbu: msingi wa seva yenyewe, na kiasi cha kumbukumbu kinachotumiwa na kila sandbox inayofanya kazi kwa wakati huo. Tenga takriban 1 GB kwa ajili ya Ubuntu, Docker na daemon, kisha gawanya kiasi kinachobaki kwa matumizi halisi ya sandbox moja. Sandbox inayotumia script ya Python inayosoma faili chache hutumia takriban 200 hadi 300 MiB. Sandbox inayotumia compiler au suite kamili ya majaribio inaweza kuzidi gibibyte moja.

ChartConcurrent sandboxes by host RAM, arithmetic after a 1 GB host reserve
The data behind this chart
[
  {
    "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 ya 4 GB inaweza kuhimili 6 sandboxes kwa wakati mmoja ikiwa kila moja inatumia 512 MiB, au 3 ikiwa kila moja inatumia gibibyte kamili. VPS ya 8 GB inaweza kuhimili 14 na 7. Hivi ni viwango vya juu vya kazi za wakati mmoja, na ni makadirio ya kihisabati badala ya kipimo cha utendaji, kwa hivyo fuatilia free -m wakati mzigo wako wa kazi unapoendelea.

Sandboxes zilizogandishwa (frozen) hupunguzwa na swap badala ya RAM, jambo ambalo ndilo lengo kuu la usanifu huu. Sandbox iliyogandishwa ambayo ilikuwa ikitumia gibibyte moja huweka kiasi hicho kwenye swap na karibu haitumii chochote kwenye RAM, kwa hivyo swapfile ya 16 GB iliyowekwa na kisakinishi inaweza kuhifadhi takriban 16 kati ya hizo. Baada ya hapo, zinahitaji kufikia hatua ya kusimamishwa (stopped), ambapo hutumia diski pekee. Diski ndiyo kikomo halisi cha muda mrefu hapa: kila sandbox huhifadhi mfumo wake wa faili, na mawakala kadhaa kila mmoja akiwa na saraka ya node_modules watajaza diski ndogo muda mrefu kabla ya kumbukumbu kuwa tatizo.

Kugandisha, kusimamisha, kuhifadhi: vigezo vya mzunguko wa maisha

Mipangilio chaguo-msingi ni kugandisha baada ya dakika 10 za kutofanya kazi, kusimamisha baada ya siku 3, na kuhifadhi baada ya siku 7 wakati uhifadhi umesanidiwa. Kuweka stopAfterSeconds kuwa null hukupa wakala anayekaa kwenye kumbukumbu (resident agent): anaweza kuganda anapokuwa haitumiki, na hawezi kamwe kuanza kutoka hali ya baridi (cold start).

Uhifadhi ni wa hiari, na daemon huwa wazi kuhusu hilo. Weka vigezo vinne vya DORMICE_S3_* na diski ya sandbox iliyosimamishwa itafungashwa kwa kutumia tar na zstd, itatumwa kwenye bucket yoyote inayooana na S3, na nafasi yake itaachiliwa kwenye seva. Bucket hiyo inaweza kuwa bucket ya MinIO unayojiendeshea mwenyewe kwenye mashine nyingine yako. Acha vigezo hivyo bila kuwekwa na sandboxes zitabaki katika hali ya kusimamishwa milele, na sera inayoomba kuhifadhi itakataliwa badala ya kupuuzwa kimya kimya. Urejeshaji huonekana badala ya kuwa wa siri: ombi linalofuata la acquire hujibu mara moja likiwa na hali ya kurejesha (restoring status) na thamani ya maendeleo, kisha hubadilika na kuwa tayari (ready) mara tu diski inapokuwa imerejea.

Je, unapaswa kuitumia sasa?

Jibu la moja kwa moja: hapana kwa kitu chochote ambacho huwezi kukijenga upya. Commit ya kwanza kwenye repository hii ina tarehe 8 Julai 2026. Kufikia tarehe 4 Agosti 2026, ina nyota 446, forks 37, leseni ya Apache-2.0, na hakuna release yoyote iliyowekewa tag. Mstari wa hali katika README yenyewe unasema hakuna kitu hapo kilicho tayari kwa matumizi ya uzalishaji (production).

Mchanganyiko huo una aina maalum ya hatari. Msimbo (code) unabadilika chini yako, kwa sababu kisakinishi kinafuatilia main. Kiolesura bado kinabadilika, na ndiyo sababu kitenzi cha kufuta (delete) kina majina mawili tofauti katika faili mbili ndani ya repository moja. Na mradi wenye umri wa wiki nne unaweza kusimama tu, kwa kuwa hakuna kifungu cha leseni kinachomlazimisha mtu yeyote kuendelea.

Kinachofanya hatari hii iweze kuvumilika ni utangamano wa E2B. Programu yako inazungumza na itifaki ambayo ina utekelezaji uliopangishwa (hosted implementation) nyuma yake, kwa hivyo ikiwa Dormice itakwama, unabadilisha URL mbili na kuendelea kufanya kazi. Andika wakala (agent) wako dhidi ya uso wa E2B badala ya API asilia na utahifadhi njia hiyo ya kutokea. Kifurushi asilia cha @dormice/sdk bado hakipo kwenye npm pia, kwa hivyo kukitumia kunamaanisha kukijenga kutoka kwenye repository, ambayo ni sababu ya pili ya kuanza na njia inayotangamana.

Iendeshe mahali ambapo unaweza kumudu kuipoteza. Jenga upya host kutoka kwenye script, weka token nje ya kila prompt na kila commit, na toa chochote kinachostahili kuhifadhiwa kutoka kwenye sandboxes kwa ratiba yako ya backup.

FAQ

Je, Dormice iko tayari kwa matumizi ya uzalishaji (production)?

Hapana, na mradi wenyewe unasema hivyo. Mstari wa hali katika README unaeleza kuwa hakuna kitu hapo kilicho tayari kwa uzalishaji, na kufikia tarehe 4 Agosti 2026 hazina (repository) hiyo ina takriban wiki nne tangu kuanzishwa, haina git tags wala releases, kwa hivyo hakuna namba ya toleo ya kutumia. Kisakinishi (installer) hufanya clone ya branch ya main, jambo linalomaanisha kila unapoikimbiza unapata commit ya hivi karibuni zaidi. Rekodi git -C /opt/dormice rev-parse HEAD baada ya kila usakinishaji, na weka chochote cha thamani nje ya sandboxes.

Dormice inatofautiana vipi na kumpa wakala wangu VM ya muda?

VM ya muda ni mashine yenye SSH unayotengeneza kwa ajili ya kikao kimoja na kuifuta baadaye. Dormice ni API ya utekelezaji: programu yako huita acquire, kisha exec, na kupata stdout na exit code, bila kuwa na shell session katikati. VM inafaa kwa binadamu au wakala anayetaka kompyuta nzima kwa muda fulani. Dormice inafaa kwa programu inayotekeleza msimbo uliotengenezwa mara nyingi kwa siku na haitaki mchakato wa kusanidi na kufuta mashine nzima kwa kila utekelezaji.

Je, SDK rasmi ya E2B inafanya kazi kweli bila kubadilisha msimbo?

Ndiyo, kwa kubadilisha usanidi. Elekeza apiUrl na sandboxUrl kwenye /e2b/api na /e2b/envd katika daemon yako, na uweke token ya Dormice ukiwa na prefix ya e2b_ kama API key. Utekelezaji wa amri, PTY sessions, uhamishaji wa faili, signed URLs na port proxy zote zimefunikwa na suite ya mwisho-hadi-mwisho ya mradi inayopitia kifurushi rasmi. Ujenzi wa template ndio pengo kuu: e2b template build haijatekelezwa, kwa hivyo template ni docker image unayojenga na kuisajili kwa dor template add.

Ni sandboxes ngapi zinatosha kwenye VPS ya 4 GB?

Takriban 6 zikiwa hai kwa wakati mmoja ikiwa kila sandbox inatumia 512 MiB, au 3 ikiwa kila moja inatumia gibibyte kamili, baada ya kutenga takriban 1 GB kwa ajili ya mfumo wa uendeshaji, Docker na daemon. Sandboxes zilizogandishwa (frozen) hupunguzwa na swap badala yake, kwa hivyo swapfile ya default ya 16 GB ya kisakinishi inaweza kuhifadhi takriban 16 sandboxes ambazo kila moja ilishikilia gibibyte. Pima matumizi yako kwa free -m chini ya mzigo halisi, kwa sababu sandbox inayotekeleza test suite hutumia mara nyingi zaidi ya ile inayotekeleza script ndogo.

Kwa nini Dormice inahitaji vm.swappiness iwekwe kuwa 100?

Kugandisha sandbox kunamaanisha kusukuma kumbukumbu yake isiyo na kazi (idle memory) kwenda kwenye swap. gVisor hushikilia kumbukumbu ya sandbox kama kumbukumbu iliyoshirikiwa (shared memory), na kernel ya Linux haitafanya swap ya kumbukumbu iliyoshirikiwa kwa swappiness ya default, kwa hivyo kwa default, kugandisha hakurudishi chochote na sandbox inaendelea kutumia kumbukumbu kamili. Mradi ulipima 0 bytes zilizorejeshwa kwa default na asilimia 99.5 zilizorejeshwa kwa 100. Hakiki thamani inayotumika kwa sysctl vm.swappiness badala ya kusoma faili za usanidi, kwa sababu baadhi ya images za wingu huja na thamani ya 0.