Can your VPS run Firecracker microVMs?

Can your VPS run Firecracker microVMs?

Your VPS can run Firecracker microVMs only if it gives you /dev/kvm. Firecracker is a VMM (virtual machine monitor) built on KVM (kernel-based virtual machine), the virtualisation layer inside Linux, and KVM needs virtualisation instructions from the CPU. On a VPS you get those instructions only when the provider passes them through to your guest, and most plans do not.

So the first question is not which microVM tool to install. It is whether the machine you already pay for can host one at all. That is a hosting question, and you can answer it in about a 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 that can host microVMs answers like this:

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

The first line is the KVM device node, owned by the kvm group. The second line says this machine is itself a guest running under KVM, which is normal and expected on a VPS. The third line counts the CPU cores that report the hardware virtualisation flag, vmx on Intel and svm on AMD. A count above zero inside a guest means the hypervisor is exposing nested virtualisation to you.

Then check that your user can open the device. This is the test from Firecracker's own getting started document:

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

FAIL while the node exists is a permission problem rather than a hardware one. Grant access to your own user with sudo setfacl -m u:${USER}:rw /dev/kvm, or add yourself to the group with sudo usermod -aG kvm ${USER} and log in again.

Ubuntu also ships a check that summarises all of this in two lines of output:

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

A host that works prints INFO: /dev/kvm exists and then KVM acceleration can be used. A host that cannot prints INFO: Your CPU does not support KVM extensions and then KVM acceleration can NOT be used. On a physical machine you may instead see INFO: KVM (vmx) is disabled by your BIOS, which is fixable in firmware. On a VPS that message is rare, because you are not looking at real firmware.

What does each /dev/kvm answer mean?

The node exists and the flag count is above zero. You have hardware virtualisation, so Firecracker will run. Skip to the sizing section, because your remaining constraint is memory rather than CPU features.

No node, systemd-detect-virt prints kvm or qemu, and the flag count is 0. Your VPS is a virtual machine whose host is not passing virtualisation through. Nothing you install inside the guest changes this, because the flag is a property of the virtual CPU that the hypervisor built for you. sudo modprobe kvm_intel fails with modprobe: ERROR: could not insert 'kvm_intel': Operation not supported, and sudo dmesg | grep -i kvm records the missing hardware support. This is the common case on shared VPS plans. Ask the provider whether the plan supports nested virtualisation. If the answer is no, you need different hosting, not a different command.

systemd-detect-virt prints lxc, lxc-libvirt or openvz. Your plan is container virtualisation, so you share the host's kernel. /dev/kvm will never appear, because you have no kernel of your own to load a module into. No package fixes this either.

The flags are there and the node is not. The module is simply not loaded. Run sudo modprobe kvm_intel (or kvm_amd on AMD) and check ls -l /dev/kvm again. If the node appears, write the module name into /etc/modules-load.d/kvm.conf so it comes back after a reboot.

You are on arm64. vmx and svm are x86 names, so the grep count is 0 on every arm64 machine, working or not. On arm64, trust the device node and the read and write test instead.

Why a microVM and not a container for agent work

A container is a process on your kernel, fenced off with namespaces and cgroups. There is one kernel and it is yours, so a kernel level escape lands on the host. A microVM boots a kernel of its own inside a hardware virtualisation boundary, and it talks to a small emulated device model rather than to your host's full system call surface. Firecracker keeps that model deliberately small, which is the whole design: fewer emulated devices means fewer ways out.

That difference matters for a coding agent, because the code an agent runs is code nobody read first. It installs packages, it runs build scripts, and it retries at machine speed when something fails. A separate kernel means a bad step damages a machine you can delete, and nothing else.

The requirement follows directly from the mechanism. Hardware isolation needs hardware virtualisation, and hardware virtualisation is exactly the thing your VPS plan may not give you. A container needs none of it, which is why containers run on every plan ever sold.

So when /dev/kvm is missing, the container-based disposable VM for coding agents stays the right answer, and it is a real control rather than a consolation prize. A throwaway container, on a host that holds no credentials you care about, restored from a snapshot whenever it misbehaves, stops most of what actually goes wrong. The same is true of the plainer setup in running a coding agent on a VPS. Reach for a microVM when an agent will run unattended, for hours, against code you have not reviewed, and when the host is yours to give.

What a microVM agent host asks for

Nehemiah is a current example of the class: an Apache-2.0 daemon that hands an AI a real Linux machine on demand, one Firecracker microVM per machine. Its README states the requirement without hedging: "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".

The documented setup is one command aimed at 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 runs a preflight over SSH and stops early when the box is wrong. Its two hardware refusals read:

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

That first string is the whole point of this post. The installer asks the same question you just asked with ls -l /dev/kvm, and on most VPS plans it gets the same disappointing answer.

Past preflight it is a whole box install: Firecracker and its jailer, a Go toolchain, a guest kernel and root filesystem, a Python guest image, an optional desktop image with a browser, and two systemd units named nehemiahd.service and boring-net.service. The daemon then answers on port 8080, and a failed health check prints /healthz didn't return ok. SKIP_DESKTOP=1 skips the desktop image, which the README says takes around 8 minutes to build.

Read the caveats before you paste that command

It wants root SSH on a fresh host. The installer writes system packages, systemd units and network configuration as root. Point it at a machine you are willing to rebuild from nothing, not at the server that already runs your site.

The daemon binds 0.0.0.0:8080 by default. Anyone who reaches that port can create machines, and those machines spend the model key you handed the installer. Set NEHEMIAH_TOKEN to require authentication, or set BIND_LOCALHOST=1 so the daemon binds 127.0.0.1 only and you reach it through a tunnel with ssh -N -L 8080:127.0.0.1:8080 root@YOUR_BOX_IP. The key deserves the same care as any other secret on the box, as in keeping secrets out of AI agents.

Every machine is a computer with internet access and agents preinstalled. The README lists claude, codex, cursor and pi inside the guest, next to node, python and git. The project says guests sit behind an egress firewall, and the isolation boundary itself is real. The guest still reaches the network by design, because a coding agent that cannot fetch a package is useless. Plan for that instead of assuming an air gap.

There is no tagged release. As of 10 August 2026 the repository has no tags at all, so cloning main gets you whatever landed that morning. Pin to a commit, and read the script before it runs as root on your server:

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

The repository was created at the end of June 2026, so treat it as young software. Read infra/setup.sh again after every update you pull, since the thing you are approving is root access to a machine, not a library version bump.

Prove KVM works before you blame the installer

If setup fails and you want to know whether KVM is the reason, test Firecracker on its own. These are the 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

A printed version proves the binary matches your architecture and runs. It does not prove KVM access, so pair it with the read and write test on /dev/kvm from earlier. Together the two separate a hosting problem from a packaging problem, which saves you from debugging an installer that was right all along.

How much server do several microVMs need?

Each microVM holds a real guest kernel plus the memory you assign it, and that memory is committed for as long as the machine runs. So size the host from the guest size and the number you want at once. The figures below are arithmetic, not measurements. A headless guest gets 1 GB and a desktop guest with a browser gets 2 GB. The host keeps a flat 2 GB back 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 wants about 3 GB, which a mid-size VPS can hold when it gives you KVM. Four of them want 6 GB. Run 8 desktop machines and the same arithmetic asks for 18 GB before you count a single gigabyte of disk.

Disk is the number nobody plans for. The host stores a guest kernel, a base root filesystem, one image per guest flavour and a snapshot per running machine, and the desktop image with a browser is the large one. The README gives no disk figure, so watch df -h / during the first build rather than trusting a guess.

This is why the honest answer to "which VPS runs Firecracker" is often "a different class of machine". Bare metal gives you the CPU flags with no hypervisor in the way, which is the trade-off in choosing between a VPS and a dedicated server. Some providers do expose nested virtualisation on virtual plans, and nested virtualisation on a VPS covers how to confirm it before you pay. If the hardware is already yours, Proxmox against a plain VPS is the same question asked from the hypervisor side.

The server is also the cheap half. Every machine you hand to an agent spends model tokens for as long as it runs, so an idle microVM costs memory while a busy one costs memory and API spend. A 1 GB plan cannot hold the host. A plan that could hold the host still will not pay the key.

FAQ

How do I check whether my VPS can run Firecracker?

Run ls -l /dev/kvm, systemd-detect-virt and grep -cE '\b(vmx|svm)\b' /proc/cpuinfo on the VPS. A device node owned by the kvm group, together with a flag count above zero, means Firecracker can run. A missing node with a count of 0 means the hypervisor is not passing virtualisation through, and sudo kvm-ok from the cpu-checker package confirms it with KVM acceleration can NOT be used. On arm64, ignore the count, because vmx and svm are x86 names.

Can I enable nested virtualisation from inside my VPS?

No. Nested virtualisation is switched on by the host, in the hypervisor's own kernel module, and it reaches you as a CPU flag on the virtual processor you were given. Inside the guest, sudo modprobe kvm_intel returns modprobe: ERROR: could not insert 'kvm_intel': Operation not supported because the virtual CPU has no VMX to use. Your options are a provider that offers nested virtualisation on the plan, or a machine where you own the hypervisor.

Is a container enough to sandbox a coding agent?

Often yes. A container shares your kernel, so a kernel level escape reaches the host, but a disposable container on a machine that holds no valuable credentials removes most of the risk you actually face. Choose a microVM when an agent runs unattended for long stretches against unreviewed code, and when you can give it a host with /dev/kvm. When you cannot, a container you destroy after every task beats a microVM you never manage to boot.

How much RAM does a microVM agent host need?

Start from the guest size. One headless guest at 1 GB with a 2 GB host reserve wants about 3 GB in total, and 8 desktop guests at 2 GB each want about 18 GB. Disk is separate and easy to underestimate, because the host keeps a kernel, root filesystems, one image per guest flavour and a snapshot for every running machine.