Maaari bang magpatakbo ng Firecracker ang VPS mo?

Maaari bang magpatakbo ang iyong VPS ng Firecracker microVM?

Maaari lamang magpatakbo ang iyong VPS ng Firecracker microVM kung ibinibigay nito sa iyo ang /dev/kvm. Ang Firecracker ay isang VMM (virtual machine monitor) na nakabatay sa KVM (kernel-based virtual machine), ang virtualization layer sa loob ng Linux. Kailangan ng KVM ng virtualization instructions mula sa CPU. Sa VPS, matatanggap mo lamang ang mga instruction na ito kapag ipinapasa ng provider ang mga ito sa iyong guest, at hindi ito ginagawa ng karamihan sa mga plan.

Kaya ang unang tanong ay hindi kung aling microVM tool ang i-install. Ang tanong ay kung kayang mag-host ng isa ng machine na binabayaran mo na. Usapin ito ng hosting, at masasagot mo ito sa loob ng humigit-kumulang isang minuto.

Suriin ang /dev/kvm bago mag-install ng anuman

Patakbuhin ang tatlong command na ito mismo sa VPS.

ls -l /dev/kvm
systemd-detect-virt
grep -cE '\b(vmx|svm)\b' /proc/cpuinfo

Ganito sumasagot ang isang machine na maaaring mag-host ng microVM:

crw-rw---- 1 root kvm 10, 232 Aug 10 09:12 /dev/kvm
kvm
16

Ang unang linya ay ang KVM device node na pagmamay-ari ng group na kvm. Ipinapakita ng ikalawang linya na ang machine na ito ay guest na tumatakbo sa ilalim ng KVM. Normal at inaasahan ito sa isang VPS. Binibilang ng ikatlong linya ang mga CPU core na nag-uulat ng hardware virtualisation flag na vmx sa Intel at svm sa AMD. Kapag higit sa zero ang bilang sa loob ng guest, inilalantad sa iyo ng hypervisor ang nested virtualisation.

Pagkatapos, tiyaking mabubuksan ng iyong user ang device. Ito ang test mula sa sariling getting started document ng Firecracker:

[ -r /dev/kvm ] && [ -w /dev/kvm ] && echo "OK" || echo "FAIL"

Ang FAIL habang umiiral ang node ay indikasyon ng permission problem, hindi ng problema sa hardware. Bigyan ng access ang sarili mong user gamit ang sudo setfacl -m u:${USER}:rw /dev/kvm, o idagdag ang sarili mo sa group gamit ang sudo usermod -aG kvm ${USER} at mag-log in muli.

May kasama ring check ang Ubuntu na nagbubuod sa lahat ng ito sa dalawang linya ng output:

sudo apt update && sudo apt install -y cpu-checker msr-tools
sudo kvm-ok

Nagpi-print ang gumaganang host ng INFO: /dev/kvm exists at kasunod nito ang KVM acceleration can be used. Nagpi-print naman ang host na hindi gumagana ng INFO: Your CPU does not support KVM extensions at kasunod nito ang KVM acceleration can NOT be used. Sa physical machine, maaari mong makita sa halip ang INFO: KVM (vmx) is disabled by your BIOS. Maaayos ito sa firmware. Sa VPS, bihira ang mensaheng ito dahil hindi totoong firmware ang sinusuri mo.

Ano ang ibig sabihin ng bawat sagot tungkol sa /dev/kvm?

Umiiral ang node at higit sa zero ang bilang ng flag. May hardware virtualization ka, kaya tatakbo ang Firecracker. Dumiretso sa sizing section, dahil memory na ang natitirang constraint mo, hindi CPU features.

Walang node, nagpi-print ang systemd-detect-virt ng kvm o qemu, at 0 ang bilang ng flag. Ang VPS mo ay isang virtual machine na hindi nagpapasa ng virtualization ang host nito. Walang mababago rito ang anumang i-install mo sa loob ng guest, dahil property ng virtual CPU ang flag na binuo ng hypervisor para sa iyo. Nagfa-fail ang sudo modprobe kvm_intel gamit ang modprobe: ERROR: could not insert 'kvm_intel': Operation not supported, at itinatala ng sudo dmesg | grep -i kvm ang nawawalang hardware support. Ito ang karaniwang sitwasyon sa shared VPS plans. Tanungin ang provider kung sinusuportahan ng plan ang nested virtualization. Kung hindi, kailangan mo ng ibang hosting, hindi ibang command.

Nagpi-print ang systemd-detect-virt ng lxc, lxc-libvirt, o openvz. Container virtualization ang gamit ng plan mo, kaya kernel ng host ang pinaghahatian ninyo. Hindi kailanman lilitaw ang /dev/kvm, dahil wala kang sariling kernel kung saan maglo-load ng module. Wala ring package na makaaayos nito.

Nariyan ang mga flag pero wala ang node. Hindi lang naka-load ang module. Patakbuhin ang sudo modprobe kvm_intel (o kvm_amd sa AMD) at suriin ulit ang ls -l /dev/kvm. Kung lumitaw ang node, ilagay ang pangalan ng module sa /etc/modules-load.d/kvm.conf para bumalik ito pagkatapos ng reboot.

arm64 ang gamit mo. Mga x86 name ang vmx at svm, kaya 0 ang bilang ng grep sa bawat arm64 machine, gumagana man ito o hindi. Sa arm64, umasa sa device node at sa read at write test.

Bakit microVM at hindi container para sa gawain ng agent

Ang container ay isang process sa iyong kernel na ibinukod gamit ang namespaces at cgroups. Iisa ang kernel at ikaw ang may kontrol dito, kaya kapag nakalusot sa kernel level, mapupunta ang pag-atake sa host. Nagbo-boot ang microVM ng sarili nitong kernel sa loob ng hardware virtualisation boundary. Nakikipag-ugnayan ito sa maliit na emulated device model sa halip na sa buong system call surface ng host. Sadyang maliit ang modelong ito sa Firecracker. Ito ang buong disenyo: kapag mas kaunti ang emulated devices, mas kaunti rin ang posibleng labasan.

Mahalaga ang pagkakaibang ito para sa coding agent dahil ang code na pinapatakbo ng agent ay code na hindi muna sinuri ng tao. Nag-i-install ito ng packages, nagpapatakbo ng build scripts, at awtomatikong sumusubok muli sa bilis ng machine kapag may nag-fail. Kapag hiwalay ang kernel, ang masamang hakbang ay makapipinsala lamang sa machine na maaari mong i-delete, at hindi sa iba pa.

Direktang sumusunod ang requirement sa mekanismo. Kailangan ng hardware isolation ang hardware virtualisation, at ang hardware virtualisation ang mismong feature na maaaring wala sa iyong VPS plan. Walang ganitong requirement ang container, kaya tumatakbo ang containers sa bawat plan na naibenta.

Kaya kapag nawawala ang /dev/kvm, nananatiling tamang sagot ang container-based na disposable VM para sa coding agents, at tunay itong control sa halip na pansamantalang pamalit. Karamihan sa aktuwal na problemang nangyayari ay mapipigilan ng throwaway container sa isang host na walang credentials na mahalaga sa iyo, basta nire-restore ito mula sa snapshot kapag hindi ito kumilos nang tama. Totoo rin ito sa mas simpleng setup na pagpapatakbo ng coding agent sa isang VPS. Gumamit ng microVM kapag tatakbo ang agent nang unattended nang ilang oras laban sa code na hindi mo pa nasusuri, at kapag ikaw ang may kontrol sa host.

Ano ang hinihingi ng microVM agent host

Ang Nehemiah ay kasalukuyang halimbawa ng ganitong uri: isang Apache-2.0 daemon na nagbibigay sa AI ng isang aktuwal na Linux machine kapag kinakailangan, na may isang Firecracker microVM para sa bawat machine. Malinaw ang nakasaad na requirement sa README: “isang Linux box na may /dev/kvm”, at mas partikular, “Ubuntu 24.04, x86_64 o arm64, na may /dev/kvm (bare-metal, o isang VM na may nested virtualization) kung saan maaari kang mag-root-SSH”.

Ang documented setup ay isang command na itinutuon sa box na iyon:

git clone https://github.com/boringcomputers/nehemiah
cd nehemiah && npm install
NEHEMIAH_ANTHROPIC_KEY=sk-ant-... ./infra/setup.sh root@YOUR_BOX_IP

Nagsasagawa ang infra/setup.sh ng preflight sa SSH at maagang humihinto kapag mali ang box. Ito ang dalawang hardware refusal nito:

/dev/kvm missing — the box needs hardware/nested virtualization
box arch is ${ARCH}; nehemiahd needs x86_64 or aarch64

Iyan ang buong punto ng post na ito. Itinatanong ng installer ang parehong tanong na itinanong mo gamit ang ls -l /dev/kvm, at sa karamihan ng VPS plan, pareho rin ang nakakadismayang sagot na natatanggap nito.

Paglampas sa preflight, buong box installation ito: Firecracker at ang jailer nito, Go toolchain, guest kernel at root filesystem, Python guest image, optional na desktop image na may browser, at dalawang systemd unit na pinangalanang nehemiahd.service at boring-net.service. Pagkatapos, nakikinig ang daemon sa port 8080, at nagpi-print ng /healthz didn't return ok kapag nabigo ang health check. Nilalaktawan ng SKIP_DESKTOP=1 ang desktop image, na ayon sa README ay tumatagal nang humigit-kumulang 8 minuto para ma-build.

Basahin ang mga caveat bago i-paste ang command

Nangangailangan ito ng root SSH sa isang bagong host. Nagsusulat ang installer ng system packages, systemd units, at network configuration bilang root. Ituro ito sa machine na handa mong i-rebuild mula sa simula, hindi sa server na nagpapatakbo na ng site mo.

Bilang default, nagbi-bind ang daemon sa 0.0.0.0:8080. Maaaring gumawa ng machines ang sinumang makakaabot sa port na iyon, at gagamitin ng mga machine na iyon ang model key na ibinigay mo sa installer. I-set ang NEHEMIAH_TOKEN upang mangailangan ng authentication, o i-set ang BIND_LOCALHOST=1 upang sa 127.0.0.1 lamang mag-bind ang daemon at ma-access mo ito sa pamamagitan ng tunnel gamit ang ssh -N -L 8080:127.0.0.1:8080 root@YOUR_BOX_IP. Ituring ang key na parang iba pang secret sa machine, gaya ng pag-iwas na mailantad ang mga secret sa AI agents.

Ang bawat machine ay isang computer na may internet access at may naka-install nang agents. Nakalista sa README ang claude, codex, cursor, at pi sa loob ng guest, kasama ng node, python, at git. Ayon sa project, nasa likod ng egress firewall ang mga guest, at tunay ang isolation boundary mismo. Naa-access pa rin ng guest ang network ayon sa disenyo, dahil walang silbi ang coding agent na hindi makapag-fetch ng package. Magplano para rito sa halip na ipagpalagay na air gap ito.

Walang tagged release. Noong 10 August 2026, walang anumang tags ang repository, kaya ang pag-clone ng main ay magbibigay sa iyo ng anumang naidagdag noong umagang iyon. Mag-pin sa isang commit, at basahin ang script bago ito tumakbo bilang root sa server mo:

git clone https://github.com/boringcomputers/nehemiah
cd nehemiah
git checkout ae743fd5c05aecb6ae4bb52bac6bce198b01ebaa
less infra/setup.sh

Nilikha ang repository sa katapusan ng June 2026, kaya ituring itong batang software. Basahin muli ang infra/setup.sh pagkatapos ng bawat update na i-pull mo, dahil ang inaaprubahan mo ay root access sa isang machine, hindi simpleng pagtaas ng library version.

Patunayan munang gumagana ang KVM bago sisihin ang installer

Kung nabigo ang setup at gusto mong malaman kung KVM ang sanhi, subukan ang Firecracker nang hiwalay. Ito ang upstream download steps:

ARCH="$(uname -m)"
release_url="https://github.com/firecracker-microvm/firecracker/releases"
latest=$(basename $(curl -fsSLI -o /dev/null -w %{url_effective} ${release_url}/latest))
curl -L ${release_url}/download/${latest}/firecracker-${latest}-${ARCH}.tgz | tar -xz
./release-${latest}-${ARCH}/firecracker-${latest}-${ARCH} --version

Ang lumabas na version ay nagpapatunay na tugma ang binary sa architecture mo at gumagana ito. Hindi nito pinatutunayang may access sa KVM, kaya isabay ito sa read at write test sa /dev/kvm mula sa naunang bahagi. Sa pamamagitan ng dalawang test na ito, matutukoy kung hosting problem o packaging problem ang sanhi. Maiiwasan mong i-debug ang installer kahit tama naman pala ang ginagawa nito.

Ilang server resources ang kailangan ng ilang microVM?

Ang bawat microVM ay may sariling aktuwal na guest kernel at memory na itinalaga rito. Naka-commit ang memory na iyon habang tumatakbo ang machine. Kaya i-size ang host batay sa laki ng guest at sa bilang ng guest na gusto mong sabay-sabay na patakbuhin. Arithmetic ang mga figure sa ibaba, hindi mga resulta ng measurement. Ang headless guest ay binibigyan ng 1 GB, at ang desktop guest na may browser ay binibigyan ng 2 GB. Naglalaan ang host ng flat na 2 GB para sa sarili nito, sa daemon, at sa image builds.

[
  {
    "label": "1 headless guest",
    "guests": 1,
    "guest_ram_gb": 1,
    "host_ram_gb": 3
  },
  {
    "label": "4 headless guests",
    "guests": 4,
    "guest_ram_gb": 1,
    "host_ram_gb": 6
  },
  {
    "label": "4 desktop guests",
    "guests": 4,
    "guest_ram_gb": 2,
    "host_ram_gb": 10
  },
  {
    "label": "8 desktop guests",
    "guests": 8,
    "guest_ram_gb": 2,
    "host_ram_gb": 18
  }
]

Ang isang headless machine sa bawat pagkakataon ay nangangailangan ng humigit-kumulang 3 GB. Kaya itong i-hold ng isang mid-size VPS kapag may KVM ito. Ang apat na machine ay nangangailangan ng 6 GB. Kung magpapatakbo ka ng 8 desktop machine, ang parehong arithmetic ay nangangailangan ng 18 GB bago pa isama ang kahit isang gigabyte ng disk.

Ang disk ang resource na kadalasang hindi napaplano. Nag-iimbak ang host ng guest kernel, base root filesystem, isang image para sa bawat guest flavour, at isang snapshot para sa bawat tumatakbong machine. Ang desktop image na may browser ang pinakamalaki. Walang ibinigay na disk figure ang README, kaya i-monitor ang df -h / habang ginagawa ang unang build sa halip na umasa sa hula.

Ito ang dahilan kung bakit ang tapat na sagot sa tanong na "aling VPS ang nagpapatakbo ng Firecracker" ay kadalasang "ibang klase ng machine". Binibigyan ka ng bare metal ng CPU flags nang walang hypervisor na nakaharang. Ito ang trade-off sa pagpili sa pagitan ng VPS at dedicated server. May ilang provider na naglalantad ng nested virtualisation sa kanilang virtual plans. Ipinapaliwanag ng nested virtualisation sa isang VPS kung paano ito makukumpirma bago magbayad. Kung pagmamay-ari mo na ang hardware, ang Proxmox kumpara sa plain VPS ay parehong tanong, pero mula sa panig ng hypervisor.

Ang server ay kalahati lamang ng gastos. Bawat machine na ipinapagamit mo sa isang agent ay kumokonsumo ng model tokens habang tumatakbo ito. Kaya ang idle microVM ay gumagastos ng memory, samantalang ang busy na microVM ay gumagastos ng memory at API spend. Hindi kayang i-hold ng 1 GB plan ang host. Kahit kayang i-hold ng isang plan ang host, hindi pa rin nito kayang bayaran ang key.

FAQ

Paano ko susuriin kung kayang magpatakbo ng Firecracker ang aking VPS?

Patakbuhin ang ls -l /dev/kvm, systemd-detect-virt, at grep -cE '\b(vmx|svm)\b' /proc/cpuinfo sa VPS. Ibig sabihin, kayang tumakbo ng Firecracker kapag may device node na pagmamay-ari ng grupong kvm at higit sa zero ang bilang ng flag. Kapag wala ang node at 0 ang bilang, hindi ipinapasa ng hypervisor ang virtualisation. Kinukumpirma ito ng sudo kvm-ok mula sa package na cpu-checker gamit ang KVM acceleration can NOT be used. Sa arm64, huwag pansinin ang bilang dahil mga x86 name ang vmx at svm.

Maaari ko bang i-enable ang nested virtualisation mula sa loob ng aking VPS?

Hindi. Ino-on ng host ang nested virtualisation sa sarili nitong kernel module ng hypervisor. Nakakarating ito sa iyo bilang CPU flag sa virtual processor na ibinigay sa iyo. Sa loob ng guest, nagbabalik ang sudo modprobe kvm_intel ng modprobe: ERROR: could not insert 'kvm_intel': Operation not supported dahil walang VMX na magagamit ang virtual CPU. Ang mga opsyon mo ay provider na nag-aalok ng nested virtualisation sa plan, o machine kung saan ikaw ang may kontrol sa hypervisor.

Sapat na ba ang container para i-sandbox ang coding agent?

Madalas, oo. Nakikibahagi ang container sa iyong kernel, kaya maaaring umabot sa host ang kernel-level escape. Gayunman, inaalis ng disposable container sa isang machine na walang mahahalagang credential ang malaking bahagi ng aktuwal na panganib. Pumili ng microVM kapag matagal na awtomatikong tumatakbo ang agent laban sa code na hindi pa nasusuri, at kapag mabibigyan mo ito ng host na may /dev/kvm. Kapag hindi ito posible, mas mabuti ang container na sinisira mo pagkatapos ng bawat task kaysa sa microVM na hindi mo kailanman mapapatakbo.

Gaano karaming RAM ang kailangan ng host para sa microVM agent?

Magsimula sa laki ng guest. Ang isang headless guest na may 1 GB at host reserve na 2 GB ay nangangailangan ng humigit-kumulang 3 GB sa kabuuan. Ang 8 desktop guest na may tig-2 GB ay nangangailangan ng humigit-kumulang 18 GB. Hiwalay ang disk at madali itong ma-underestimate dahil nagtatago ang host ng kernel, root filesystem, isang image para sa bawat guest flavour, at snapshot para sa bawat tumatakbong machine.