PandaStack vs Cloudflare Workers for Untrusted Code

If you're weighing PandaStack against Cloudflare Workers for running code — especially untrusted or AI-generated code — the cleanest framing is this: Cloudflare Workers run JavaScript and WebAssembly in V8 isolates distributed across the edge, while PandaStack runs anything inside a full Firecracker microVM. Workers are a phenomenal way to run trusted, stateless functions close to the user at enormous scale. PandaStack is built for the opposite shape of problem: an arbitrary binary, any language, a full Linux userspace, and a hardware-virtualization boundary around code you didn't write. They both "run your code," but the isolation model, the runtime constraints, and the workloads they're good at are genuinely different. This post walks the axes fairly, including the cases where Cloudflare Workers are the right answer and PandaStack is the wrong one.

Isolation model: V8 isolates vs Firecracker microVMs

This is the dimension everything else hangs on, so it's worth getting precise. Cloudflare Workers run your code in a V8 isolate — the same lightweight sandbox primitive a browser tab uses. Many isolates share a single operating-system process, and the isolation boundary is V8's own sandbox plus Cloudflare's runtime hardening, not a separate kernel per tenant. The upside is enormous: isolates are cheap to spin up, so cold starts are very fast and density is extremely high. The constraint is that the boundary is a language-VM boundary, not a hardware-virtualization one, and Cloudflare invests heavily in hardening it precisely because that's a meaningfully different threat model than a per-tenant kernel.

PandaStack puts every workload inside its own Firecracker microVM: a real KVM hardware-virtualization boundary with a dedicated guest kernel, its own network namespace, and its own filesystem. If the code inside does something hostile, the blast radius is one VM. This is the same isolation primitive AWS Lambda uses under the hood — but PandaStack exposes it directly as a sandbox you drive from an SDK, rather than hiding it behind a function runtime. The trade is honest: a microVM carries more weight than an isolate, so a cold create is heavier than spinning up an isolate. PandaStack's answer to that is snapshot-restore, covered below.

What can actually run inside?

This is the most practical difference and the one most likely to decide your choice. Because Workers run inside a V8 isolate with no full operating system underneath, the execution environment is constrained by design:

• Language surface — JavaScript and TypeScript natively, WebAssembly for compiled languages, and Python via Pyodide (which is itself WASM). That covers a lot, but it is not "any language with a Linux toolchain."
• No arbitrary native binaries — you can't shell out to an arbitrary executable, spawn a child process, or run a CLI tool that expects a normal Linux process model. There's no general-purpose subprocess execution.
• No full filesystem — there's no POSIX filesystem the way a process expects one; persistent state lives in Cloudflare's own primitives (KV, R2, D1, Durable Objects) rather than a writable disk you mount.
• Platform-shaped APIs — the Worker is built around the request/response model and the Web Platform API surface, which is great for what it targets but is not a general Unix environment.

PandaStack inverts every one of those. Inside a sandbox you have a full Ubuntu userspace: run any binary, in any language, spawn subprocesses, write to a real filesystem, install packages with apt or pip or npm, run a headless Chromium, compile and execute native code. If an AI agent generates a shell script that pipes ffmpeg into a Python script that writes a SQLite file, that just works — it's a normal Linux machine. The flip side is also true: if all you need is a tiny JS function that transforms a request, a whole microVM is overkill and a Worker is the cleaner tool.

Cold-start: edge isolates vs snapshot-restore

Cold-start is where Workers' design genuinely shines and where the naive intuition ("a VM must be slower than an isolate") deserves a closer look. Spinning up a V8 isolate is extremely cheap, which is exactly why Workers can scale to huge fan-out with negligible warm-up and run at the edge close to users. For trusted, stateless, high-volume request handling, that latency profile is hard to beat, and I won't quote a Cloudflare number — verify their published figures against your own region and workload.

PandaStack closes most of the gap with snapshot-restore. There is no warm pool of idle VMs — every create restores a baked Firecracker snapshot on demand. The restore step itself is about 49ms; end to end, a create lands at roughly 179ms p50 (p99 ~203ms), including patching networking and resuming the guest. The first-ever spawn of a brand-new template does a full cold boot (~3s) and bakes the snapshot; after that, every create takes the fast restore path. So you get full-VM isolation at latencies people usually associate with containers — not as cheap as an isolate, but in a completely different league from booting a VM from scratch on every request.

The architectural point: Workers win on raw start latency and edge proximity because an isolate is lighter than a microVM, full stop. PandaStack's bet is that snapshot-restore makes a microVM cheap enough to start that you can have hardware isolation per task without paying VM-boot prices — a different optimization aimed at a different workload.

Statefulness, snapshots, and forking

Workers are stateless by design; durable state is offloaded to Cloudflare's storage primitives, and Durable Objects give you a single-threaded, addressable coordination point. That model is excellent for the edge, but it's a different shape from "a live machine you can pause and branch." PandaStack treats a sandbox as a stateful machine with copy-on-write superpowers:

• snapshot() captures the full VM — memory and disk — so you can restore the exact running state later.
• fork() branches a running sandbox using copy-on-write: guest memory is shared via MAP_PRIVATE (the kernel only copies a page on write) and the rootfs is cloned with an XFS reflink (data shared until written). A same-host fork lands in roughly 400–750ms; a cross-host fork (GCS download plus restore) is about 1.2–3.5s.
• hibernate() / wake() lets an idle sandbox sleep and resume on the next request (auto-wake), which is how scale-to-zero works without losing in-memory state.

Why this matters for agents: a loop often wants to try several branches from a common starting point — install dependencies once, load a dataset, warm a REPL, then fork N times and explore in parallel, each starting from the exact same memory state without re-running setup. Forking a VM in well under a second makes that cheap. A stateless isolate model makes you rebuild state every invocation. If your workload is tree-search, agent rollouts, or "try five fixes and keep the one that passes," forking is the feature to evaluate hardest; if your workload is idempotent request handling, you don't need it and the stateless model is simpler.

Head-to-head, at a glance

The honest one-line-per-axis version — read it as "different tools," not "winner vs loser":

• Isolation boundary — PandaStack: Firecracker microVM, dedicated guest kernel, KVM hardware boundary per workload. Cloudflare Workers: V8 isolate sharing an OS process, hardened language-VM boundary.
• What can run — PandaStack: any binary, any language, full Linux userspace, subprocesses, real filesystem. Cloudflare Workers: JavaScript/TypeScript, WebAssembly, and Python via Pyodide; no arbitrary native binaries or general subprocess execution.
• Cold-start — PandaStack: ~49ms restore step, ~179ms p50 create via snapshot-restore (no warm pool), ~3s on first-ever template boot. Cloudflare Workers: very fast isolate startup at the edge (verify their published figures).
• State model — PandaStack: stateful VMs with snapshot, copy-on-write fork (400–750ms same-host), hibernate/wake. Cloudflare Workers: stateless functions; durable state via KV, R2, D1, Durable Objects.
• Edge distribution — PandaStack: regional microVM hosts, not a global edge PoP network. Cloudflare Workers: runs across Cloudflare's global edge close to users — a genuine strength PandaStack does not match.
• Best fit — PandaStack: untrusted/AI-generated code, stateful agent sessions, full-Linux workloads, fork/snapshot patterns. Cloudflare Workers: trusted, stateless JS/WASM at huge scale with edge latency.
• Deployment — PandaStack: open-source Apache-2.0 core, self-hostable on your own KVM hosts, plus a hosted API. Cloudflare Workers: fully managed on Cloudflare's network.

Platform breadth around the sandbox

Sandboxes are ephemeral by design, so what holds state around them matters. Beyond raw execution, PandaStack ships a few things on the same microVM substrate and one bill:

• Managed PostgreSQL 16 — each database runs in its own dedicated Firecracker microVM with a durable volume, pgvector plus other extensions, PgBouncer pooling, and connectivity over native postgres:// (SNI-routed TLS) or an HTTP query broker. Create takes 30–90s because it blocks until Postgres is genuinely ready.
• Git-driven app hosting — connect a repo, PandaStack auto-detects the framework (next/vite/cra/node/static/python), does blue-green deploys, supports GitHub push-to-deploy, and scales to zero via auto-hibernate.
• Serverless functions with cron schedules — code bundles you invoke directly or over HTTP, with scheduled triggers.
• Durable volumes — persistent disk for sandboxes that need state beyond the ephemeral copy-on-write rootfs.

Cloudflare's platform is, if anything, broader in its own direction — KV, R2, D1, Queues, Durable Objects, and a global edge are a deep, mature ecosystem that PandaStack does not try to replicate. The distinction isn't "more features"; it's the center of gravity. Cloudflare's gravity is the edge and stateless request handling at planetary scale. PandaStack's gravity is hardware-isolated, stateful, full-Linux execution. Pick the platform whose center of gravity matches your product.

What using PandaStack looks like

PandaStack ships a Python SDK (pandastack), a TypeScript SDK (@pandastack/sdk), and a CLI (pandastack). The client reads PANDASTACK_API_KEY from the environment and talks to a configurable base URL, so the same code points at the hosted API or your own self-hosted control plane with one env var. Here's the canonical "run untrusted code in an isolated VM" flow in Python — create a sandbox, exec a command, read the result, then fork:

from pandastack import Sandbox

# Spin up an isolated Firecracker microVM (~179ms p50 via snapshot-restore)
sbx = Sandbox.create(
    template="code-interpreter",
    ttl_seconds=300,
    metadata={"task": "run-agent-snippet"},
)

# Run untrusted, agent-generated code inside the VM's own kernel.
# This is a real subprocess on a real Linux machine — not a V8 isolate.
result = sbx.exec(
    "python -c 'import sys; print(sys.version)'",
    timeout_seconds=30,
)
print(result.stdout, result.exit_code)

# Arbitrary binaries work too — no language or subprocess restriction.
sbx.exec("bash -lc 'pip install requests -q && python fetch.py'")

# Persist a file to a real filesystem, then branch the running state
# with copy-on-write (~400-750ms same-host).
sbx.filesystem.write("/work/out.txt", "hello from inside the microVM")
branch = sbx.fork()
branch.exec("echo exploring an alternate path")

The shape to notice: you're not deploying a request handler, you're operating a machine. exec, filesystem read/write, snapshot, fork, hibernate/wake. That API surface is the tell for what PandaStack is optimized for — and the thing a V8 isolate, by design, doesn't give you.

When to pick which — honestly

Here's the straight version rather than pretending PandaStack wins every row.

Pick Cloudflare Workers when

• Your unit of work is trusted JavaScript/TypeScript or WASM you wrote — request transformation, APIs, edge middleware, stateless glue.
• Edge latency and global proximity to users are first-order requirements — running close to the user at thousands of locations is a core Workers strength PandaStack does not match.
• You want extreme scale and density for stateless functions with negligible warm-up, and the V8-isolate constraints (no arbitrary binaries, no general filesystem) are fine for your code.
• You're already invested in Cloudflare's ecosystem — KV, R2, D1, Durable Objects, Queues — and want your compute next to that storage.

Pick PandaStack when

• You're running untrusted or AI-generated code and want a hardware-virtualization boundary with its own kernel per task, not a shared-process isolate.
• The code needs a full Linux userspace — arbitrary binaries, any language, subprocesses, a real filesystem, package installs at runtime.
• Your agent benefits from stateful sandboxes — snapshot a setup, fork it cheaply (400–750ms same-host) to explore branches in parallel, hibernate/wake for scale-to-zero.
• You want the surrounding platform on one substrate: managed PostgreSQL 16, durable volumes, and git-driven app hosting to deploy what the agent builds.
• You need to self-host on your own KVM hosts for data-residency, compliance, or VPC isolation — the core is Apache-2.0.

The bottom line

Cloudflare Workers and PandaStack are not really competing for the same job. Workers are a superb edge runtime for trusted, stateless JavaScript and WebAssembly, with isolate-level cold starts and global distribution that a microVM platform simply doesn't match. PandaStack is built for the other half of the problem: untrusted, AI-generated, or arbitrary code that needs a full Linux machine and a hardware-virtualization boundary per task — delivered via snapshot-restore (~49ms restore, ~179ms p50 create, no warm pool), first-class copy-on-write forking (400–750ms same-host), and a broader platform spanning managed PostgreSQL, app hosting, and functions, with an open-source Apache-2.0 core you can self-host. If you're running code you wrote and you want it at the edge, reach for Workers. If you're running code you don't control and you need a real machine around it, that's exactly what PandaStack is for. Either way, prototype against the one that fits your workload — see the quickstart and SDK docs to get a sandbox running in a few minutes, and /blog/e2b-alternatives for a wider survey of the field.