Top Platforms for Spinning Up Ephemeral Dev Environments for Coding Agents (2026)

Key points:

• There are two distinct categories, and picking the wrong one wastes weeks: code sandboxes (E2B, Daytona, Modal, Vercel Sandbox, Cloudflare Sandbox) that boot in about a second to run untrusted agent-generated code, and full ephemeral app environments (Qovery, Bunnyshell, plus Coder and GitHub Codespaces on the workspace side) that stand up your whole stack - services, managed databases, secrets, a real HTTPS URL - per branch, per pull request, or per agent task.
• For the inner loop (write code, run it, read output, discard), use a code sandbox: E2B advertises sub-200ms same-region startup and Daytona advertises sub-90ms creation, both billed per second, and Modal exposes the same Sandbox primitive inside a serverless CPU/GPU platform. Verify current numbers on each vendor's docs and pricing pages before you commit.
• For the outer loop (validate a pull request end to end), use a full ephemeral environment: Qovery creates a complete preview environment per pull request inside your own AWS, GCP, Azure, or Scaleway account, or your existing Kubernetes cluster, so an agent can verify a change against real services and databases backed by managed cloud services - and the cloud bill, commitments, and discounts stay in your name.
• Cost control has to be structural, not procedural, because agents create environments at machine rate: per-second or idle-based billing for sandboxes, plus TTL and automatic auto-stop for non-production full environments. Flexera's 2026 State of the Cloud reports wasted cloud spend rising to 29%, and non-production is where that waste concentrates.
• Isolation level and data residency decide the shortlist for regulated teams: shared-kernel containers are not enough for untrusted agent code, which is why sandbox specialists standardized on Firecracker microVMs (measured booting in under 125ms in the NSDI 2020 paper), while BYOC platforms like Qovery and self-hosted Coder keep environments inside your own account, region, and VPC.

---

Coding agents now open pull requests at machine speed. One agent can fan out a dozen attempts at a task in parallel, and a fleet of them can file more PRs in a day than a human team files in a month. Stack Overflow's 2025 survey puts 84% of developers using or planning to use AI tools (Stack Overflow 2025), and the volume of agent-authored changes is climbing with it.

That shifts where the bottleneck lives. Generating code is no longer the hard part. Proving the code works is. And verification happens in non-production environments, which is exactly where most cloud waste already hides. So the interesting question in 2026 is not "which model writes the best code," it is "where does each agent task run, and who pays for it."

We build and operate this kind of infrastructure at Qovery, so I spend a lot of time helping teams answer that. The single most useful thing I can tell you up front: there are two categories here, most "top platforms" lists mash them together, and mixing them up is what costs you weeks.

What is an ephemeral dev environment for a coding agent?

An ephemeral dev environment for a coding agent is a disposable, isolated environment created on demand by an API call for a single agent task and destroyed when that task ends. It comes in two shapes: a code sandbox (one microVM or container with a filesystem, shell, and network, alive for seconds to minutes) and a full ephemeral app environment (a multi-service stack with real databases, secrets, and a public HTTPS URL, alive for hours to days).

A one-line example of each: an E2B sandbox that spins up, runs a pytest suite against a diff, returns the exit code, and disappears; versus a Qovery preview environment that deploys the whole app for a pull request and serves it at its own HTTPS URL so an agent (or a human) can exercise it.

Coding agents changed the requirements versus human dev environments in four ways:

• High concurrency - dozens of parallel attempts at once, not one workstation per person.
• Untrusted generated code - the code running was written seconds ago by a model, so it is hostile by default.
• Machine-speed create and destroy - environments churn continuously, not once per sprint.
• Zero tolerance for a human click - anything that needs a person to approve, resize, or clean up breaks the loop.

An environment that serves an agent well has seven properties: sub-second-to-sub-minute start, filesystem and process isolation, snapshot or fork, a programmatic API or SDK, egress control, machine-readable logs and exit codes, and hard quotas plus TTL. Miss one and the agent either stalls waiting for a human or quietly runs up a bill.

Each shape fails at the other's job. A code sandbox cannot validate a schema migration against a real Postgres plus a queue plus a third-party webhook, because it does not have those things. A full app environment is far too heavy to spin up for a 3-second code execution, because it has to build images and pass health checks first.

A quick terminology cleanup, since people use these words interchangeably and that is why the lists are useless:

• Sandbox - a single isolated compute unit for running code, usually via SDK.
• Preview / ephemeral environment - a full running app tied to a branch or PR, usually with a URL.
• Cloud dev environment / workspace - a long-lived-ish dev machine in the cloud (Codespaces, Coder), built for a human first.
• Staging - a shared, persistent pre-production environment, not per-task and not disposable.

This is a mainstream problem now, not a lab curiosity. Kubernetes hit 82% production use among container users in the 2025 CNCF Annual Survey, which is the substrate most full environments run on, and AI-assisted contributions are now a normal part of the PR queue rather than an experiment.

What are the top platforms for spinning up ephemeral dev environments for coding agents in 2026?

For raw agent code execution, E2B, Daytona, and Modal lead. For agent-driven full-stack environments per pull request, Qovery and Bunnyshell lead. For human-plus-agent dev workspaces under your own governance, Coder and GitHub Codespaces lead. Vercel Sandbox and Cloudflare Sandbox are the pragmatic pick if your product already runs on those platforms.

Here is the categorized verdict, one line per platform and the single case it genuinely wins:

• E2B - open-source (Apache-2.0) Firecracker sandboxes purpose-built for AI agents, Python and JS SDKs, per-second billing, self-hostable. Best when you want microVM isolation you can run in your own cloud.
• Daytona - agent-first sandbox infrastructure advertising sub-90ms creation with snapshots and declarative images. Best when raw inner-loop start time is the priority.
• Modal - a serverless CPU/GPU platform with a Sandbox primitive for untrusted agent code. Best when the agent work needs GPUs or large fan-out.
• Vercel Sandbox - Firecracker microVMs for running untrusted, AI-generated code. Best if your product already lives on Vercel.
• Cloudflare Sandbox - container isolation attached to Workers and Agents. Best if your agents already run on Cloudflare's edge.
• Coder - self-hosted workspaces defined in Terraform, running in your own infrastructure. Best for governance and data residency, workspace-first with agents layered on.
• GitHub Codespaces - devcontainer-based workspaces native to GitHub. Best when agents run inside GitHub Actions or Copilot workflows.
• Bunnyshell - ephemeral environments as a product, per-PR full stacks on Kubernetes. Best for full-stack previews if you want that as a managed layer.
• Qovery - an internal developer platform that creates a full preview environment per pull request inside your own AWS, GCP, Azure, or Scaleway account, or your existing Kubernetes cluster. Best for outer-loop PR verification against real managed databases in your own cloud.

Let me be blunt about what Qovery is not: it is not a sub-second microVM sandbox. If your agent needs to run untrusted code in 200ms, use E2B, Daytona, or Modal. Qovery's job is the outer loop, and the strongest pipelines pair the two categories rather than forcing one to do both.

Two pieces of category context worth knowing. First, the cloud-dev-environment space re-centered on agents: Gitpod rebranded to Ona in September 2025 as "your AI software engineer" (Gitpod is now Ona) and Ona later joined OpenAI in June 2026 (Ona joins OpenAI). Second, if self-hosting is a shortlist filter, E2B (Apache-2.0) and Coder (AGPLv3) are open source and run in your own infrastructure. Daytona started open source; confirm its current licensing directly before you count on it.

Should your coding agent get a code sandbox or a full ephemeral app environment?

Use a code sandbox when the agent's work can be verified by running code or tests in isolation. Use a full ephemeral app environment when the work can only be verified by exercising the running product end to end - anything touching a database schema, auth, background jobs, multiple services, or a third-party integration. Most serious agent pipelines in 2026 use both.

The tradeoff in one line: a sandbox optimizes your latency budget, a full environment optimizes your fidelity budget.

Here is the checklist an agent orchestrator can encode. Does the change touch a migration, a queue, auth, more than one service, or an external webhook? If yes, a sandbox will pass its tests and still ship a broken feature, because the thing that breaks is not in the sandbox.

The realistic 2026 architecture runs both loops:

• Inner loop - the agent writes code, runs it, reads output, and iterates inside a sandbox (E2B, Daytona, Modal). Fast, cheap, disposable.
• Outer loop - the agent pushes a branch, opens a PR, and a full environment (Qovery, Bunnyshell) deploys the whole stack at a real URL for E2E tests, human review, and agent self-review.

A concrete pipeline: the agent iterates in an E2B or Daytona sandbox until the unit tests pass, pushes a branch, and opens a PR. Qovery spins up the full environment in your own cloud with a managed database. Playwright and the agent both hit the preview URL to confirm the feature actually works. The environment auto-stops on inactivity and is destroyed on merge. Nobody clicks anything.

This is why verification, not generation, is the real bottleneck. DORA's 2024 research found that a 25% increase in AI adoption was associated with an estimated 1.5% decrease in delivery throughput and a 7.2% reduction in delivery stability (DORA 2024). More code, faster, with more ways to break - the answer is not less AI, it is better verification. The common mistake I see: mocking the database inside the agent loop, watching the tests go green, and discovering the broken migration in staging, or worse, in production.

How fast can a coding agent actually get a working environment?

Expect three honest tiers. Tier 1, microVM code sandboxes, start in about a second (E2B advertises sub-200ms same-region startup, Daytona advertises sub-90ms creation, and Modal documents containers booting in about one second). Tier 2, container cloud dev workspaces, land in seconds with prebuilds and minutes without. Tier 3, full multi-service app environments with a managed database, land in minutes because they have to build images, provision or seed data, issue TLS, and pass health checks.

What dominates the latency is different in each tier, and that is the part that matters:

• Tier 1 is bounded by microVM or container boot. Firecracker itself boots to application code in under 125ms with under 5 MB of memory overhead per microVM (Firecracker, NSDI 2020). The trick that removes rebuild time entirely is snapshot and resume - Daytona restores saved sandbox state instead of rebuilding it (Daytona).
• Tier 2 is bounded by the image build. GitHub Codespaces prebuilds exist specifically to speed up creation for large repositories (GitHub Codespaces prebuilds), and the default 30-minute idle timeout (GitHub timeout docs) is what quietly determines your cost.
• Tier 3 is bounded by everything a real stack needs: container build, image pull, database provisioning or seeding, DNS and TLS issuance, and health checks. You can cache or pre-warm most of it.

The techniques that cut each tier are known: snapshots and forks, warm pools, layer caching, one shared seeded managed database with per-environment schemas instead of a fresh database per environment, and prebuilt base images.

"Fastest" is the wrong single metric for agents. An agent does not care about a 4-minute PR environment as long as it eventually gets a URL and readable logs. But a 4-minute wait on every code execution destroys the inner loop. So I set expectations honestly for Qovery: preview environments are minutes, not milliseconds, and minutes is the correct budget for outer-loop verification. If you need milliseconds, that is a sandbox's job.

How do you keep ephemeral environments for coding agents from blowing up your cloud bill?

Make cost control structural, not procedural: require per-second or idle-based billing for sandboxes, and enforce TTL plus automatic auto-stop on inactivity for full environments. Manual cleanup fails within a day of running a fleet of agents, and wasted cloud spend already sits at 29% before agents enter the picture (Flexera 2026).

Agent concurrency changes the math. One human developer opens a handful of PRs a week. A fleet of agents can open dozens a day, each wanting a full stack with its own database. The levers that actually work, roughly in order of impact:

• Per-second and idle billing so you pay for work, not wall-clock.
• Snapshot-and-resume instead of rebuild.
• Aggressive TTL on every non-production environment.
• Auto-stop on inactivity for full environments.
• One shared seeded managed database with per-environment schemas instead of a database per environment.
• Right-sized CPU and memory defaults, not the biggest instance "to be safe."
• Hard per-repo and per-agent quotas so a runaway loop cannot create 500 environments.

The governance data backs this up. Workload optimization and waste reduction is the top priority in the State of FinOps 2025, and managing commitment-based discounts sits close behind. Both of those interact directly with where your agent environments run.

That is the BYOC economics argument, stated plainly. When environments run in your own AWS, GCP, Azure, or Scaleway account, or your existing Kubernetes cluster, your committed-use discounts, Savings Plans, and negotiated rates apply to agent environments too, and the spend lands in the account your FinOps team already governs. Vendor-hosted sandboxes bill at the vendor's margin on top of the same underlying compute - which is often the right trade for sub-second inner-loop work, and the wrong one for a fleet of long-lived full stacks.

Qovery's concrete cost mechanisms, sticking to what is documented: preview environments tied to the pull request lifecycle (Qovery preview environments), environment auto-stop for non-production, which Qovery documents as cutting non-prod cost significantly (Qovery deployment rules), and per-environment resource configuration.

A worked example, built only from published price units, with every input labelled as an assumption and none of it presented as a measurement. Assume 30 agent PRs a day, each needing a 4-core full environment kept up for 45 minutes of verification. At the GitHub Codespaces 4-core rate of $0.36/hour (GitHub Codespaces billing), that is 30 x 0.75h x $0.36 = $8.10/day of compute before storage. Now assume the inner loop instead runs each check as a 3-minute sandbox execution on a per-second platform; the same 30 runs cost a small fraction of the same-sized full environment. The exact dollar figure depends entirely on your assumptions. The point is that the pricing unit and the idle policy, not the sticker rate, decide the bill.

How do you isolate and secure environments running untrusted agent-generated code?

Treat every agent environment as hostile by default. Untrusted generated code belongs in microVM or gVisor-class isolation, not a shared-kernel container, backed by short-lived scoped credentials, default-deny egress, per-environment RBAC, and an audit trail of everything the agent deployed.

Isolation runs on a tier ladder, weakest to strongest:

• Shared-kernel container (namespaces and cgroups) - fine for your own trusted code, not a boundary for hostile code, because a kernel exploit escapes it.
• Sandboxed kernel (gVisor) - the Sentry intercepts application syscalls and implements the system API in user space instead of exposing the host kernel directly (gVisor security model).
• microVM (Firecracker) - a real guest kernel with a tiny attack surface, booting in under 125ms (Firecracker, NSDI 2020). This is why the sandbox specialists standardized on it.
• Full VM - strongest isolation, slowest start, rarely worth it for per-task work.

The rest of the controls are not optional once an agent is in the loop:

• Credential hygiene - short-lived scoped tokens, per-environment secrets, and never a production database URL inside an agent environment. Use seeded or anonymized data, not a production copy.
• Network policy - default-deny egress with an allowlist for package registries and model APIs, and private VPC access to internal services only when the environment lives in your own account.
• Governance - per-environment RBAC, audit logs of agent-triggered deployments, and any environment-creation tool scoped so the agent can create and destroy non-production only.

Prompt injection and supply chain risk make the boundary the control, not the model's good behavior. Agent-generated code plus freshly fetched dependencies is a live attack path: prompt injection and excessive agency both sit on the OWASP Top 10 for LLM Applications. You do not defend against that with a better system prompt. You defend against it with the sandbox wall.

BYOC simplifies compliance here because data stays in your own cloud account, region, and VPC, which keeps GDPR, SOC 2, and HIPAA scoping tighter. Self-hosted Coder gives that property for workspaces, and self-hosted E2B or Daytona gives it for sandboxes. One honest note on the full-environment platforms, including Qovery: they run on Kubernetes, which is shared-kernel, so they are the right home for your own code in a PR environment and the wrong home for genuinely untrusted code. That is the case for pairing a microVM sandbox with a full environment rather than asking one tool to do both.

How do you wire ephemeral environments into a coding agent workflow end to end?

An environment is agent-ready only if four operations are each a single API call: create from a git ref or image, get status and URL, stream logs or exec a command, and destroy. Add snapshot or fork for sandboxes and TTL plus auto-stop for app environments. Anything that still needs a human click is not agent-ready.

Creation comes in two flavors, and mature pipelines wire both:

• Git-driven - PR-triggered preview environments (Qovery, Bunnyshell) that appear when the agent opens a pull request.
• API-driven - SDK-triggered sandboxes (E2B, Daytona, Modal) that the agent spins up mid-task.

Feed results back to the agent so it can self-correct: build logs, test output, deploy status, exit codes, and a preview URL the agent can actually browse for functional and visual verification. An agent that can read its own failing logs and open its own preview URL fixes far more of its mistakes before a human ever looks.

A reference flow from task to merge:

1. Agent receives a task and iterates in a sandbox until unit tests pass.
2. Agent pushes a branch and opens a PR.
3. The PR triggers a full ephemeral environment with a real managed database.
4. E2E tests and the agent both hit the preview URL; the agent reads logs and self-reviews.
5. A human approves. On merge, the platform destroys the environment. On inactivity before merge, auto-stop pauses it.

Expose those four operations as MCP tools the agent can call - create, status, logs, destroy - and scope that tool to non-production only, with an audit entry on every call. The details that bite in practice are boring and important: one environment per PR, collision-free hostnames, per-agent quotas so a runaway loop cannot create 500 environments, and rate limits on the platform API so the loop cannot DDoS your own control plane.

Which platform should you pick for your situation?

Pick by constraint, not by hype. Vendor-hosted microVM sandboxes (E2B, Daytona, Modal) when cold start dominates. Your own cloud account with full-stack fidelity (Qovery, Bunnyshell) when pull request verification dominates. Self-hosted workspaces (Coder) when governance and data residency dominate. And run two platforms when your agents do both loops.

By scenario:

• Solo builder shipping an agent prototype - E2B or Daytona for a cheap, fast sandbox; add Modal if you need a GPU.
• AI product running untrusted user code at scale - Modal for GPU and fan-out, E2B if you want microVM isolation you can self-host.
• SaaS team with agents opening PRs on a multi-service app - Qovery for a full env per PR with a real managed database, Bunnyshell as the alternative.
• Regulated enterprise with data residency requirements - Coder for workspaces and Qovery for app environments, both keeping data in your account; self-hosted E2B for sandboxes.
• Team already all-in on GitHub - GitHub Codespaces for the native path, E2B when you need real untrusted-code isolation.
• Team already on Vercel - Vercel Sandbox for inner-loop execution, a full-env platform for the outer loop.
• Team running its own Kubernetes cluster - Qovery or Bunnyshell to put per-PR environments on the cluster you already operate.

When you combine a sandbox platform and an app-environment platform, the split is clean: the sandbox owns the inner loop (fast, untrusted, disposable) and the app environment owns the outer loop (full stack, real data, real URL). Budget a few days of integration to wire creation, log streaming, and teardown into your agent orchestrator, not weeks.

Qovery's honest limits and honest wins: it is not a sub-second sandbox and I would not sell it as one. Where it genuinely wins is full-stack fidelity with real managed databases (Qovery managed databases), BYOC economics and residency, Kubernetes-native including your existing cluster, environment auto-stop, per-environment RBAC (Qovery RBAC), and managed cluster upgrades (Qovery docs). Adoption is short: connect your cloud account or existing Kubernetes cluster, describe your services, enable preview environments on the repository, then let agents open PRs.

Finally, a red-flags list for evaluating any vendor in this space. Walk away if there is no destroy API, no per-environment quota, no idle or per-second billing, no audit log, or container-only isolation offered for untrusted code. Any one of those turns into an incident once agents are creating environments at machine rate.

What are the best platforms for spinning up ephemeral dev environments for coding agents in 2026?

There is no single best platform, because there are two categories. For raw agent code execution (the inner loop), E2B, Daytona, and Modal lead, with Vercel Sandbox and Cloudflare Sandbox as good picks if you already run on those platforms. For full-stack environments per pull request (the outer loop), Qovery and Bunnyshell lead, and Coder and GitHub Codespaces cover human-plus-agent dev workspaces. Most serious pipelines run one from each category.

What is the difference between an AI code sandbox and an ephemeral preview environment?

An AI code sandbox is a single isolated microVM or container that boots in about a second to run untrusted agent code and then disappears, exposed through an SDK (E2B, Daytona, Modal). An ephemeral preview environment is a full multi-service app with real databases, secrets, and a public HTTPS URL, created per branch or pull request and alive for hours to days (Qovery, Bunnyshell). Use the sandbox for the inner loop and the preview environment for end-to-end verification.

How fast can a coding agent get a working dev environment?

In three tiers. MicroVM sandboxes start in about a second or less: E2B advertises sub-200ms same-region startup, Daytona advertises sub-90ms creation, and Firecracker itself boots in under 125ms (Firecracker, NSDI 2020). Container cloud dev workspaces (GitHub Codespaces, Coder) land in seconds with prebuilds and minutes cold, and full multi-service app environments with a managed database (Qovery, Bunnyshell) land in minutes because they build images, provision data, and pass health checks.

How do I stop coding agents from running up my cloud bill with ephemeral environments?

Make cost control structural: use per-second or idle-based billing for sandboxes, and enforce TTL plus automatic auto-stop on inactivity for full environments, because manual cleanup fails within a day of running a fleet of agents. Share one seeded managed database across environments with per-environment schemas instead of a database per environment, and set hard per-repo and per-agent quotas. Running environments in your own cloud (BYOC) keeps your committed-use discounts and Savings Plans applied, which matters when wasted cloud spend already sits at 29% (Flexera 2026).

Is it safe to run agent-generated code in a container, or do I need a microVM?

For genuinely untrusted, agent-generated code, a shared-kernel container is not a sufficient boundary; use microVM (Firecracker) or gVisor-class isolation. That is why sandbox specialists like E2B and Vercel Sandbox run on Firecracker microVMs and Modal is built for untrusted code, since a shared kernel can be escaped by a kernel exploit. Prompt injection and excessive agency are on the OWASP Top 10 for LLM Applications, so the sandbox wall, not the model's good behavior, is the control.

Can coding agents get an ephemeral environment that includes a real database and multiple services?

Yes, that is exactly what a full ephemeral app environment provides, as opposed to a code sandbox. Qovery creates a complete preview environment per pull request inside your own AWS, GCP, Azure, or Scaleway account, or your existing Kubernetes cluster, with databases backed by managed cloud services (Qovery docs), and Bunnyshell offers per-PR full stacks on Kubernetes. This is what an agent needs to verify a schema migration, an auth change, or a third-party integration end to end before merge.