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í a microVM agent host need

Nehemiah na current example of this kind: Apache-2.0 daemon wey fit give AI one real Linux machine when e need am, with one Firecracker microVM for each machine. E README talk the requirement clearly: "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 fit root-SSH into".

The documented setup na one command wey you run for 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

infra/setup.sh dey run preflight over SSH and e stop early if the box no correct. The two hardware refusals 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 dey ask the same question wey you just ask with ls -l /dev/kvm, and for most VPS plans e go get the same disappointing answer.

After preflight, na full box installation: Firecracker and its jailer, Go toolchain, guest kernel and root filesystem, Python guest image, optional desktop image with browser, plus two systemd units wey dem name nehemiahd.service and boring-net.service. The daemon then dey listen on port 8080, and failed health check go print /healthz didn't return ok. SKIP_DESKTOP=1 dey skip the desktop image, and the README talk say building am dey take around 8 minutes.

Read the caveats before you paste that command

E dey need root SSH for fresh host. The installer dey write system packages, systemd units and network configuration as root. Point am to machine wey you ready rebuild from zero, no be 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 installer. Set NEHEMIAH_TOKEN to require authentication, or set BIND_LOCALHOST=1 so the daemon 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. Treat the key with the same care wey you give any other secret for the box, as shown for keeping secrets away from AI agents.

Every machine na computer wey get internet access and agents already installed. The README lists 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 dey 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.

There is no tagged release. As of 10 August 2026, the repository no get any tags, so cloning main go give you anything wey land that morning. Pin am to commit, and 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

The repository start for end of June 2026, so treat am as young software. Read infra/setup.sh again after every update wey you pull, because the thing wey you dey approve na root access to 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 wey you assign am, and that memory dey 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, no be measurements. Headless guest dey get 1 GB, while desktop guest with browser dey get 2 GB. The host keeps flat 2 GB for itself, the daemon, and 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
  }
]

One headless machine at a time needs about 3 GB. Mid-size VPS fit hold am when e gives you KVM. Four of dem need 6 GB. Run 8 desktop machines, and the same arithmetic needs 18 GB before you count even 1 gigabyte of disk.

Disk na the thing wey nobody dey plan for. The host stores 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 "different class of machine". Bare metal gives you the CPU flags without hypervisor blocking am. 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 explains how to confirm am before you pay. If the hardware already belong to you, Proxmox against a plain VPS asks the same question from the hypervisor side.

The server na also the cheaper half. Every machine wey you give agent dey spend model tokens as long as e dey run. So idle microVM costs memory, while busy one costs 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. Device node wey belong to kvm group, together with flag count wey pass zero, mean say Firecracker fit run. If node no dey and count na 0, e mean say hypervisor no pass virtualisation through, and sudo kvm-ok from cpu-checker package 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 dey switch on nested virtualisation for hypervisor own kernel module, and e reach you as CPU flag for the virtual processor wey dem give you. Inside the guest, sudo modprobe kvm_intel return 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 dey enough to sandbox coding agent?

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

How much RAM microVM agent host need?

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