PandaStack vs Modal: which for AI code execution?

If you're choosing between PandaStack and Modal for AI code execution, the short answer is this: Modal is a serverless Python cloud for running functions, GPU jobs, and batch workloads you wrote yourself, while PandaStack is a Firecracker microVM sandbox platform for running per-task, per-tenant, or untrusted code — the code an AI agent writes at runtime, the script you don't fully trust, the multi-tenant workload that needs a hard isolation boundary. They overlap in the word "compute," but they solve different problems. Pick Modal when the unit of work is a function you own. Pick PandaStack when the unit of work is an isolated environment you hand to something — or someone — you don't control.

I'm Ajay, founder of PandaStack. I'll be specific about what PandaStack does and how it works, and general about Modal — I'm not going to invent Modal's internals or quote numbers I can't stand behind. The goal here is to help you make the right call, not to win an argument.

PandaStack vs Modal: what are they actually for?

The cleanest way to tell these apart is to ask: what is the unit of work, and who wrote the code?

• Modal is a serverless compute platform. You decorate Python functions, push them to Modal's cloud, and it handles packaging, scheduling, autoscaling, and GPU provisioning. The unit of work is a function or job you authored. It shines for batch processing, model inference and training, data pipelines, and on-demand GPU.
• PandaStack is a microVM sandbox platform. You call an API to spin up an isolated environment — a full Linux guest with its own kernel — and then exec commands, read/write files, snapshot it, fork it, or expose a port. The unit of work is an environment, and the code running inside it is frequently code you did not write: an LLM-generated script, a user's submission, an agent's tool call.

That framing drives almost every other difference — isolation model, statefulness, persistence, and cold-start behavior all follow from "function you own" versus "environment for code you don't control."

How does each handle isolation for untrusted or agent code?

This is the difference that matters most if you're running AI-generated or third-party code, because the failure mode isn't a slow job — it's a sandbox escape.

Every PandaStack sandbox, database, and app runs in its own Firecracker microVM. That means a real hardware-virtualization boundary (KVM) and a separate guest kernel per workload — not a shared-kernel container. If agent code does something hostile, it's confined to a VM with its own kernel, its own network namespace, and its own filesystem. This is the same isolation primitive AWS Lambda and other serverless platforms use under the hood, exposed directly as a sandbox you can drive from an SDK.

Modal runs your trusted functions in its own managed sandboxed environment, and it does offer a sandbox primitive for running code. I won't characterize the exact boundary Modal uses for arbitrary code — check their docs for that. The honest distinction is one of intent: Modal is built around running code you wrote and trust, scaled out; PandaStack is built from the ground up around the assumption that the code inside the box is untrusted and needs hardware-level isolation per task.

Cold-start: 179ms snapshot-restore vs serverless warm-up

Cold-start is where the microVM design earns its keep. The naive assumption is that a VM must be slower to start than a container or a serverless function. PandaStack breaks that assumption with snapshot-restore.

PandaStack's p50 sandbox create is 179ms. There is no warm pool of idle VMs sitting around — every create restores a baked Firecracker snapshot on demand. The first spawn of a template does a cold boot and captures a snapshot; every subsequent create restores that snapshot, patches networking, and resumes. A same-host fork is around 400ms. So you get full-VM isolation at latencies people associate with containers.

Serverless platforms like Modal have their own cold-start characteristics — container build/pull, image caching, and warm-pool behavior all factor in, and Modal has invested heavily in making this fast. I'm not going to put a number on Modal's cold-start because it varies by image size, GPU, and configuration. The architectural point is that PandaStack's latency target comes specifically from snapshot-restore of a microVM, which is a different mechanism than keeping warm function containers around.

Statefulness, snapshots, and forking

Serverless functions are designed to be stateless — that's the model, and it's a strength for scaling stateless work. PandaStack goes the other way for agent workflows: a sandbox is a live, stateful machine you can pause, snapshot, and branch.

• 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: memory via MAP_PRIVATE and the rootfs via XFS reflink, so a fork shares pages with its parent until it writes. Same-host fork lands around 400ms.
• hibernate() / wake() lets a sandbox sleep when idle and resume on the next request (auto-wake), which is how scale-to-zero works without losing in-memory state.

Why does this matter for agents? Because an agent loop often wants to try several branches from a common starting point — run three candidate solutions from the same setup state, keep the best. Forking a VM at 400ms makes that cheap. A stateless function model makes you rebuild state every time. If your workload is "explore from a checkpoint," PandaStack's snapshot/fork primitives are a structural advantage; if your workload is "run this idempotent job," you don't need them and the stateless model is simpler. See the snapshots and forks docs for the full lifecycle.

Databases, volumes, and git-driven app hosting

This is where PandaStack stops being "just a sandbox" and becomes a platform you can build a product on. Beyond ephemeral sandboxes, PandaStack ships:

• Managed PostgreSQL 16 — each database runs in its own dedicated microVM with a durable volume, automatic WAL archiving plus daily base backups, pgvector and seven more extensions, PgBouncer connection pooling, and connectivity via native postgres:// (SNI-routed TLS) or an HTTP query broker for edge functions.
• Durable volumes — persistent storage that survives beyond a single ephemeral sandbox.
• Git-driven app hosting — connect a Git repo, PandaStack auto-detects the framework (next/vite/cra/node/static/python), builds it, and serves it behind a stable URL with blue-green deploys, GitHub push-to-deploy, and scale-to-zero via auto-hibernate.

Modal is a compute platform first; it has storage primitives (volumes, dicts) for function workloads, but it is not pitching itself as a managed Postgres provider or a Vercel-style git deploy host. If you need a managed database with pgvector or you want to host the app an agent just built, that's squarely PandaStack territory. If you need to fan out a million inference calls across GPUs, that's squarely Modal territory.

What about GPUs?

Let me be direct, because this is a real trade-off and not in PandaStack's favor. Modal's first-class GPU support — provisioning A100/H100-class accelerators on demand for inference and training — is a core reason people choose it. If your workload is GPU-bound model serving or training, Modal is purpose-built for that and PandaStack is not the tool. PandaStack's templates (base, code-interpreter, agent, browser, postgres-16, claude-agent) target CPU-bound code execution, agent tool-use, headless browsers, and databases. Don't pick PandaStack expecting a GPU cloud.

Self-hosting and licensing

PandaStack's core is Apache-2.0 licensed and designed to be self-hostable on your own KVM hosts. If you have a hard requirement to run untrusted workloads inside your own VPC, on your own hardware, or in a region a managed provider doesn't serve, that matters — you own the agent, the control plane, and the data path. Modal is a managed cloud service; you run on their infrastructure. Neither model is universally better. Managed is less operational burden; self-hostable open source is more control and no vendor lock-in. Choose based on your compliance posture and how much infra you want to own.

What using PandaStack looks like

PandaStack ships a Python SDK (pandastack), a TypeScript SDK (@pandastack/sdk), and a CLI (pandastack). The client reads PANDASTACK_TOKEN from the environment and talks to https://api.pandastack.ai. Here's the canonical "run untrusted code in an isolated VM" flow — create a sandbox, exec a command, read the result:

from pandastack import PandaStack

client = PandaStack()  # reads PANDASTACK_TOKEN from the environment

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

# Execute code the agent generated — confined to this VM's own kernel
result = sandbox.exec(
    "python -c 'import sys; print(sys.version)'",
    timeout_seconds=30,
)
print(result.stdout, result.exit_code)

# Branch the running state with copy-on-write (~400ms same-host)
branch = sandbox.fork()
branch.exec("echo exploring an alternate path")

# Persist a file, then snapshot the whole VM for later restore
sandbox.filesystem.write("/work/out.txt", "hello from inside the microVM")
sandbox.snapshot()

The shape to notice: you're not deploying a function, 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.

Pick Modal when… / Pick PandaStack when…

Here's the honest decision guide. These aren't competitors so much as tools with overlapping silhouettes.

Pick Modal when

• Your unit of work is a Python function or batch job you wrote and trust.
• You need on-demand GPUs for inference or training — this is a core Modal strength and not a PandaStack feature.
• You want a serverless, scale-out model for data pipelines, embeddings, or model serving where statelessness is fine.
• You'd rather not think about VM lifecycle, snapshots, or networking at all — you just want functions in the cloud.

Pick PandaStack when

• You're running untrusted or AI-generated code and you want a hardware-isolation boundary (own kernel) per task, not a shared-kernel container.
• Your agent benefits from stateful sandboxes — snapshot a setup, fork it cheaply (~400ms) to explore branches, hibernate/wake for scale-to-zero.
• You need fast per-task isolation: p50 179ms create via snapshot-restore, with no warm pool to manage.
• You want the surrounding platform: managed PostgreSQL 16 (pgvector, PgBouncer, WAL archiving), durable volumes, and git-driven app hosting to deploy what the agent builds.
• You need to self-host on your own KVM hosts — the core is Apache-2.0.

And if you're building a serious agent product, it's entirely reasonable to use both: Modal for the GPU-heavy inference and batch jobs you own, PandaStack for the per-session isolated sandboxes where the agent runs the code it generates. "AI sandbox vs serverless" is a false binary more often than people assume — the right answer is matching each workload to the tool whose isolation and state model fit it.