Cloud development environments for coding agents: 9 platforms compared
Published September 5, 2026
Summary
Running coding agents on developer laptops stops working once a team wants several running at once. This guide compares the cloud environments agents can run in instead, from self-hosted dev environments to microVM sandboxes to workspaces that bundle the agent, and explains which one fits a growing engineering team.
The problem
Why teams stop running coding agents locally
The first agent on a laptop is fine. The trouble starts when an engineer wants three running while they do something else, when a second engineer needs the same environment, or when security asks what the agent could reach with the developer's SSH keys and cloud credentials. Local execution ties every agent run to a person, a machine, and that person's permissions.
Moving the agent into a cloud environment fixes those problems in one move, but the market splits into products that solve quite different parts of it. The choice is less about which vendor is best and more about which layer you want to own.
- Isolation: an agent that runs arbitrary generated code should not share a machine with a developer's credentials or with another agent's work.
- Parallelism: the value of delegation is running many tasks at once, which a single laptop cannot do without Git worktrees and a lot of RAM.
- Reproducibility: every task should start from the same dependencies, tools, and secrets, defined once rather than per machine.
- Attribution: teams need to know which tasks ran, who started them, what they cost, and what shipped, which local runs never record.
The landscape
Three kinds of cloud environment for coding agents
Most comparisons of this category mix products that were built for people with products that were built for programs. It helps to separate them first.
- Cloud development environments built for people
- Coder, GitHub Codespaces, and DevPod give a developer a persistent or disposable machine in the cloud with an IDE attached. Agents can run inside them, and Coder in particular has added agent-specific governance, but you start and supervise the agent yourself.
- Agent sandboxes built for programs
- E2B, Daytona, and Northflank provide a microVM in well under a second through an SDK. They are infrastructure for teams building agent products: your code decides what runs inside and what happens to the result.
- Agent workspaces that bundle the environment, the agent, and the trigger
- Replicas and Ona provision an isolated environment per task, run a coding agent inside it, and connect the loop to the tools where work already lives. This is the tier for an engineering team that wants to delegate backlog items rather than build an agent platform.
Nine platforms
Cloud dev environments for coding agents, compared
The table gives the shape of each platform. The entries below explain where each one fits and what you take on by choosing it. Startup times, deployment options, and pricing in this category change often; confirm them with each vendor before committing.
| Platform | Category | Isolation | How agents get in | Best for |
|---|---|---|---|---|
| Replicas | Agent workspace | Dedicated Linux VM per task, destroyed when the work is done | Slack, Linear, GitHub, GitLab, dashboard, schedules, webhooks, API | Teams that want to delegate work to Claude Code, Codex, Cursor, or OpenCode without running the machines |
| Coder | Cloud dev environment | Containers or VMs on your infrastructure, one ephemeral workspace per agent | Coder Tasks UI, CLI, and API; bring any agent | Platform teams that must keep source, credentials, and agents inside their own network |
| GitHub Codespaces | Cloud dev environment | GitHub-managed VM per codespace, 2 to 32 cores | Browser or local VS Code; agents run as processes you start | GitHub-native teams that want disposable environments for humans first |
| Ona | Agent workspace | Managed cloud environments; runs in your VPC with kernel-level policy enforcement | Ona agent, automations on PRs, schedules, and webhooks | Enterprises that used Gitpod and want an agent-first successor in their own VPC |
| E2B | Agent sandbox | Firecracker microVM per sandbox | Python and JavaScript SDKs; you supply the agent and the orchestration | Teams building their own agent product that needs to execute untrusted code |
| Daytona | Agent sandbox | Isolated sandboxes on dedicated compute, no cross-tenant sharing | SDKs for Python, TypeScript, Ruby, Go, and Java | High-volume agent execution where startup latency dominates |
| Northflank | Agent sandbox | MicroVM sandboxes alongside your services, databases, and GPU jobs | API and platform UI; sandboxes live next to the rest of your stack | Teams that want sandboxes and their application runtime on one control plane |
| Qovery | Ephemeral app environment | Full multi-service stack per pull request with real databases and URLs | Git and CI driven; agents use the environment to verify, not to run | Verifying agent output against a production-like stack before merge |
| DevPod | Cloud dev environment | Whatever the backend provides: a cloud VM, a Kubernetes pod, or a local container | CLI and desktop app; agents run as processes inside the workspace | Teams that want devcontainer environments with zero vendor and zero server |
Replicas: best when the agent, the environment, and the trigger should come as one thing
Replicas is the layer above a sandbox. Each task gets its own Linux VM booted from an environment your team configured once: dependencies and images preinstalled through warm hooks, environment variables and files, MCP servers, skills, and secrets synced from Doppler or Infisical. The agent inside is the harness your engineers already use, and it can drive a real desktop and browser to check its own work.
The difference from a raw sandbox is that nobody on your team writes the orchestration. Work starts from a Slack message, a Linear issue, a GitHub or GitLab comment, a schedule, or one API call, and comes back as a pull request, a reply, or a recording. Analytics attribute every minute to a source, a person, a harness, a model, and the credential that paid for it.
Replicas runs in its own cloud by default, with dedicated single-tenant and fully self-hosted deployments, SCIM, audit logs, static egress IPs, and configurable retention on the enterprise tier. Pricing is per seat with a 14-day trial and no credit card. If your platform team wants to own the Kubernetes cluster the environments run on, look at Coder instead.
Coder: best self-hosted option
Coder provisions workspaces from Terraform templates onto your own Kubernetes clusters or VMs, in any cloud or fully air-gapped. It is agent-agnostic: Claude Code, Codex, or an open-source agent runs inside an ephemeral workspace with the same template a human developer would get, and Coder adds an agent firewall for permissions, audit logs of agent chats and tool calls, and role-based access control.
The trade-off is that you operate it. Coder is the right answer when "our infrastructure, our policies" is a requirement rather than a preference, and when a platform team already exists to run it. The open-source core is free; governance features sit in the premium tier.
GitHub Codespaces: easiest adoption if you already live in GitHub
Codespaces turns a devcontainer.json in your repository into a reproducible cloud machine that opens in the browser or in local VS Code. Organizations pay as they go with spending controls, and individuals get a free monthly allowance. For a team already standardized on GitHub it is the lowest-friction way to stop running dependencies on laptops.
It was designed for people. You can run Claude Code or Codex inside a codespace, but you start it, watch it, and shut the machine down yourself; there is no ticket-to-PR loop and no fleet view. GitHub's own Copilot coding agent runs on Actions runners rather than in Codespaces, which tells you where GitHub draws the line between the two products.
Ona: best Gitpod lineage for agent fleets
Ona is what Gitpod became. The environments are still the product, but the pitch is now "task in, pull request out": background agents run end to end in connected cloud environments, automations fire on pull requests, schedules, or webhooks, and the whole thing can run inside your VPC with scoped credentials and audit trails. Ona works with its own agent and with Codex and other agents.
It is the closest thing on this list to Replicas in shape, aimed further up-market at large enterprises with CVE remediation and code-migration programs. Teams choosing between the two are usually deciding whether they want harness choice and per-seat pricing or a single enterprise agent platform with a sales process.
E2B: best open-source sandbox primitive
E2B gives an agent a fresh Firecracker microVM in under 200 milliseconds through a Python or JavaScript SDK, keeps it alive for up to 24 hours, and lets you run it on E2B's cloud, your own AWS, GCP, or Azure account, or on-premises. The runtime is open source, and it is the sandbox most agent frameworks reach for when they need somewhere safe to run generated code.
It is a primitive, not a workflow. E2B does not know what a pull request is; your code clones the repository, installs dependencies, launches the agent, and decides what to do with the result. That is exactly right when you are building an agent product, and the wrong amount of work when you want your engineering team to delegate backlog items.
Daytona: best for very fast, very many sandboxes
Daytona is built for running AI-generated code at volume: sandbox creation in under 90 milliseconds, consumption pricing per vCPU, memory, and storage, and a customer-managed compute option that keeps the sandboxes in your cloud while Daytona runs the control plane. SDKs cover five languages.
Like E2B, it is infrastructure for a product team rather than a tool for an engineering team. Evaluate it when you are building something that spins up thousands of short-lived environments, not when you want to hand a Linear issue to Codex.
Northflank: best when the sandbox should sit next to production services
Northflank is a runtime platform that added microVM sandboxes to the same control plane that runs your services, databases, jobs, and GPU workloads, on its cloud or yours. That matters when an agent needs to hit a real database or internal API rather than a mocked one, and you would rather not stitch a sandbox vendor to a hosting vendor.
It is the broadest platform here and correspondingly the least specialized for coding agents. If your team already runs on Northflank, the sandboxes are an easy add. If not, it is a platform migration, not an agent decision.
Qovery: best for the outer loop
Qovery, and Bunnyshell in the same category, provision a complete copy of your application per pull request inside your own AWS, GCP, Azure, or Scaleway account: every service, a seeded database, and a URL to click. Startup is measured in minutes because there is real infrastructure behind it.
These are not where the agent runs; they are where you find out whether what the agent did actually works. Mature setups pair a fast environment for the agent's inner loop with a full ephemeral environment for end-to-end verification, and Qovery is the second half of that pair.
DevPod: best lock-in-free option
DevPod, from vCluster Labs, is an open-source, client-only tool that turns a devcontainer.json into a workspace on any provider: AWS, GCP, Azure, Kubernetes, or your laptop. There is no server to run and nothing to pay for, which is why teams that left Codespaces over cost or Gitpod over its pivot end up here.
Everything above the environment is yours to build. Running an agent means starting it in the workspace; running many agents means scripting DevPod yourself. It is a fine base for a platform team and a lot of glue for anyone else.
Shortlist by need
Which environment fits your team
Growing teams usually end up with two of these, one for the agent's inner loop and one for verification. The question to settle first is who owns the layer between the sandbox and the pull request.
- You want engineers to delegate work from Slack or Linear this month
- Replicas. The environment, the harness, the triggers, and the review loop are already wired; your team configures an environment once and starts assigning tasks.
- Your platform team must own the infrastructure
- Coder if you want a proven self-hosted product with agent governance. DevPod if you want open source with no server at all and are willing to script the rest.
- You are building an agent product, not adopting one
- E2B or Daytona. Pick on SDK language, startup latency, and whether you need bring-your-own-cloud. Northflank if the sandboxes should live next to the rest of your stack.
- You already live in GitHub and mostly want humans off laptops
- GitHub Codespaces for people, and GitHub Copilot's coding agent for issue-to-PR work on Actions. Add a workspace platform when you want harness choice or GitLab.
- You need to verify agent output against a real stack
- Qovery or Bunnyshell for a per-pull-request copy of production, alongside whichever environment the agent itself runs in.
Evaluation
Questions to ask before you choose
Run the same two or three backlog tasks through each finalist with the same repository and the same reviewer. While you do, get concrete answers to these.
- What is the isolation boundary: a microVM or VM per task, a container, or a shared machine with worktrees?
- Who starts the agent and who cleans up: a person, your own orchestration code, or the platform?
- Can work start from where it is already tracked, such as Linear, GitHub, GitLab, or Slack, or only from a UI or SDK?
- Which agents can run inside, and can you switch between Claude Code, Codex, Cursor, and open-source harnesses without changing platforms?
- Where do credentials live, how are they scoped per task, and can egress be pinned to a static IP for your internal services?
- Can you see, per task and per engineer, what ran, how long it took, what it cost, and whether it merged?
FAQ
Cloud environment questions
Getting started with Replicas
Give every agent its own machine without running any
Replicas includes a 14-day free trial with no credit card required. Connect a repository, define the environment once, pick Claude Code, Codex, Cursor, or OpenCode, and delegate a task from the dashboard, Slack, Linear, GitHub, or GitLab. Each task boots its own Linux VM and comes back as a pull request your team reviews together.
For dedicated or self-hosted deployment, SCIM, audit logs, static egress IPs, and security review, contact the enterprise team.