PandaStack vs GitHub Codespaces

I built PandaStack, so start with the bias disclosure and then the useful part: GitHub Codespaces is not my competitor, and pretending otherwise would waste your time. Both products hand you a computer in the cloud with your repo already in it, which is why they show up in the same searches. But Codespaces is optimised for a human being who wants to write code with an editor, and PandaStack is optimised for a program that wants to run code without one. Those are opposite consumers, and almost every design difference — lifecycle, billing shape, how you define the environment, how many you can have at once — falls out of that single split. This post is the honest head-to-head, including the parts where the answer is "use Codespaces" and the parts where the answer is "use both."

What each one actually is

GitHub Codespaces is a cloud development environment attached to a GitHub repository. You define it with a `devcontainer.json`, open it in browser VS Code or your local editor, and get a long-lived, stateful workspace you come back to: your shell history, your uncommitted changes, your running dev server, your extensions. It inherits GitHub auth and repository permissions, which is a genuinely large convenience — no token plumbing to clone a private repo, because the environment already knows who you are. Prebuilds exist to cut the wait on a cold start, and idle timeouts stop the machine when you walk away. It is, in the best sense, an ordinary developer machine that happens to live somewhere else.

PandaStack is a sandbox API. You call `create`, get a Firecracker microVM with its own guest kernel in about 179ms at p50 (~203ms p99), run a command, read a file, and destroy it. There is no editor, no browser IDE, no extension marketplace, and no notion of "your" workspace — a sandbox is a disposable unit of compute with a TTL. The primitives that matter are the ones a program needs: exec, filesystem read/write, snapshot, and fork. A same-host fork clones a running VM's memory and disk copy-on-write in 400–750ms, which is what lets an agent branch its own state instead of re-running setup.

The tell: if your "developer environment" is being created by a `for` loop, you don't want a developer environment.

That line is the whole decision framework, compressed. A developer environment is something a person opens. If the thing opening it is code — an agent evaluating candidate patches, a CI job fanning out across a matrix, a SaaS backend executing a customer's uploaded script — then the ergonomics you're paying for (an editor, extensions, port forwarding to a browser tab, session persistence across days) are dead weight, and the properties you actually need (create in a loop, hard isolation per invocation, per-second cost, no per-user identity) aren't what the product is shaped around.

Side by side

Read this as "different shapes," not "winner per row." Several of the Codespaces columns are strengths I have no intention of matching.

• Primary consumer — GitHub Codespaces: a human developer, working interactively. PandaStack: a program — an AI agent, a CI pipeline, or a backend running customer code.
• Interface — GitHub Codespaces: browser VS Code, desktop VS Code, JetBrains, or SSH, plus a CLI. PandaStack: REST API, Python SDK, TypeScript SDK, and a CLI. No editor at all.
• Start time — GitHub Codespaces: designed around human-scale waits, with prebuilds specifically to shorten cold starts; measure it yourself on your repo. PandaStack: 179ms p50 create (~203ms p99) via snapshot-restore on every create, ~3s for the very first cold boot of a new template.
• Lifecycle — GitHub Codespaces: a long-lived stateful workspace that idles out and resumes, and that you return to tomorrow. PandaStack: an ephemeral VM with a TTL that is expected to be destroyed, often within seconds.
• Billing unit — GitHub Codespaces: metered against a GitHub account and tied to a codespace a user owns; check GitHub's current pricing docs for rates and included amounts. PandaStack: per-sandbox usage while the VM is alive, with no per-seat notion — a thousand sandboxes belong to an API key, not to a thousand people.
• Isolation boundary — GitHub Codespaces: GitHub documents codespaces as isolated cloud environments; verify the boundary against their docs and security documentation rather than assuming internals. PandaStack: a Firecracker microVM with its own guest kernel, plus a dedicated Linux network namespace and TAP device per sandbox.
• Fork / snapshot — GitHub Codespaces: not the product's model; state persistence is per-workspace, not a branch-my-machine primitive. PandaStack: first-class. Snapshot captures memory plus disk; fork clones a running VM copy-on-write in 400–750ms same-host (1.2–3.5s cross-host).
• Fan-out — GitHub Codespaces: bounded by what a team of humans plausibly opens at once. PandaStack: designed for it — each agent pre-allocates 16,384 /30 network slots, so the practical ceiling is host memory and CPU rather than networking.
• Environment definition — GitHub Codespaces: `devcontainer.json` in the repo, versioned alongside the code, with prebuilds to warm it. PandaStack: a baked template snapshot (`base`, `code-interpreter`, `agent`, `browser`, `postgres-16`, or your own), restored identically on every create.
• Editor and extensions — GitHub Codespaces: the point of the product — VS Code, the extension marketplace, settings sync, port forwarding to a browser tab. PandaStack: none of it, deliberately. Bring your own client.
• Repo and auth integration — GitHub Codespaces: native GitHub identity and repository permissions, so private clones just work. PandaStack: you supply credentials to the sandbox, or use the git-driven app hosting path with a GitHub App installation token.
• Best fit — GitHub Codespaces: onboarding, reviewing a branch, pairing, working from an iPad, standardising a team's toolchain. PandaStack: executing untrusted or model-generated code, agent rollouts, per-tenant execution in a product you sell.

Where the shapes actually diverge

Lifecycle: a workspace you return to vs. a VM you throw away

A codespace is stateful on purpose. The value proposition includes that your half-finished refactor is still there on Monday, that your dev server is still bound to a port, and that an idle timeout suspends rather than deletes. Everything about that is correct for a person. It is exactly wrong for a program: an agent that runs a hundred candidate patches wants a hundred machines that have never seen each other, and wants each one gone the moment it reports an exit code. State that survives is a bug in that world, not a feature — it's cross-contamination between evaluations.

PandaStack's default is the inverse. A sandbox carries a `ttl_seconds`, the reaper takes it if you forget, and `kill()` means the whole machine — kernel, memory, rootfs — ceases to exist. There is a `persistent: true` flag and a hibernate/wake path for the cases that genuinely need to hold state (managed databases, hosted apps), but the ephemeral case is the fast path, and the one the create latency is optimised for.

Billing shape: per-person vs. per-machine-second

I won't quote GitHub's numbers, but the structural point doesn't need them. Codespaces meters compute against an account, and a codespace is owned by a user. That model is coherent when the population of environments tracks the population of engineers. It stops describing your workload when the population of environments tracks the number of tasks your agent decided to try this minute — at that point "who owns this machine?" has no meaningful answer, because nobody does. It existed for four seconds to run one test.

A sandbox API bills per machine-second with no seat concept, which is the only shape that survives contact with a `for` loop. That's not a claim that it's cheaper — model your own numbers — it's a claim that the units line up with the thing you're actually doing.

Isolation: what I'll assert and what I won't

I'll be precise about mine and careful about theirs. Every PandaStack sandbox is a Firecracker microVM with its own guest kernel behind a hardware virtualization boundary, with a dedicated network namespace, veth pair, and TAP device — the same VMM class that AWS Lambda uses to run untrusted code from many customers on shared fleets. That's the property I care about when the code was written by a language model responding to an arbitrary prompt: the boundary doesn't depend on the code inside behaving.

For Codespaces I'm not going to characterise the internals, and you should be suspicious of any vendor who does. GitHub documents codespaces as isolated cloud environments; if the isolation boundary is decision-critical for you — because you're contemplating running third-party or model-generated code in one — read GitHub's own security documentation and ask them directly. No security FUD from me here; "verify it yourself" is the honest answer, not a rhetorical dodge.

Fan-out and forking: 50 variants of the same task

This is the capability gap that has nothing to do with either product being better-engineered — it's a consequence of who each one serves. Nobody needs to open 50 identical editors. But an agent doing best-of-N frequently does want 50 machines that are byte-identical up to the moment it started diverging, and it wants them without re-running `npm ci` fifty times. Fork gives you that: warm one VM to a known-good state, snapshot it, then branch. Memory is shared copy-on-write (`MAP_PRIVATE`, so a page is only copied when something writes it) and the rootfs is cloned via reflink, so fifty branches of one golden VM cost far less than fifty independent ones.

import { Sandbox } from "@pandastack/sdk";

// Warm ONE machine to a known-good state...
const golden = await Sandbox.create({ template: "base", ttlSeconds: 1800 });
await golden.exec(
  "git clone --depth 1 https://github.com/acme/webapp /work/webapp",
  { timeoutSeconds: 120 },
);
await golden.exec("cd /work/webapp && npm ci && npm run build", {
  timeoutSeconds: 900,
});

// ...then branch it N ways. Each fork is 400-750ms same-host, copy-on-write,
// and starts from the identical post-install memory + disk state.
const results = await Promise.all(
  patches.map(async (patch) => {
    const branch = await golden.fork();
    try {
      await branch.filesystem.write("/work/webapp/candidate.diff", patch);
      const run = await branch.exec(
        "cd /work/webapp && git apply candidate.diff && npm test",
        { timeoutSeconds: 600 },
      );
      return { patch, passed: run.exitCode === 0 };
    } finally {
      await branch.kill();
    }
  }),
);

console.log(`${results.filter((r) => r.passed).length}/${results.length} pass`);
await golden.kill();

Programmability: an SDK call vs. an editor session

Codespaces has a CLI and an API, so "programmatic" isn't binary — you can automate it. But the centre of gravity is an interactive session, and automation lives at the edges. PandaStack has no interactive session at all; the API is the only surface, which means there's no ergonomic penalty for being a machine. Here's the entire shape of "run one piece of model-written code safely and throw the evidence away":

from pandastack import Sandbox


def run_candidate(source: str) -> tuple[int, str]:
    """Execute one LLM-written script in its own microVM, then destroy the VM."""
    # ~179ms p50 to create: every create restores a baked Firecracker snapshot.
    sbx = Sandbox.create(template="code-interpreter", ttl_seconds=120)
    try:
        sbx.filesystem.write("/work/solution.py", source)
        result = sbx.exec("python /work/solution.py", timeout_seconds=60)
        return result.exit_code, result.stdout
    finally:
        # The kernel, the memory, and the disk all go away. Nothing to clean up.
        sbx.kill()


# The `for` loop is the tell. No human is opening any of these.
for candidate in llm_candidates:
    exit_code, stdout = run_candidate(candidate)
    print("exit", exit_code, "|", stdout.strip()[-200:])

The `ttl_seconds` is belt-and-braces: if your process dies mid-loop, the sandboxes reap themselves instead of billing until someone notices. That is a very different failure mode from a forgotten editor tab, and it's the one you want when the creator is a program.

Environment definition: devcontainer.json vs. a baked snapshot

Both models solve "everyone gets the same machine," from opposite ends. A `devcontainer.json` lives in the repo, is reviewed like code, and describes the environment declaratively — which is genuinely excellent for a team, because the environment evolves in the same pull request as the code that needs it. Something like this (illustrative; check the current schema in GitHub's devcontainer docs):

{
  "name": "webapp",
  "image": "mcr.microsoft.com/devcontainers/typescript-node:22",
  "forwardPorts": [3000],
  "postCreateCommand": "npm ci",
  "customizations": {
    "vscode": {
      "extensions": ["dbaeumer.vscode-eslint", "esbenp.prettier-vscode"]
    }
  }
}

A PandaStack template is the other end: you bake a Firecracker snapshot once — a machine that has already booted, already installed the toolchain, already warmed whatever caches you care about — and every create restores that exact memory and disk state. An image gives you a consistent filesystem; a memory-plus-disk snapshot gives you a consistent running machine, which is why the restore is measured in milliseconds rather than in `postCreateCommand` seconds. The trade is directness: a devcontainer is a text file anyone on the team can edit in a PR, while a template snapshot is an artifact you build. Declarative-and-flexible versus baked-and-instant. If your environment changes on every branch, the devcontainer model is more pleasant. If ten thousand creates a day all want the identical machine, baking wins.

The boring, correct answer: use both

Most teams I talk to that end up on a sandbox API did not stop using their dev environment. The two live at different points in the pipeline, and the split is clean once you name it: humans author, machines execute.

1. Authoring — a developer opens a Codespace (or a local devcontainer) with the editor, extensions, debugger, and port forwarding, and writes the code. This is a human doing human work, and an IDE in the cloud is the right tool.
2. Execution — CI, your agent, or your product's backend spawns short-lived isolated VMs through a sandbox API to actually run things: test matrices, agent rollouts, customer-submitted scripts, per-tenant code execution.
3. Shipping — the artifact goes to whatever hosts it. If that's on the same microVM substrate, fine; if it's Vercel or your own Kubernetes, also fine. Nothing about this argument requires consolidating.

Choosing between them is only necessary if you've mistaken one for the other — which is easy to do, because both are accurately described as "a computer in the cloud with my repo in it."

What PandaStack is not

Stated plainly so nobody discovers it in week two:

• It is not an IDE. There is no browser editor, no attach-your-VS-Code story polished to Codespaces' standard, and no debugger integration.
• There is no extension marketplace, no settings sync, and no dotfiles-on-first-boot convention.
• There is no built-in GitHub identity for interactive use. Sandboxes don't inherit your repository permissions; you pass credentials in, or use the app-hosting path where a GitHub App installation token is minted per deploy.
• It is not designed around a workspace you return to for three weeks. You can pin a sandbox persistent, but the product's centre of gravity is machines that live for seconds.
• If what you want is browser VS Code for your team, connected to your repos with permissions that already work — that is Codespaces, and you should use Codespaces. I'd rather say that than sell you the wrong primitive.

When to pick which

Pick GitHub Codespaces when a person is the consumer: onboarding a new hire without a day of toolchain archaeology, reviewing a colleague's branch in a clean machine, pairing, standardising a team on one environment definition that lives in the repo, or working from a machine you can't install anything on. The GitHub-native auth and permissions alone are worth a lot, and no sandbox API is going to hand you a better editor experience.

Pick a sandbox API like PandaStack when a program is the consumer: an AI agent that needs to execute code it just wrote, a CI system fanning out across a matrix, a SaaS product running customer-supplied code, or any workload where you need hundreds of short-lived isolated environments per hour created in code, with no per-seat model and a hard isolation boundary per invocation. The forking primitive is the tiebreaker if branch-and-explore is central to your product — warming one machine and cloning it 50 times in under a second each is a shape a workspace product has no reason to offer.

As always: build the one-hour spike rather than trusting the table. Measure create latency in your region, run your real workload, and check whether the lifecycle and billing units match the thing you're actually building. If the answer to "who opens this environment?" is "a `for` loop," you already know which side of the line you're on. If you're surveying the wider field, /blog/e2b-alternatives covers the sandbox-API side, and /blog/cloud-dev-environments-on-microvms covers running dev-environment workloads on this substrate directly.