Kan mijn VPS Firecracker microVMs draaien?

Kan uw VPS Firecracker microVM's draaien?

Uw VPS kan alleen Firecracker microVM's draaien als deze /dev/kvm biedt. Firecracker is een VMM (virtual machine monitor) gebouwd op KVM (kernel-based virtual machine), de virtualisatielaag binnen Linux, en KVM vereist virtualisatie-instructies van de CPU. Op een VPS krijgt u deze instructies alleen als de provider deze doorgeeft aan uw guest, en de meeste abonnementen doen dit niet.

De eerste vraag is dus niet welke microVM-tool u moet installeren. De vraag is of de machine waarvoor u al betaalt er überhaupt een kan hosten. Dat is een vraag over hosting, en u kunt deze in ongeveer een minuut beantwoorden.

Controleer /dev/kvm voordat u iets installeert

Voer deze drie commando's uit op de VPS zelf.

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

Een server die microVM's kan hosten, geeft de volgende output:

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

De eerste regel is het KVM-device-node, dat eigendom is van de groep kvm. De tweede regel geeft aan dat deze machine zelf een guest is die onder KVM draait; dit is normaal en verwacht op een VPS. De derde regel telt het aantal CPU-cores dat de hardware-virtualisatievlag rapporteert, vmx op Intel en svm op AMD. Een getal hoger dan nul binnen een guest betekent dat de hypervisor nested virtualisation aan u doorgeeft.

Controleer vervolgens of uw gebruiker het device kan openen. Dit is de test uit het document getting started van Firecracker:

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

FAIL terwijl de node bestaat, wijst op een rechtenprobleem in plaats van een hardwareprobleem. Verleen toegang aan uw eigen gebruiker met sudo setfacl -m u:${USER}:rw /dev/kvm, of voeg uzelf toe aan de groep met sudo usermod -aG kvm ${USER} en log opnieuw in.

Ubuntu bevat ook een controle die dit alles samenvat in twee regels output:

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

Een host die werkt, toont INFO: /dev/kvm exists en daarna KVM acceleration can be used. Een host die niet werkt, toont INFO: Your CPU does not support KVM extensions en daarna KVM acceleration can NOT be used. Op een fysieke machine ziet u mogelijk INFO: KVM (vmx) is disabled by your BIOS, wat in de firmware kan worden opgelost. Op een VPS is die melding zeldzaam, omdat u niet naar echte firmware kijkt.

Wat betekent elk /dev/kvm antwoord?

Het node-bestand bestaat en de vlag-teller is groter dan nul. U beschikt over hardware-virtualisatie, dus Firecracker zal werken. Ga door naar de sectie over dimensionering, aangezien uw beperkende factor nu het geheugen is in plaats van CPU-functies.

Geen node-bestand, systemd-detect-virt geeft kvm of qemu weer, en de vlag-teller is 0. Uw VPS is een virtuele machine waarvan de host geen virtualisatie doorgeeft. Niets dat u binnen de gastmachine installeert, verandert dit, omdat de vlag een eigenschap is van de virtuele CPU die de hypervisor voor u heeft aangemaakt. sudo modprobe kvm_intel faalt met modprobe: ERROR: could not insert 'kvm_intel': Operation not supported, en sudo dmesg | grep -i kvm registreert het ontbreken van hardware-ondersteuning. Dit is de gebruikelijke situatie bij gedeelde VPS-abonnementen. Vraag de provider of het abonnement nested virtualisation ondersteunt. Als het antwoord nee is, heeft u andere hosting nodig, geen ander commando.

systemd-detect-virt geeft lxc, lxc-libvirt of openvz weer. Uw abonnement is gebaseerd op container-virtualisatie, waardoor u de kernel van de host deelt. /dev/kvm zal nooit verschijnen, omdat u geen eigen kernel heeft om een module in te laden. Geen enkel pakket lost dit op.

De vlaggen zijn aanwezig, maar het node-bestand niet. De module is simpelweg niet geladen. Voer sudo modprobe kvm_intel uit (of kvm_amd op AMD) en controleer ls -l /dev/kvm opnieuw. Als het node-bestand verschijnt, schrijf de modulenaam dan in /etc/modules-load.d/kvm.conf zodat deze na een herstart weer terugkeert.

U gebruikt arm64. vmx en svm zijn x86-namen, dus de grep-teller is 0 op elke arm64-machine, ongeacht of deze werkt of niet. Vertrouw op arm64 op het device-node-bestand en de lees- en schrijftest.

Waarom een microVM en geen container voor agent-taken

Een container is een proces op uw kernel, afgeschermd met namespaces en cgroups. Er is één kernel en die is van u, dus een ontsnapping op kernelniveau bereikt de host. Een microVM start een eigen kernel binnen een hardware-virtualisatiegrens en communiceert met een klein geëmuleerd apparaatmodel in plaats van met het volledige systeem-call-oppervlak van uw host. Firecracker houdt dat model bewust klein, wat het hele ontwerp is: minder geëmuleerde apparaten betekenen minder ontsnappingsroutes.

Dat verschil is van belang voor een coding agent, omdat de code die een agent uitvoert code is die niemand vooraf heeft gelezen. Deze installeert pakketten, voert build-scripts uit en probeert het op machinesnelheid opnieuw wanneer iets mislukt. Een aparte kernel betekent dat een foutieve stap een machine beschadigt die u kunt verwijderen, en niets anders.

De vereiste volgt direct uit het mechanisme. Hardware-isolatie vereist hardware-virtualisatie, en hardware-virtualisatie is precies hetgeen wat uw VPS-abonnement mogelijk niet biedt. Een container heeft dit niet nodig, en daarom draaien containers op elk verkocht abonnement.

Dus wanneer /dev/kvm ontbreekt, blijft de op containers gebaseerde tijdelijke VM voor coding agents het juiste antwoord, en het is een echte beheersmaatregel in plaats van een troostprijs. Een wegwerpcontainer, op een host die geen inloggegevens bevat waar u waarde aan hecht, hersteld vanuit een snapshot wanneer deze zich misdraagt, stopt het meeste van wat er daadwerkelijk misgaat. Hetzelfde geldt voor de eenvoudigere opzet in een coding agent draaien op een VPS. Kies voor een microVM wanneer een agent onbeheerd zal draaien, gedurende uren, tegen code die u niet heeft gecontroleerd, en wanneer de host van u is om weg te geven.

Wat een microVM-agenthost vereist

Nehemiah is een actueel voorbeeld van deze klasse: een Apache-2.0-daemon die op aanvraag een echte Linux-machine aan een AI levert, één Firecracker microVM per machine. De README vermeldt de vereiste zonder voorbehoud: "een Linux-box met /dev/kvm", en specifieker "Ubuntu 24.04, x86_64 of arm64, met /dev/kvm (bare-metal, of een VM met nested virtualization) waar u root-SSH-toegang tot heeft".

De gedocumenteerde installatie bestaat uit één commando gericht op die box:

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

infra/setup.sh voert via SSH een preflight-check uit en stopt voortijdig als de box niet voldoet. De twee hardware-weigeringen luiden:

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

Die eerste reeks is de kern van dit bericht. Het installatieprogramma stelt dezelfde vraag die u zojuist stelde met ls -l /dev/kvm, en op de meeste VPS-abonnementen krijgt het hetzelfde teleurstellende antwoord.

Na de preflight volgt een volledige installatie op de box: Firecracker en de bijbehorende jailer, een Go-toolchain, een guest-kernel en root-bestandssysteem, een Python-guest-image, een optionele desktop-image met een browser, en twee systemd-units genaamd nehemiahd.service en boring-net.service. De daemon luistert vervolgens op poort 8080, en een mislukte health check geeft /healthz didn't return ok weer. SKIP_DESKTOP=1 slaat de desktop-image over, waarvan de README aangeeft dat het bouwen ongeveer 8 minuten duurt.

Lees de waarschuwingen voordat u dat commando plakt

Het vereist root SSH op een nieuwe host. Het installatieprogramma schrijft systeempakketten, systemd-units en netwerkconfiguraties als root. Gebruik hiervoor een machine die u volledig opnieuw kunt installeren, niet de server waarop uw website al draait.

De daemon luistert standaard op 0.0.0.0:8080. Iedereen die die poort bereikt, kan machines aanmaken, en die machines verbruiken de modelsleutel die u aan het installatieprogramma heeft verstrekt. Stel NEHEMIAH_TOKEN in om authenticatie te vereisen, of stel BIND_LOCALHOST=1 in zodat de daemon alleen op 127.0.0.1 luistert en u deze bereikt via een tunnel met ssh -N -L 8080:127.0.0.1:8080 root@YOUR_BOX_IP. De sleutel verdient dezelfde zorg als elk ander geheim op de server, zoals beschreven in geheimen buiten AI-agents houden.

Elke machine is een computer met internettoegang en vooraf geïnstalleerde agents. De README vermeldt claude, codex, cursor en pi in de guest, naast node, python en git. Het project stelt dat guests achter een uitgaande firewall zitten en dat de isolatiegrens zelf reëel is. De guest bereikt echter nog steeds het netwerk, omdat een programmeer-agent die geen pakket kan ophalen nutteloos is. Houd hier rekening mee in plaats van uit te gaan van een air-gap.

Er is geen getagde release. Sinds 10 augustus 2026 bevat de repository helemaal geen tags, dus het klonen van main levert u de versie op die die ochtend is geüpload. Pin vast op een commit en lees het script voordat het als root op uw server wordt uitgevoerd:

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

De repository is eind juni 2026 aangemaakt, dus beschouw het als nieuwe software. Lees infra/setup.sh opnieuw na elke update die u ophaalt, aangezien u toestemming geeft voor root-toegang tot een machine, niet voor een versie-update van een bibliotheek.

Controleer of KVM werkt voordat u de installer de schuld geeft

Als de installatie mislukt en u wilt weten of KVM de oorzaak is, test Firecracker dan afzonderlijk. Dit zijn de stappen voor het downloaden van de upstream-versie:

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

Een afgedrukte versie bewijst dat het binaire bestand overeenkomt met uw architectuur en wordt uitgevoerd. Dit bewijst echter niet dat er toegang is tot KVM, dus combineer dit met de lees- en schrijftest op /dev/kvm van eerder. Samen scheiden deze twee tests een hostingprobleem van een verpakkingsprobleem. Dit bespaart u het debuggen van een installer die vanaf het begin correct was.

Hoeveel servercapaciteit hebben meerdere microVM's nodig?

Elke microVM bevat een echte gast-kernel plus het geheugen dat u toewijst, en dat geheugen blijft gealloceerd zolang de machine draait. Bepaal daarom de grootte van de host op basis van de grootte van de gasten en het aantal dat u gelijktijdig wilt draaien. De onderstaande cijfers zijn rekenkundig, geen metingen. Een headless gast krijgt 1 GB en een desktop-gast met een browser krijgt 2 GB. De host houdt standaard 2 GB achter de hand voor zichzelf, de daemon en het bouwen van images.

[
  {
    "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
  }
]

Eén headless machine tegelijk vereist ongeveer 3 GB, wat een middelgrote VPS kan bieden wanneer deze KVM ondersteunt. Vier van dergelijke machines vereisen 6 GB. Draai 8 desktopmachines en dezelfde berekening vraagt om 18 GB, nog voordat u ook maar één gigabyte aan schijfruimte meetelt.

Schijfruimte is het getal waar niemand rekening mee houdt. De host slaat een gast-kernel op, een basis-root-bestandssysteem, één image per gasttype en een snapshot per draaiende machine; de desktop-image met een browser is de grootste. De README geeft geen schijfcijfer, dus houd df -h / in de gaten tijdens de eerste build in plaats van op een schatting te vertrouwen.

Dit is de reden waarom het eerlijke antwoord op "welke VPS draait Firecracker" vaak is: "een ander type machine". Bare metal biedt u de CPU-flags zonder hypervisor die in de weg zit; dat is de afweging bij het kiezen tussen een VPS en een dedicated server. Sommige providers bieden geneste virtualisatie aan op virtuele abonnementen, en geneste virtualisatie op een VPS beschrijft hoe u dit bevestigt voordat u betaalt. Als de hardware al van u is, is Proxmox versus een standaard VPS dezelfde vraag, maar dan bekeken vanuit het perspectief van de hypervisor.

De server is bovendien de goedkope helft. Elke machine die u aan een agent geeft, verbruikt model-tokens zolang deze draait; een inactieve microVM kost dus geheugen, terwijl een actieve microVM geheugen én API-kosten met zich meebrengt. Een abonnement van 1 GB kan de host niet draaien. Een abonnement dat de host wel kan draaien, betaalt nog steeds niet de key.

FAQ

Hoe controleer ik of mijn VPS Firecracker kan draaien?

Voer ls -l /dev/kvm, systemd-detect-virt en grep -cE '\b(vmx|svm)\b' /proc/cpuinfo uit op de VPS. Een device node die eigendom is van de kvm-groep, in combinatie met een vlag-aantal boven nul, betekent dat Firecracker kan draaien. Een ontbrekende node met een aantal van 0 betekent dat de hypervisor virtualisatie niet doorgeeft, en sudo kvm-ok uit het cpu-checker-pakket bevestigt dit met KVM acceleration can NOT be used. Negeer op arm64 het aantal, omdat vmx en svm x86-namen zijn.

Kan ik geneste virtualisatie inschakelen vanuit mijn VPS?

Nee. Geneste virtualisatie wordt ingeschakeld door de host, in de eigen kernelmodule van de hypervisor, en bereikt u als een CPU-vlag op de virtuele processor die aan u is toegewezen. Binnen de guest geeft sudo modprobe kvm_intel de waarde modprobe: ERROR: could not insert 'kvm_intel': Operation not supported terug, omdat de virtuele CPU geen VMX heeft om te gebruiken. Uw opties zijn een provider die geneste virtualisatie aanbiedt in het abonnement, of een machine waarvan u zelf de hypervisor beheert.

Is een container voldoende om een coding agent te isoleren?

Vaak wel. Een container deelt uw kernel, dus een ontsnapping op kernelniveau bereikt de host, maar een tijdelijke container op een machine zonder waardevolle inloggegevens elimineert het grootste deel van het risico waar u daadwerkelijk mee te maken heeft. Kies een microVM wanneer een agent gedurende lange tijd onbeheerd draait op niet-gecontroleerde code, en wanneer u deze een host met /dev/kvm kunt geven. Wanneer dat niet kan, is een container die u na elke taak vernietigt beter dan een microVM die u niet aan de praat krijgt.

Hoeveel RAM heeft een microVM-agenthost nodig?

Ga uit van de grootte van de guest. Eén headless guest van 1 GB met een host-reserve van 2 GB vereist in totaal ongeveer 3 GB, en 8 desktop-guests van elk 2 GB vereisen ongeveer 18 GB. Schijfruimte is een apart punt en wordt gemakkelijk onderschat, omdat de host een kernel, root-bestandssystemen, één image per guest-type en een snapshot voor elke draaiende machine moet bewaren.