Glossary
Cloud development environment
The compute, filesystem and toolchain live somewhere else, and are usually thrown away afterwards.
Definition
A cloud development environment (CDE) is a software development environment (compute, filesystem, dependencies and toolchain) hosted on remote infrastructure and accessed over the network from a browser or a local editor. Environments are typically defined as configuration in the repository and created on demand, so every developer gets an identical setup and can discard it when the branch is done.
- Abbreviation
- CDE
- Examples
- Codespaces, Gitpod, Coder
- Defining property
- Reproducible from config
- Typical lifetime
- Minutes to days
Where the idea came from
Remote development is older than the term. Developers have compiled on shared servers since timesharing, and browser IDEs such as Cloud9 shipped around 2010. What made CDE a named category was the combination of three things arriving together: container images that pin a toolchain, environment definitions checked into the repository, and per-branch provisioning fast enough that developers stopped maintaining a laptop setup.
GitHub Codespaces, Gitpod, Coder and Daytona are the products most often named in the category. The problem they exist to kill is the one every team recognises: an environment that works on one machine and not another, and the day of onboarding that goes into fixing it.
What distinguishes a CDE from a remote server
Defined as code
The environment comes from a file in the repository, whether a devcontainer definition, a Dockerfile or a Nix expression, so it is reproducible rather than hand-built.
Ephemeral by default
Environments are created for a branch or a task and destroyed afterwards. State that matters lives in version control, not on the box.
Attached to an editor, not a terminal alone
A browser IDE or a local editor connected over the network, with language servers, debuggers and port forwarding working as they would locally.
Provisioned on demand
Start time measured in seconds to a couple of minutes, because a developer waiting five minutes will go back to their laptop.
Commonly confused with
| Term | What it means | The difference |
|---|---|---|
| Virtual desktop (VDI) | A remote Windows or Linux desktop session | A whole desktop for general work, persistent, not defined by a repo. |
| Remote SSH box | A long-lived server you configure by hand | Not reproducible and not disposable. The classic thing a CDE replaces. |
| Agent runtime | Infrastructure that executes an AI agent's job | No human editor attached. The consumer of the environment is a program, not a person. |
| CI runner | Ephemeral compute that executes a pipeline | Runs a defined script to completion. Nobody is developing inside it. |
The overlap with AI agents
The CDE category and the agent-runtime category are converging, because an AI agent needs roughly what a developer needs: a filesystem, a toolchain, network access and credentials, created on demand and thrown away after. The difference that still matters is the interface. A CDE assumes a person is typing in it; an agent runtime assumes nobody is watching and therefore has to record what happened.
Polaris runs a worker runtime on Fly.io that wakes a machine per task. It is not a CDE and is not sold as one. There is no editor to attach to, and the output is a delivered task comment rather than a branch you inspect by hand.
Related terms
Agent runtime
Not the model, not the framework: the thing that actually runs the job.
Headless agent
Nobody is typing at it, so its output is actions and artefacts rather than replies.
Task queue
The thing that lets a request survive the process that made it.
Running an AI agent in the cloud instead of on your laptop
Three approaches, one of which is ours, described precisely enough that you can tell which one you actually want.
Cloud agents versus local agents
Most teams end up running both. The useful question is which work belongs where.
Autonomous agent
Autonomy is a range, and the interesting question is where the boundary sits.
Questions people ask
+Is a cloud development environment the same as running Claude Code in the cloud?
No. A CDE gives a human developer a remote machine to work in. Running an agent in the cloud gives a program a machine to work in, with no editor session and no person present. The infrastructure looks similar; the interface, the audit requirements and the failure modes are different.
+Do CDEs cost more than local development?
They move the cost from hardware to metered compute, which usually shows up as a per-hour or per-seat line item. Teams that adopt them tend to justify it on onboarding time and environment-drift incidents rather than on raw cost, since a laptop is a sunk cost and a CDE is a recurring one.
+What is the main limitation?
Latency and offline work. Editing over a network connection is noticeably worse on a bad connection, and nothing works on a plane. Teams that adopt CDEs generally keep local development possible as a fallback rather than deleting it.
Related
Agent runtime
Not the model, not the framework: the thing that actually runs the job.
Headless agent
Nobody is typing at it, so its output is actions and artefacts rather than replies.
Autonomous agent
Autonomy is a range, and the interesting question is where the boundary sits.
Task queue
The thing that lets a request survive the process that made it.
Cloud agents that keep working after you close the laptop
For the person whose agent is brilliant, local, single-player, and dead the moment the lid goes down.
Cloud agents versus local agents
Most teams end up running both. The useful question is which work belongs where.
What keeps running after you close the lid
The honest version: nothing on your laptop survives, so the work has to not be on your laptop.