The cloud dev environment: a practical guide for 2026

The cloud dev environment was a 2020 idea that peaked around 2023, plateaued, and is now in the middle of an unexpected second wave. The reason isn't that browser-based IDEs got better — they're roughly where they were. It's that the AI agents everyone is building need somewhere to live, and the somewhere looks a lot like a CDE.

This piece is the practical 2026 view of the category. What a cloud development environment actually is, the four shapes it comes in this year, what changed, and how to pick.

A short history before the present

The CDE category has three rough eras.

Era one: the browser editor (2020–2022). GitHub Codespaces, Gitpod, Replit. Open a repo in a browser tab, get a containerised dev environment with VS Code attached. The pitch was the right environment, instantly. It fit new contributors to open-source projects and organisations standardising tooling. It struggled for anyone whose workflow needed real disk persistence, GPUs, weird tooling, or low latency.

Era two: the self-hosted plateau (2022–2024). Gitpod and Coder went hard on self-host. The category narrowed: most CDEs were either hosted SaaS we don't have to operate or self-host running on our k8s. Adoption was real but flat. The teams who needed it adopted; the teams who didn't kept their laptops.

Era three: agents arrive (2024–now). Suddenly somewhere code can run that isn't my laptop matters in a different way. The agent needs a real Linux machine. It needs to run for hours. It needs to fork. It needs to keep state. The CDE primitive turns out to be most of what an agent execution environment is — and the platforms that bend toward agent workloads are pulling ahead of the ones still optimising for the human-in-the-IDE story.

What "cloud development environment" means in 2026

The term is messier than it should be. Cloud dev environment, cloud development environment, remote development, CDE, browser dev environment — they're used interchangeably and they mean different things. The minimal shared definition: a development environment whose compute runs somewhere other than your laptop.

Inside that, four shapes:

Shape 1: SaaS browser-based

GitHub Codespaces is the canonical example. You open a repo, a container spins up in GitHub's cloud, VS Code in the browser attaches to it. Everything's hosted. Everything's tied to the editor experience.

Where this fits: new-contributor onboarding, standardising tooling across an org, anyone who wants the lowest possible setup cost.

Where this struggles: workloads that need persistent state, real disk, low latency to local services, or anything that runs longer than a coding session.

Shape 2: Self-hostable container-based

Gitpod, Coder. You run the platform on your k8s. Engineers get container-based workspaces from your golden image. SSO, audit logs, network policies — all yours.

Where this fits: medium-to-large engineering orgs that want CDE benefits with self-host control. Compliance teams who need everything in the VPC.

Where this struggles: small teams without k8s ops capacity. Workloads where containers are the wrong primitive (anything that wants kernel access, weird device files, or persistent process trees).

Shape 3: CDE platforms repositioning around AI

The interesting recent move is in this column. Ona (the post-pivot Gitpod, now built around an Elixir control plane rather than k8s) is the clearest example of a CDE platform restructuring for the agent era. Coder has shipped agent-focused features on top of its existing self-host story. Daytona has gone the other direction — explicitly leaving the dev-environment category in early 2025 to position as an agent-sandbox product — and Fly.io's Sprites was never a CDE in the first place; it's a persistent-microVM platform for code execution. Mentioning all four together makes the point: the line between dev environment and agent runtime is dissolving fast.

Where this fits: teams choosing a platform now and wanting to bet on one that's building toward both shapes at once.

Where this struggles: teams who want a clean, settled product story. The repositioning is real, and the docs aren't always caught up to where the product is.

Shape 4: SSH-native persistent VM

boxd. Real VMs (KVM, not containers), persistent by default, forkable in milliseconds, accessed primarily over SSH. The editor is whatever the developer prefers — Cursor, Zed, Claude Code, vim. The agent reaches the same machine the same way.

Where this fits: teams whose workloads are a mix of human coding and agent execution. Teams that want one substrate for both. Teams who outgrew browser editors but don't want to maintain k8s.

Where this struggles: teams whose dev environment story is VS Code in a browser tab and nothing else.

The four shapes overlap at the edges. The thing that distinguishes them is what they optimise for: the editor experience (1, 2), the workspace continuity (3), or the substrate that holds both human and agent work (4).

What changed: agents joined the workload

For five years, the CDE category was about giving humans a better dev environment. In 2026 the workload is split. Some of the time the developer is in the workspace; some of the time an agent is. The platform either supports both or it picks one.

That shift turns out to be load-bearing. Five workspace properties that used to be nice-to-have are now requirements:

1. Persistent state across sessions. The agent does not stop at the end of the workday. The workspace can't either.
2. Sub-second resume from sleep. The agent will be back in two hours. The workspace should be ready for it without being billed for those two hours.
3. Fast fork from running state. Branch the workspace to run an experiment in parallel. Not a 30-second container build — a 60ms snapshot.
4. Stable network identity. The agent makes outbound webhooks, the agent runs an MCP server, the workspace integrates with services that need to call back. The address has to be stable.
5. SSH-friendly by default. The agent talks SSH. The human can talk whatever they want — IDE, browser, terminal. SSH is the lowest-common-denominator surface that doesn't lock either party in.

The container-on-k8s shape can satisfy most of these with effort. Browser-only editors can't. The shape that fits all five out of the box is the persistent VM — which is roughly what's pulling the category in that direction.

What we built

boxd is a CDE that was shaped for the 2026 workload from the start. The architectural bet underneath: the agent lives inside the machine.

• Persistent VMs. Every workspace is a real KVM virtual machine. State, files, env, processes — they survive between sessions.
• 60ms fork. Copy-on-write fork captures memory, disk, and in-flight processes. Spawn a workspace from any state in under a tenth of a second.
• Sub-millisecond resume from sleep. Idle workspaces hibernate; cost goes to near-zero. The next SSH connection wakes them in a millisecond.
• Per-VM public IPv4, real DNS, real TLS. Every workspace is reachable. Webhooks land. MCP servers work. The agent's tool calls have somewhere to come back to.
• SSH-first interface. Your editor is your choice. Cursor over SSH. Claude Code in a tmux session. Zed remote. vim. The substrate doesn't care.
• Self-hostable. One Rust binary on KVM. Run it in your VPC, your bare metal, your country.

A working CDE on boxd looks like this:

ssh dev.alice.boxd.sh           # alice's persistent workspace
ssh fork dev.alice.boxd.sh ↦ dev.alice-feature.boxd.sh   # branched in 60ms for an experiment
ssh agent.dev.alice.boxd.sh "claude code --resume"        # the agent uses the same substrate

Same machine for the human, the agent, and any branched experiment. Same SSH key as identity. Same address as long as you want it.

Picking by team shape

Indie developer. The free Codespaces tier or a small persistent VM both work. Pick on whether you need persistence between sessions and whether the agent in your loop needs continuity.

Small team building with agents. Persistent-VM platforms (Sprites, boxd) fit the workload better than browser editors. One workspace per developer, plus one or two for the agents themselves. Costs stay manageable because idle workspaces don't bill.

Engineering org with mixed workloads. Self-hostable matters here, both for cost control at scale and for compliance. Coder, Gitpod self-host, and self-hosted boxd all fit; pick on whether your ops team prefers k8s (Coder, Gitpod) or single-binary (boxd).

Regulated team or EU-data-bound org. Self-host in your jurisdiction. Single-binary platforms are a smaller operational surface than k8s-based ones, which usually matters more than the platform choice itself. See self-hosted agent execution for engineering teams for the EU sovereignty angle.

What's next for the category

The CDE category is consolidating around persistence and agent-friendliness. The platforms that ship sub-second resume, fork-from-state, and a substrate that fits both human and agent work will keep growing. The platforms still optimising for VS Code in a browser tab will stay useful for the onboarding-and-standardisation use case and stop being interesting outside it.

The honest summary: a CDE in 2026 is not just a dev environment in the cloud. It's the substrate that holds your engineers' work and your agents' work side by side. Pick one shaped for that.

That's what boxd is for. SSH in. It's yours. The agent can use it too. If you're shopping persistent-VM substrates, see boxd vs sprites.dev and boxd vs exe.dev.

Last verified: 2026-05-04. This article is informational, not legal advice. Send corrections to hello@boxd.sh.