Your VPS Fit Run Firecracker? Check Am First

Your VPS fit run Firecracker microVMs?

Your VPS fit run Firecracker microVMs only if e give you /dev/kvm. Firecracker na VMM (virtual machine monitor) wey dey build on KVM (kernel-based virtual machine), wey be the virtualisation layer inside Linux. KVM need virtualisation instructions from the CPU. For VPS, you go get these instructions only when provider pass dem through go your guest, and most plans no dey do am.

So the first question no be which microVM tool to install. Na whether the machine wey you already dey pay for fit host one at all. This na hosting question, and you fit answer am within about one minute.

Check /dev/kvm before you install anything

Run these three commands on the VPS itself.

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

A box wey fit host microVMs go answer like this:

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

The first line na KVM device node, and na kvm group own am. The second line talk say this machine na guest wey dey run under KVM. This normal and na wetin we expect for VPS. The third line count CPU cores wey report hardware virtualisation flag, vmx for Intel and svm for AMD. If the count pass zero inside guest, e mean say hypervisor dey expose nested virtualisation to you.

Then check say your user fit open the device. Na this test Firecracker own getting started document use:

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

FAIL while the node dey exist na permission problem, no be hardware problem. Give your own user access with sudo setfacl -m u:${USER}:rw /dev/kvm, or add yourself to the group with sudo usermod -aG kvm ${USER}, then log in again.

Ubuntu also get check wey summarise all this with two lines of output:

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

Host wey work go print INFO: /dev/kvm exists, then KVM acceleration can be used. Host wey no fit work go print INFO: Your CPU does not support KVM extensions, then KVM acceleration can NOT be used. For physical machine, you fit instead see INFO: KVM (vmx) is disabled by your BIOS, and firmware fit fix am. For VPS, that message rare because you no dey check real firmware.

Wetin each /dev/kvm answer mean?

The node dey exist and the flag count pass zero. You get hardware virtualisation, so Firecracker go run. Skip go the sizing section, because memory na your remaining constraint, no be CPU features.

No node, systemd-detect-virt dey print kvm or qemu, and the flag count na 0. Your VPS na virtual machine wey the host no dey pass virtualisation through. Nothing wey you install inside the guest fit change this, because the flag na property of the virtual CPU wey hypervisor build for you. sudo modprobe kvm_intel fail with modprobe: ERROR: could not insert 'kvm_intel': Operation not supported, and sudo dmesg | grep -i kvm record the missing hardware support. This na the common case for shared VPS plans. Ask the provider whether the plan support nested virtualisation. If the answer na no, you need different hosting, no be different command.

systemd-detect-virt dey print lxc, lxc-libvirt or openvz. Your plan na container virtualisation, so you dey share the host kernel. /dev/kvm no go ever appear, because you no get your own kernel wey you fit load module into. No package fit fix this too.

The flags dey there but the node no dey. The module simply no load. Run sudo modprobe kvm_intel (or kvm_amd for AMD) and check ls -l /dev/kvm again. If the node appear, write the module name inside /etc/modules-load.d/kvm.conf so e go come back after reboot.

You dey use arm64. vmx and svm na x86 names, so the grep count na 0 for every arm64 machine, whether e dey work or not. For arm64, trust the device node and the read and write test instead.

Why microVM better pass container for agent work

Container na be process wey dey run for your kernel, and namespaces plus cgroups fence am off. Na one kernel dey, and na your own be that, so if person escape through kernel level, e go land for host. microVM boots its own kernel inside hardware virtualisation boundary. E dey communicate with small emulated device model instead of your host full system call surface. Firecracker deliberately keep that model small. Na the main design be that: fewer emulated devices mean fewer ways to escape.

This difference matter for coding agent because na code wey nobody read first agent dey run. E dey install packages, run build scripts, and retry at machine speed when something fail. Separate kernel mean say bad step fit damage machine wey you fit delete, and nothing else.

The requirement follow directly from how the mechanism work. Hardware isolation need hardware virtualisation, and hardware virtualisation na exactly wetin your VPS plan fit no provide. Container no need any of am, na why containers dey run for every plan wey dem don ever sell.

So when /dev/kvm no dey, container-based disposable VM for coding agents still be the correct answer. E be real control, no be consolation prize. Throwaway container for host wey no hold any credential wey matter to you, restored from snapshot whenever e misbehave, dey stop most of the things wey actually fit go wrong. Same thing apply to the simpler setup for running coding agent on VPS. Use microVM when agent go run unattended for hours against code wey you never review, and when host na your own to give.

Wetín microVM agent host need

Nehemiah na current example of this class: na Apache-2.0 daemon wey dey give AI one real Linux machine on demand, with one Firecracker microVM for each machine. As of 10 August 2026, the README state the requirement plainly: "a Linux box with /dev/kvm", and more precisely "Ubuntu 24.04, x86_64 or arm64, with /dev/kvm (bare-metal, or a VM with nested virtualization) that you can root-SSH into".

That one don change since then. On 11 August 2026, the project replace its self-serve setup docs with a managed-host runbook, and the README wey dem check on 11 October 2026 no longer get that requirement line or the one-command install. Dem dey now provision hosts from signed release artifacts onto Latitude.sh bare-metal servers with infra/latitude/provision.sh. Na manual, operator-run process for approved hosts, wey the project control plane later enrolls. The runbook canary still refuse host wey no get usable /dev/kvm, so the requirement no disappear. E don move go bare metal.

Before that change, the documented setup na one command wey target that box:

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

For current main, that command no dey install anything again. infra/setup.sh don mark as descoped and e go exit for the first step with message say self-serve bootstrap no longer supported, before any preflight or install step run. The README talk say the earlier self-serve installers now exit with pointer to the managed runbook.

For the commit wey this post first use, infra/setup.sh run preflight over SSH and stop early when the box no correct. The two hardware refusal messages be:

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

That first string na the main point of this post. The installer ask the same question wey you just ask with ls -l /dev/kvm, and for most VPS plans e get the same disappointing answer. The managed runbook still ask am too.

After preflight, na complete box installation: Firecracker and its jailer, Go toolchain, guest kernel and root filesystem, Python guest image, optional desktop image with browser, and two systemd units named nehemiahd.service and boring-net.service. If health check fail, e print /healthz didn't return ok, while SKIP_DESKTOP=1 skip the desktop image. The README for that date talk say building the image dey take around 8 minutes. None of those steps, messages, or switches dey run from current main. The daemon itself still dey listen on port 8080 by default.

Read the caveats before you paste that command

E wan root SSH for fresh host. The self-serve installer write system packages, systemd units and network configuration as root. If you run that unsupported commit anyway, point am to machine wey you ready rebuild from nothing, no be the server wey already dey run your site.

The daemon dey bind 0.0.0.0:8080 by default. Anybody wey fit reach that port fit create machines, and those machines go spend the model key wey you give the host. Set NEHEMIAH_TOKEN make e require authentication, or set NEHEMIAH_ADDR=127.0.0.1:8080 (the daemon still accept -addr 127.0.0.1:8080) so e go bind 127.0.0.1 only, then you go reach am through tunnel with ssh -N -L 8080:127.0.0.1:8080 root@YOUR_BOX_IP. The old installer's BIND_LOCALHOST=1 switch no dey read by the daemon, so e no do anything outside that script. Treat the key with the same care as any other secret for the box, like keeping secrets away from AI agents.

Every machine na computer wey get internet access and agents wey don install. The README list claude, codex, cursor and pi inside the guest, together with node, python and git. The project talk say guests dey behind egress firewall, and the isolation boundary itself dey real. The guest still fit reach network by design, because coding agent wey no fit fetch package no get use. Plan for this instead of assuming say air gap dey.

No tagged release dey. As of 11 October 2026, the repository no get tags or releases, so when you clone main, you go get anything wey land that morning, and today na the managed-only code. Pin am to a commit. The one below na the commit wey this post use on 10 August 2026, one day before dem withdraw the self-serve installer, so its infra/setup.sh still install. The project no longer support that path, so read the script before e run as root for your server:

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

Dem create the repository for end of June 2026 and withdraw the self-serve install six weeks later. So treat am as young software wey its supported path fit change under you. Before you pull anything newer, read the README and the runbook again, because wetin you dey approve na root access to a machine, no be library version bump.

Prove say KVM dey work before you blame the installer

If setup fail and you wan know whether KVM na the reason, test Firecracker by itself. Na these 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

Version wey e print prove say the binary match your architecture and dey run. E no prove say KVM access dey work, so pair am with the read and write test for /dev/kvm from earlier. Together, the two tests go separate hosting problem from packaging problem. This go save you from debugging installer wey dey correct from the beginning.

How much server several microVMs need?

Each microVM get real guest kernel plus the memory we assign am, and that memory remain committed as long as machine dey run. So size the host based on guest size and how many you want run at once. The figures below na arithmetic, not measurements. Headless guest get 1 GB, while desktop guest with browser get 2 GB. The host keep flat 3 GB reserve for itself, the daemon, and image builds. This na the daemon default reserve (NEHEMIAH_MEM_RESERVE_MB, 3072 MB). The daemon no go boot new machine if e go use any part of that reserve, so host wey too small go reach capacity instead of running out of 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
  }
]

One headless machine at a time need about 4 GB, and mid-size VPS fit hold am when e gives you KVM. Four of dem need 7 GB. Run 8 desktop machines, and the same arithmetic need 19 GB before you count even 1 GB of disk.

Disk na the thing wey people no dey plan for. Host store guest kernel, base root filesystem, one image for each guest flavour, and one snapshot for each machine wey dey run. Desktop image wey get browser na the large one. README no give disk figure, so monitor df -h / during the first build instead of trusting guess.

Na why the honest answer to "which VPS runs Firecracker" often be "another class of machine". Bare metal gives you the CPU flags without hypervisor blocking am, and that na the trade-off for choosing between a VPS and a dedicated server. Some providers expose nested virtualisation for virtual plans, and nested virtualisation on a VPS explain how to confirm am before you pay. If the hardware already belong to you, Proxmox against a plain VPS ask the same question from the hypervisor side.

The server na only the cheap part. Every machine wey you hand to agent dey spend model tokens as long as e dey run, so idle microVM cost memory, while busy one cost memory and API spend. 1 GB plan no fit hold the host. Plan wey fit hold the host still no go pay the key.

FAQ

How I fit check whether my VPS fit run Firecracker?

Run ls -l /dev/kvm, systemd-detect-virt and grep -cE '\b(vmx|svm)\b' /proc/cpuinfo for the VPS. If device node dey owned by kvm group, and flag count dey above zero, Firecracker fit run. If node no dey and count na 0, hypervisor no dey pass virtualisation through. sudo kvm-ok from cpu-checker package go confirm am with KVM acceleration can NOT be used. For arm64, ignore the count, because vmx and svm na x86 names.

I fit enable nested virtualisation from inside my VPS?

No. Host na e dey switch on nested virtualisation, inside the hypervisor own kernel module. E dey reach you as CPU flag for the virtual processor wey dem give you. Inside the guest, sudo modprobe kvm_intel returns modprobe: ERROR: could not insert 'kvm_intel': Operation not supported because virtual CPU no get VMX to use. Your options na provider wey offer nested virtualisation for the plan, or machine wey you own the hypervisor.

Container alone fit sandbox coding agent?

Most times, yes. Container dey share your kernel, so kernel-level escape fit reach host. But disposable container for machine wey no hold valuable credentials go remove most of the risk wey you really face. Choose microVM when agent dey run unattended for long time against code wey you never review, and when you fit give am host wey get /dev/kvm. When you no fit do that, container wey you destroy after every task better pass microVM wey you never manage to boot.

How much RAM microVM agent host need?

Start with the guest size. One headless guest at 1 GB, plus 3 GB host reserve, need about 4 GB altogether. 8 desktop guests at 2 GB each need about 19 GB. Disk na separate matter, and e easy to underestimate, because host dey keep kernel, root filesystems, one image for every guest flavour, and snapshot for every machine wey dey run.