Firecracker vs CheerpX / WebVM: where does the code run?

"Firecracker vs CheerpX" looks like a comparison and is really a fork in the road. CheerpX — the engine behind WebVM, from Leaning Technologies — runs a Linux userland inside a browser tab: a WebAssembly x86 emulator with a JIT, a virtual block device, and no server at all. Firecracker is a server-side KVM microVM: a real guest kernel behind hardware virtualization, running on your infrastructure. Both let you run a shell and untrusted code, so they get benchmarked against each other. But they answer different questions. The first question isn't "which is faster" — it's "where does the code run, and whose machine is it running on?" Everything else follows from that. I'm Ajay; I built PandaStack on the Firecracker side, and I'll be fair to the browser side — but please verify any CheerpX/WebVM specifics against their own docs, which move faster than any blog post.

The short version, so you can leave early if you need to: CheerpX/WebVM is a genuinely wild feat — a whole Linux distro running client-side, no backend to provision, no egress from your servers, and the isolation is the user's own browser sandbox. It's a beautiful fit for playgrounds, docs demos, teaching, and running code you'd rather never touch your infrastructure. Firecracker is for the opposite job: running untrusted code on your infrastructure, at scale, with a real kernel, real networking, and native-ish performance behind a hardware boundary. If the code should run on the visitor's machine, reach for the browser VM. If it must run on yours — for AI agents, code interpreters, per-tenant workloads — you're on the microVM rung. Everything below is the reasoning.

The core difference: whose machine executes the code

Start here, because it's the whole comparison. CheerpX runs entirely in the browser tab. The x86 userland is executed by a WebAssembly engine that JIT-compiles x86 to wasm; the filesystem is a virtual block device streamed on demand (WebVM famously boots a Debian image this way), and the isolation boundary is the browser's own sandbox — the same one keeping every other tab from reading your bank session. There is no server executing anything. That is the headline property and the headline constraint at once: your infrastructure never runs the user's code, so it also never has to be protected from it.

A Firecracker microVM runs on a Linux host you operate, behind KVM hardware virtualization. Each workload gets its own guest kernel, and the guest reaches the outside world only through a tiny set of emulated virtio devices; the boundary is enforced by the CPU's virtualization extensions, not by a language runtime. It's the same VMM AWS Lambda and Fargate use, and it treats every guest vCPU as hostile from the first instruction. The code runs on your machine — which is exactly why you want a hardware boundary around it.

Isolation and performance: a JIT'd emulator vs a native kernel

The isolation models rhyme with where each runs. CheerpX's boundary is the browser's WASM sandbox — a software boundary, per-tab, and honestly a well-hardened one because browsers run hostile internet code all day. The nice property is that the untrusted code and your servers are never in the same place to begin with; the exposure that matters is the user's own browser, not your fleet. Firecracker's boundary is the hypervisor: attacker and host sit in separate address spaces with a separate guest kernel, which is the standard boundary for running mutually-untrusting tenants on shared infrastructure. Neither is magic — both WASM sandboxes and KVM have had real CVEs, and both are exposed to microarchitectural side channels — so frame it by threat model, not a single security dial.

Performance follows the same seam. CheerpX executes x86 by JIT-compiling it to WebAssembly, which is remarkable that it works at all but is fundamentally emulation: you're running x86 semantics on top of a wasm engine on top of the user's CPU, and heavy or long-running workloads feel that. Firecracker runs the guest on the real CPU through KVM, so compute is native-ish and I/O goes through virtio rather than an emulator. I'm deliberately keeping CheerpX qualitative here — I'm not going to invent browser-VM benchmarks, and you should measure your own workload against their docs. The structural point stands regardless of the exact numbers: a JIT'd x86 emulator in a tab and a hardware VM on a server are not in the same performance class, and they were never trying to be.

Side by side

• Where it runs — CheerpX/WebVM: entirely client-side, in the visitor's browser tab; no backend. Firecracker: server-side, on your Linux KVM hosts.
• Isolation — CheerpX/WebVM: the browser's WASM sandbox, per tab. Firecracker: KVM hardware virtualization, its own guest kernel per microVM.
• Execution model — CheerpX/WebVM: x86 JIT-compiled to WebAssembly (emulation) plus a virtual block device. Firecracker: a real guest kernel running on the host CPU via KVM.
• Performance character — CheerpX/WebVM: impressive but emulated; heavy/long workloads pay for it (verify against their docs). Firecracker: native-ish compute, virtio I/O; ~179ms p50 create via snapshot-restore.
• Networking — CheerpX/WebVM: no direct sockets from the tab; egress via a proxy/Tailscale-style relay. Firecracker: real per-sandbox netns with veth + tap (PandaStack: 16,384 /30 subnets per agent).
• Best fit — CheerpX/WebVM: zero-infra playgrounds, docs demos, teaching, running code that should never touch your servers. Firecracker: untrusted/AI-generated code on your infra at scale, code interpreters, per-tenant workloads.

Networking and persistence: the browser's hard walls

Two practical constraints decide a lot of real projects. First, networking: code in a browser tab can't open arbitrary TCP/UDP sockets — the tab only speaks fetch/WebSocket to origins that allow it. WebVM's answer is clever (a Tailscale-style userspace network relay that proxies the guest's traffic out through a WebSocket), but it's a relay, not a raw socket, and it's a different operational shape than "the process just bound to a port." Firecracker gives each guest a real Linux network stack: its own network namespace, veth pair, and tap device, so a process binds a port and listens like any server. PandaStack runs that at scale with NATID — 16,384 pre-allocated /30 subnets per agent, each sandbox in its own namespace with per-sandbox egress isolation.

Second, persistence and lifecycle. A client-side VM lives and dies with the tab: state is the user's browser storage, and there's no server-side snapshot to restore, fork, or hand to a teammate. That's fine — often ideal — for a playground. It's a wall for anything server-side: durable per-tenant databases, an agent that resumes a long task tomorrow, forking a running environment to branch an exploration. Firecracker snapshots and forks whole-machine state on the server: PandaStack restores a baked snapshot in ~49ms (179ms p50 create end-to-end, ~203ms p99), same-host forks a running machine in 400–750ms via copy-on-write memory and reflink rootfs (cross-host 1.2–3.5s), and stands up a managed Postgres in 30–90s. None of that is expressible in a tab, because the tab has no server behind it — which is the entire point of CheerpX and the entire limitation of it, depending on your job.

When each is the right call

Reach for CheerpX/WebVM when the code belongs on the user's machine and you'd rather have no backend at all: an interactive playground on your docs site, a "try it in your browser" terminal, a teaching environment, a client-side tool where shipping zero servers is the whole win. If untrusted code never touching your infrastructure is a feature — because then you never have to defend against it — the browser VM turns that into an architecture. It is genuinely the right tool for that shape, and a server-side microVM would be over-building for a problem you could solve with zero infra.

Reach for Firecracker (or a platform built on it) the moment the code has to run on your infrastructure: an AI agent executing model-written commands, a hosted code interpreter, ephemeral CI runners for arbitrary repos, per-customer isolated databases, anything that needs real networking, real performance, durable state, or a server-side lifecycle. The honest reason isn't that a microVM is "more secure" than a browser sandbox in the abstract — it's that it's the only rung that can run a server-side, native-performance, real-network, snapshot-and-fork workload at all, and it happens to come with a hardware boundary you control.

Where PandaStack lands

PandaStack is built on the microVM rung, for the server-side job. Every sandbox is a Firecracker microVM with its own guest kernel (5.10, Ubuntu 24.04 guest), isolated by KVM hardware virtualization — not a browser sandbox and not a shared-kernel container. That means real networking, native-ish CPU, arbitrary native binaries, a real shell, subprocesses, compilers, and the full long tail of native-dependency Python all just work, because there's a real Linux kernel underneath running on the host CPU — not an x86 emulator in a tab. This is the shape AI agents actually need: they run commands you didn't write and can't predict, shell out, install native-dep packages, spawn subprocesses, and hit the network, all on your infrastructure.

from pandastack import Sandbox

# Server-side microVM: real kernel, real network, native execution.
# The code runs on YOUR infra, behind a KVM hardware boundary.
with Sandbox.create(template="code-interpreter", ttl_seconds=300) as sbx:
    # install a native-extension package and run it
    print(sbx.exec("pip install --quiet lxml && python3 -c "
                   "'import lxml.etree as e; print(e.__version__)'",
                   timeout_seconds=120).stdout)

    # real networking: a process binds a real port on a real netns
    print(sbx.exec("python3 -m http.server 8000 & sleep 1 && "
                   "curl -s localhost:8000 | head -n1",
                   timeout_seconds=15).stdout)

The classic objection to the VM rung is cost and cold start, and that's the part the engineering answers. There's no warm pool of idle VMs; every create restores a baked snapshot on demand at 179ms p50 (about 203ms p99), the underlying snapshot restore is roughly 49ms, and only a true first cold boot pays the ~3s kernel-boot tax. Fork a running environment in 400–750ms same-host. The core is Apache-2.0 and self-hostable on your own Linux KVM hosts. None of that makes the microVM the right answer for a browser playground — if the code should run on the visitor's machine with zero backend, CheerpX/WebVM is the more elegant call, full stop. It makes the microVM the right answer for the opposite job: untrusted, unpredictable code that has to run on your infrastructure, fast, at scale.