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.

Mga hinihingi ng microVM agent host

Ang Nehemiah ay kasalukuyang halimbawa ng ganitong uri ng software: isang Apache-2.0 daemon na nagbibigay sa AI ng aktuwal na Linux machine kapag kinakailangan, na may tig-isang Firecracker microVM bawat machine. Noong 10 August 2026, malinaw na nakasaad sa README nito ang requirement: “isang Linux box na may /dev/kvm,” at mas partikular, “Ubuntu 24.04, x86_64 o arm64, na may /dev/kvm (bare-metal, o VM na may nested virtualization) na maaari mong i-root-SSH.”

Nagbago na ito mula noon. Noong 11 August 2026, pinalitan ng proyekto ang self-serve setup documentation nito ng managed-host runbook. Sa README na sinuri noong 11 October 2026, wala na ang requirement na iyon at ang one-command install. Ang mga host ay sine-set up na ngayon mula sa signed release artifacts papunta sa Latitude.sh bare-metal servers na may infra/latitude/provision.sh. Isa itong manual na prosesong pinapatakbo ng operator para sa mga aprubadong host, na saka ine-enroll ng control plane ng proyekto. Tumatanggi pa rin ang canary ng runbook sa host na walang usable na /dev/kvm, kaya hindi nawala ang requirement. Inilipat lamang ito sa bare metal.

Bago ang pagbabagong iyon, isang command ang documented setup para 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

Sa kasalukuyang main, wala nang ini-install ang command na iyon. Ang infra/setup.sh ay minarkahang descoped at lumalabas sa unang hakbang nito na may mensaheng hindi na suportado ang self-serve bootstrap, bago tumakbo ang anumang preflight o install step. Ayon sa README, ang mga dating self-serve installer ay lumalabas na ngayon na may pointer papunta sa managed runbook.

Sa commit na pinagbabatayan ng unang pagkakasulat ng post na ito, nagsasagawa ang infra/setup.sh ng preflight sa pamamagitan ng SSH at maagang humihinto kapag hindi tama ang box. Ganito ang dalawang hardware refusal nito:

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

Ang unang string ang pangunahing punto ng post na ito. Itinanong ng installer ang parehong tanong na itinanong mo gamit ang ls -l /dev/kvm, at sa karamihan ng VPS plan, ganoon din ang nakakadismayang sagot. Itinatanong din ito ng managed runbook.

Pagkatapos ng preflight, buong box ang ini-install: 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. Kapag nabigo ang health check, ipinapakita ang /healthz didn't return ok. Nilalaktawan naman ng SKIP_DESKTOP=1 ang desktop image, na ayon sa README noong petsang iyon ay umaabot nang humigit-kumulang 8 minuto ang pag-build. Wala sa mga hakbang, mensahe, o switch na ito ang tumatakbo mula sa kasalukuyang main. Ang daemon mismo ay nakikinig pa rin bilang default sa port 8080.

Basahin ang mga caveat bago i-paste ang command na iyon

Nangangailangan ito ng root SSH sa bagong host. Ang self-serve installer ay nagsusulat ng system packages, systemd units, at network configuration bilang root. Kung patatakbuhin mo pa rin ang hindi suportadong commit na iyon, gamitin ito sa machine na handa mong i-rebuild mula sa simula, hindi sa server na nagpapatakbo na ng site mo.

Naka-bind ang daemon sa 0.0.0.0:8080 bilang default. 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 host. Itakda ang NEHEMIAH_TOKEN upang mangailangan ng authentication, o itakda ang NEHEMIAH_ADDR=127.0.0.1:8080 (tumatanggap din ang daemon ng -addr 127.0.0.1:8080) upang sa 127.0.0.1 lamang ito mag-bind at maabot mo ito sa pamamagitan ng tunnel gamit ang ssh -N -L 8080:127.0.0.1:8080 root@YOUR_BOX_IP. Hindi binabasa ng daemon ang BIND_LOCALHOST=1 switch ng lumang installer, kaya wala itong epekto sa labas ng script na iyon. Ingatan ang key tulad ng iba pang secret sa machine, gaya ng nasa pagpapanatiling hiwalay ng mga secret sa AI agents.

Ang bawat machine ay 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. Nakakaabot pa rin sa network ang guest ayon sa disenyo, dahil walang silbi ang coding agent na hindi makapag-fetch ng package. Magplano para rito sa halip na ipagpalagay na may air gap.

Walang tagged release. Noong 11 October 2026, walang tags at releases ang repository, kaya kapag ni-clone ang main, makukuha mo ang anumang na-commit noong umagang iyon, at ang code ngayon ay para lamang sa managed deployment. Mag-pin sa isang commit. Ang nasa ibaba ang commit na ginamit noong isinulat ang post na ito noong 10 August 2026, isang araw bago bawiin ang self-serve installer, kaya nag-i-install pa rin ang infra/setup.sh nito. Hindi na sinusuportahan ng project ang path na iyon, kaya basahin ang script bago ito patakbuhin bilang root sa server mo:

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

Ginawa ang repository sa pagtatapos ng June 2026 at binawi ang self-serve install pagkalipas ng anim na linggo, kaya ituring itong bagong software na maaaring magbago ang supported path nang hindi inaasahan. Bago kumuha ng anumang mas bagong bersyon, basahin muli ang README at runbook, dahil root access sa machine ang inaaprubahan mo, hindi simpleng pag-update ng bersyon ng library.

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.

Gaano karaming server ang kailangan ng ilang microVM?

Ang bawat microVM ay may sariling aktuwal na guest kernel, kasama ang memory na inilaan mo rito. Nakalaan 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. Ang mga figure sa ibaba ay batay sa arithmetic, hindi sa measurements. 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 3 GB para sa sarili nito, sa daemon, at sa image builds. Ito ang default reserve ng daemon (NEHEMIAH_MEM_RESERVE_MB, 3072 MB). Tumatanggi ang daemon na mag-boot ng bagong machine kung kakain ito sa reserve na iyon. Kaya ang host na kulang sa laki ay umaabot sa capacity sa halip na maubusan ng memory.

[
  {
    "label": "1 headless guest",
    "guests": 1,
    "guest_ram_gb": 1,
    "host_ram_gb": 4
  },
  {
    "label": "4 headless guests",
    "guests": 4,
    "guest_ram_gb": 1,
    "host_ram_gb": 7
  },
  {
    "label": "4 desktop guests",
    "guests": 4,
    "guest_ram_gb": 2,
    "host_ram_gb": 11
  },
  {
    "label": "8 desktop guests",
    "guests": 8,
    "guest_ram_gb": 2,
    "host_ram_gb": 19
  }
]

Ang isang headless machine sa bawat pagkakataon ay nangangailangan ng humigit-kumulang 4 GB. Kaya itong i-hold ng isang mid-size VPS kapag nagbibigay ito sa iyo ng KVM. Ang apat na machine ay nangangailangan ng 7 GB. Kung magpapatakbo ka ng 8 desktop machine, kailangan naman ng parehong arithmetic ang 19 GB bago pa isama ang kahit isang gigabyte ng disk.

Ang disk ang madalas 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 ibinibigay na disk figure ang README, kaya i-monitor ang df -h / habang isinasagawa 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 madalas na “ibang klase ng machine.” Nagbibigay ang bare metal ng mga CPU flag 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 mga virtual plan, at ipinapaliwanag ng nested virtualisation sa isang VPS kung paano ito makumpirma bago magbayad. Kung iyo na ang hardware, ang Proxmox kumpara sa plain VPS ay kaparehong tanong ngunit mula sa panig ng hypervisor.

Mura rin ang server na bahagi ng gastos. Bawat machine na ipinapasa mo sa isang agent ay gumagamit ng model tokens habang tumatakbo ito. Kaya ang idle microVM ay nagkakahalaga ng memory, habang ang busy microVM ay nagkakahalaga 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 sasagutin ang key.

FAQ

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

Patakbuhin ang ls -l /dev/kvm, systemd-detect-virt, at grep -cE '\b(vmx|svm)\b' /proc/cpuinfo sa VPS. Ibig sabihin ng device node na pagmamay-ari ng grupong kvm, kasama ng flag count na higit sa zero, ay kayang patakbuhin ng Firecracker. Ang kawalang device node na may count na 0 ay nangangahulugang hindi ipinapasa ng hypervisor ang virtualisation, at 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 count 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, at ipinapasa ito sa iyo bilang CPU flag sa virtual processor na itinalaga sa iyo. Sa loob ng guest, ibinabalik ng sudo modprobe kvm_intel ang modprobe: ERROR: could not insert 'kvm_intel': Operation not supported dahil walang VMX ang virtual CPU na magagamit. 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 isang coding agent?

Kadalasan, oo. Ibinabahagi ng container ang kernel mo, kaya maaabot ng kernel-level escape ang host. Gayunman, inaalis ng disposable container sa machine na walang mahahalagang credential ang karamihan sa aktuwal na panganib na kinakaharap mo. Pumili ng microVM kapag matagal na tumatakbo nang walang supervision 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 mainam ang container na sinisira mo pagkatapos ng bawat task kaysa sa microVM na hindi mo naman mapasimulang mag-boot.

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

Magsimula sa laki ng guest. Ang isang headless guest na may 1 GB, kasama ang 3 GB na reserve para sa host, ay nangangailangan ng humigit-kumulang 4 GB sa kabuuan. Ang 8 desktop guest na tig-2 GB ay nangangailangan naman ng humigit-kumulang 19 GB. Hiwalay ang disk at madaling maliitin ang pangangailangan dito dahil nagtatago ang host ng kernel, root filesystem, isang image para sa bawat guest flavour, at snapshot para sa bawat tumatakbong machine.