How Do You Give Coding Agents Their Own Ephemeral Dev Environments? 9 Platforms Compared

Key Points:

• You give a coding agent an ephemeral dev environment in one of two ways. A micro-VM code sandbox created over an API (E2B, Daytona, Modal, Runloop, Cloudflare Sandboxes, Vercel Sandbox) boots in well under a second for the agent's inner loop. A preview environment per pull request (Qovery, Northflank, Vercel Preview Deployments) deploys your real services, databases and ingress in minutes for the human review loop.
• The decision rule is one question: does the agent need to execute code, or does a human need to open a URL and click on a running app? Execute code means a code sandbox. Review a running app means a full application environment. At pull-request scale you end up needing both, and they are complements, not substitutes.
• For the inner loop: E2B and Daytona are the sandbox runtimes with open-source roots, Modal is the pick when the workload needs GPUs, Runloop is built for agent evaluation on SWE-bench-style tasks, and Cloudflare Sandboxes or Vercel Sandbox make sense if you already run there.
• For the outer loop inside your own cloud account, that is where Qovery fits: it creates a preview environment per pull request on your AWS, GCP, Azure, Scaleway or existing Kubernetes cluster, with environment auto-stop, per-environment RBAC and databases backed by managed cloud services. Qovery is not a sub-second code sandbox and does not try to be.
• Cost is driven by environment-hours left running, not the per-second compute price. Agents open far more branches than humans do, so platform-enforced TTL, teardown on merge and auto-stop on idle are the three features that decide your bill.

---

How do you give coding agents their own ephemeral dev environments?

You give a coding agent an ephemeral dev environment in one of two ways, and most teams running agents at scale need both: a micro-VM code sandbox created over an API or an MCP tool call for the agent's inner loop (write, run, test), and a preview environment per pull request for the outer loop (open PR, run end-to-end tests, human review). The first is measured in milliseconds and has no shareable URL. The second is measured in minutes and gives you a real app on a real database at a real HTTPS address.

This stopped being a hypothetical. Frontier coding models now resolve north of 80% of SWE-bench Verified tasks, with Claude Opus 4.6 reporting 81.42% (Anthropic), and 90% of software professionals say they now use AI in their work (DORA 2025). Agents write mergeable code. The bottleneck moved from writing the code to having somewhere real to run it and review it.

Here is the shortlist, one line each:

• E2B - open-source Firecracker micro-VM sandboxes over an SDK. Best for running untrusted, LLM-generated code.
• Daytona - a sandbox runtime for AI-generated code with sub-90ms creation. Best when you want a self-hostable runtime (with a caveat below).
• Modal - serverless CPU and GPU compute with a Sandbox API. Best when the agent workload needs GPUs or heavy compute.
• Runloop - devboxes built for coding-agent evaluation and benchmarking. Best for running agents against SWE-bench-style suites.
• Cloudflare Sandboxes / Containers - containers driven from Workers. Best if you already run on Cloudflare.
• Vercel Sandbox + Preview Deployments - a micro-VM sandbox plus a per-branch preview. Best for frontend and Next.js agent output.
• Northflank - containers plus preview environments, in their cloud or yours (BYOC). Best for a container platform that does both loops.
• Docker / Dev Containers - the free local and CI baseline. Best when a single container is genuinely enough.
• Qovery - a preview environment per pull request inside your own cloud account. Best when the environment must live in your AWS, GCP, Azure, Scaleway or existing Kubernetes cluster.

The mechanics come down to three steps:

1. The agent calls a sandbox API or MCP tool and gets an isolated runtime with a filesystem and a shell to run the code it just wrote.
2. The agent pushes a branch, and the platform builds a preview environment from a manifest, with its own database and an HTTPS URL a human can open.
3. TTL and auto-stop reclaim both without a human in the loop.

Most comparison articles stop at step one. That is the trap. Agent output eventually has to be reviewed by a human and a CI pipeline against a running system, and a code sandbox gives you no shareable URL, no database and no ingress. The two layers solve different problems.

One note on timing: this category barely existed before 2024. Vendor specs move month to month, so every number below is dated to what the vendor published as of September 2026, hyperlinked to the page, and marked "not published" where the vendor does not state a figure. Do not trust a cold-start number you cannot click.

What is the difference between an agent code sandbox and an ephemeral application environment?

A code sandbox is a single isolated micro-VM or container created over an API to run untrusted code for seconds to minutes with no shareable URL. An ephemeral application environment is your whole application - services, workers, managed databases, queues, secrets and ingress - deployed per branch with an HTTPS URL that lives for hours to days.

A code sandbox has these properties:

• Micro-VM or container isolation (Firecracker, gVisor, OCI containers).
• Lifetime of seconds to minutes.
• One process or one shell, not a running distributed app.
• No team-shareable ingress you hand to a reviewer.
• Isolating untrusted code is the primary job.
• Billed per second of CPU and RAM.

An ephemeral application environment has these properties:

• Multiple services running together.
• Real managed databases, secrets and ingress.
• A shareable HTTPS URL.
• Teardown on merge.
• Cost measured in environment-hours, not CPU-seconds.

The mapping to the two agent loops is exact. The inner loop - write, execute, test, iterate - is a sandbox job. The outer loop - open PR, run e2e tests, human review, stakeholder demo - is an application environment job.

Isolation is where the difference gets expensive if you get it wrong. Running model-written code in your CI runner's shell hands that code your CI credentials and your network position. That is a materially different risk from a Firecracker micro-VM with egress locked down. Firecracker boots a guest in under 125ms, creates up to 150 micro-VMs per second per host, and adds under 5 MiB of memory overhead per VM (Firecracker), which is exactly why the fast sandbox vendors are built on it. gVisor takes a different route, running a user-space kernel written in Go that intercepts system calls, trading some performance for a smaller attack surface without a full VM.

The interface layer most sandbox vendors now ship is MCP, the Model Context Protocol, so an agent can request an environment as a tool call instead of bespoke glue code.

Two vendors appear in both categories on purpose. Vercel and Northflank each ship a sandbox and a preview-environment product, so they show up twice in the comparison below. And one adjacent category is worth naming so this piece is complete: Gitpod and Coder build cloud dev environments for humans, not agent APIs. They are excellent at giving a person a ready-to-code workspace. They are not the API-first, ephemeral, per-call runtime an agent's inner loop wants, so they sit outside the nine-platform comparison.

How do the top 9 ephemeral environment platforms compare on cold start, isolation, cost and where they run?

Sandbox platforms start in well under a second because they boot a micro-VM with nothing attached, while full application environments take minutes because they build images and provision databases and ingress. Only Qovery, Northflank BYOC, Daytona self-hosted and Docker run inside infrastructure you control. Everything else runs in the vendor's cloud.

Every figure below is vendor-published and linked. Where a vendor does not publish a number, the cell says "not published" rather than an estimate.

How to read this table: if the answer to "does this environment need my real database and my real ingress?" is yes, the cold-start column is irrelevant. In that case the "runs in your cloud" column is the only one that matters, and the field narrows to Qovery, Northflank BYOC, and Docker.

Open source is a real selection criterion, not a checkbox. E2B is Apache-2.0, Docker Compose is Apache-2.0, and the Dev Containers spec is CC BY 4.0 - all three let you self-host the runtime or cap your exit cost. Daytona is the cautionary tale here: it was AGPL-3.0 through v0.190.0, but as of June 2026 core development moved to a private codebase and the public repo is unmaintained (GitHub). If "we can self-host it" is load-bearing for you, read the license file on the branch you would actually run, not the badge.

And where Qovery loses, plainly: Qovery is not a sub-second code sandbox. It is not the tool for one-off untrusted snippets, and it provisions in minutes because it stands up real infrastructure - services, a managed database, ingress. If your only need is running a throwaway script an agent wrote, a sandbox is the right tool and Qovery is the wrong one.

The second question a security reviewer asks is the isolation unit. Here it is per platform:

Egress defaults change and are often configurable, so confirm the exact policy in each vendor's networking docs before you trust it. The pattern that holds: the hosted sandboxes let outbound traffic through by default so agents can install dependencies, while the two Kubernetes-based application platforms (Northflank, Qovery) inherit whatever network policy your cluster enforces.

Which ephemeral environment platform should you pick for your specific agent use case?

Pick by what the agent actually does, not by which vendor markets hardest. Six use cases, one primary recommendation and one alternative each:

For a single container, a small team and a tight budget, Docker Compose in CI or a Dev Container is often enough, and I will say that plainly. Do not buy a platform to solve a problem docker compose up already solves.

The anti-pattern that costs the most is the opposite of ephemeral: one giant always-on shared "agent staging" environment. It produces flaky tests from cross-agent interference, it hides which change broke what, and it runs up a bill nobody is watching. Per-agent or per-PR isolation is the entire point.

Is it safe to let an AI coding agent run code in your cloud account?

Yes, under three conditions. The code runs in an isolated micro-VM or a dedicated per-environment Kubernetes namespace rather than your CI runner's shell, the environment holds no production credentials and no production data, and access is scoped by per-environment RBAC with a platform-enforced TTL. Get those three right and running agent code in your own cloud account is a normal, auditable operation.

The failure modes are concrete:

• Agent-generated code with unrestricted egress reaching internal services it should never see.
• Secrets inherited from the CI runner, so a hallucinated command exfiltrates your registry token.
• Long-lived environments quietly accumulating real customer data.
• Prompt-injected or hallucinated dependencies pulling in malicious packages.

Rank the isolation from strongest to weakest in one line: Firecracker micro-VM > gVisor > a dedicated container with egress denied > your shared CI runner shell (do not do this).

The risk is measured, not theoretical. Veracode tested code from more than 100 models and found 45% of AI-generated samples introduced an OWASP Top 10 vulnerability (Veracode). GitGuardian counted 23.77 million new secrets leaked in public GitHub commits in a single year (GitGuardian). And a Stanford study found developers with an AI assistant wrote less secure code while believing it was more secure (Perry et al.). Two distinct signals - insecure code and leaked secrets - point at the same conclusion: assume agent output is hostile until isolated.

On the two attack classes the outline flags: prompt injection is ranked LLM01, the number-one risk in the OWASP Top 10 for LLM Applications, and package hallucination is real and measurable. A USENIX Security 2025 study found hallucinated package names in 5.2% of commercial-model outputs and 21.7% of open-model outputs, cataloguing 205,474 unique fake names attackers can pre-register (Spracklen et al.). That is the mechanism behind slopsquatting.

The data question decides your architecture. Seed ephemeral environments with anonymised or synthetic fixtures, not a snapshot of production, because a snapshot drags GDPR, SOC 2 and HIPAA obligations into a place agents can touch. This is exactly why BYOC matters here: if agent-written code can reach customer data, keeping the environment inside your own AWS, GCP, Azure, Scaleway or Kubernetes account keeps it under your existing VPC, IAM, audit logging and data-residency controls instead of a vendor's. You cannot outsource a data-residency guarantee to someone else's sandbox.

A six-item checklist a security reviewer can copy:

1. Isolation unit - micro-VM, dedicated container with egress denied, or (never) the CI runner shell.
2. Egress policy - default-deny with an allowlist, or wide open.
3. Credential scope - environment-scoped short-lived tokens, or inherited CI secrets.
4. Data class - synthetic fixtures, or a production snapshot.
5. TTL enforcement - platform-enforced, or a cron job someone will forget.
6. Audit trail - who created what, when, and what it could reach.

How much do ephemeral environments for coding agents cost, and how do you keep the bill down?

The cost driver is environment-hours left running, not the per-second compute price. Agents create far more environments than humans ever did, and almost none of them get torn down by hand. So the bill is set by how long idle environments live, not by how cheap a single run is.

Sandbox pricing is genuinely cheap per run. E2B bills per second at $0.000014 per vCPU-second and $0.0000045 per GiB-second (E2B pricing); Modal bills $0.0000131 per CPU-core-second (Modal pricing); Cloudflare bills $0.000020 per vCPU-second (Cloudflare pricing). The risk is volume. Thousands of agent runs a day at a few cents each is a real line item that grows quietly because no single run looks expensive.

Application-environment cost is dominated by idle time. A managed database, a load balancer and node capacity that nobody touches at 3am, running all weekend on a branch that already merged. To make that concrete with list prices you can click: an AWS RDS db.t4g.medium PostgreSQL instance runs about $0.065/hr (AWS RDS pricing) and an Application Load Balancer runs $0.0225/hr (AWS ELB pricing) before data processing. One forgotten preview environment with a database and an ALB is roughly $0.09/hr, or about $64 a month, each. Multiply by the number of branches an agent fleet leaves open and the picture is obvious.

This is not a niche worry. Flexera's 2026 survey puts wasted cloud spend at 29% and names cost optimization the top cloud initiative for 68% of organisations (Flexera). Idle ephemeral environments are that waste in miniature.

Five levers actually move the number:

• Platform-enforced TTL on every environment.
• Auto-stop on idle, so nothing runs overnight untouched.
• Teardown on PR merge, automatic, not a reminder.
• Right-sized CPU and memory per environment.
• Shared vs dedicated databases, plus spot or preemptible nodes for non-production.

BYOC economics, honestly stated: running in your own cloud account means the compute counts toward your existing committed spend, Savings Plans and negotiated discounts instead of a vendor markup, and the bill stays in your name. The trade-off is that you own the cluster and its upgrades. That is a real cost, not a footnote, and it is the right trade only past a certain volume.

How does Qovery fit in, and when is it the right answer for agent environments?

Qovery is not a millisecond code sandbox. It creates full, production-shaped ephemeral environments inside your own cloud account, which is exactly what an agent-authored pull request needs before a human approves it. When the agent has finished its inner loop and pushed a branch, Qovery is the outer loop: real services, a real managed database, real ingress, on a URL a reviewer can open.

The capabilities that matter here, each documented:

• Git-push deployments and a preview environment per pull request, created automatically for every PR targeting your base branch (Qovery docs).
• Environment auto-stop and scheduled shutdown for non-production (deployment rules).
• Per-environment RBAC across roles and environment types (Members & RBAC).
• Managed Kubernetes cluster upgrades, tested and rolled out by Qovery (Clusters).
• Databases backed by managed cloud services, for example an RDS instance on AWS (Databases).

Where it runs is the whole point: your own AWS, GCP, Azure or Scaleway account, or your existing Kubernetes cluster - self-managed, on-prem, any distribution (Qovery docs). The cloud bill, the discounts and the data residency stay in your name.

Why this matters at agent volume: PR count climbs sharply once agents are opening PRs. Per-PR environments then have to be created automatically, scoped by RBAC and auto-stopped, or your platform team turns into a ticket queue that cannot keep up.

The recommendation I actually give, stated plainly: use E2B, Daytona or Modal for the agent's inner loop, and Qovery for the outer loop. They are complements, not substitutes. Qovery does not replace a sandbox runtime, and a sandbox runtime does not give you a reviewable, database-backed environment in your own VPC.

What should you check before committing to an ephemeral environment platform?

Run this six-question checklist in an afternoon. These are the questions that kill a platform choice in month three, not the ones printed on the pricing page.

• Isolation: is agent-generated code running in a micro-VM, a dedicated container with egress denied, or your CI runner's shell?
• Data: can the environment reach real customer data, and is that allowed under your compliance regime?
• Teardown: is TTL and auto-stop enforced by the platform, or by a cron job someone on your team wrote and will forget?
• Parity: does the ephemeral environment actually resemble production - databases, queues, ingress, secrets - or only the happy path?
• Concurrency: what are the published quotas at agent-scale volumes (hundreds of concurrent environments), and what happens when you hit them?
• Exit cost: open-source runtime, standard OCI containers and standard Kubernetes, or proprietary lock-in you cannot lift out?