The Core Concept of CDEs

The Idea in One Sentence

Everything else about Cloud Development Environments follows from that idea. Where the environment runs, which IDE connects to it, and who pays the compute bill are downstream decisions. The concept itself does not require a cloud at all: a devcontainer that builds on a laptop is environment-as-code, and a hand-configured cloud VM that someone SSHed into and installed packages on is not. The distinction is whether the definition exists as a durable, executable description or only as accumulated state on a disk.

That is worth stating plainly because the vendor conversation almost always starts in the wrong place - with a platform, a pricing page, and a demo. The useful question is narrower: is the environment your team develops in a described thing or an assembled thing? Teams that answer "described" get most of the value regardless of which product they buy. Teams that answer "assembled" do not get the value even after they buy one.

The Failure Mode It Solves

The problem is not that setting up a machine is hard the first time. It is that the setup has no single source of truth, so every copy of it diverges from every other copy the moment it exists. This is environment drift, and it produces a specific and familiar set of costs.

Notice that none of these are solved by making laptops faster or by writing a better README. They are all consequences of the same missing property: the environment has no authoritative definition. Adding one is the entire concept.

What "Environment as Code" Actually Includes

"Environment" is vaguer than it sounds, and half-finished attempts usually fail because they codify one layer and leave the rest to chance. A complete definition covers five things. A devcontainer that pins the toolchain but tells engineers to "get a database from somewhere" has codified one of the five.

Declarative vs Imperative: Why the Distinction Matters

Writing the setup down is necessary but not sufficient. A bash script writes the setup down and still drifts. The property that matters is whether the file describes the desired end state or the steps taken to reach it.

#!/usr/bin/env bash
apt-get install -y postgresql-client
npm install -g pnpm
curl -o /usr/local/bin/tf https://example/tf
cp .env.sample .env

{
  "image": "ghcr.io/org/base@sha256:9f2c...",
  "features": {
    "node": { "version": "22.11.0" },
    "postgres-client": { "version": "16" }
  },
  "hostRequirements": { "cpus": 8, "memory": "16gb" }
}

Three properties come from the declarative form, and all three are the reason this distinction is not pedantry:

• Idempotence. Applying the definition to an environment that already matches it changes nothing. This is what makes it safe to run automatically, on every start, without anyone thinking about it.
• Diffability. A change to the environment shows up as a reviewable diff in a pull request. Upgrading a runtime becomes one commit that every environment inherits, rather than a message asking everyone to please upgrade.
• Reproducibility. Given the same definition and the same pinned inputs, you get the same environment - which is the property that lets you throw an environment away rather than repair it. Disposability is a consequence of reproducibility, not a separate feature.

In practice most real definitions are a declarative outer shell with a small imperative escape hatch inside it, and that is fine. The failure is when the imperative part grows until the declarative part is only a wrapper around a five-hundred-line install script. A useful rule of thumb: anything in the imperative section should be safe to run twice.

Documentation, Script, Definition

Most teams are already on one of three rungs. Knowing which one clarifies what the next step actually buys.

The Mechanisms

Several tools implement the concept, and they operate at different layers rather than competing for the same job. Most real setups use two: one that describes the machine the environment runs on, and one that describes the environment itself.

What the Concept Does Not Fix

Environment-as-code moves work rather than removing it. The setup that used to be duplicated across every laptop becomes a definition that someone has to own, keep current, and debug when it breaks for everyone at once. That is a good trade, but it is a trade: the definition is now a shared dependency with a blast radius, and a bad merge to it blocks the whole team rather than one person.

It also does not, by itself, make anything faster. A described environment still has to be built, and if the definition is written carelessly - unpinned inputs, layers that invalidate on every commit, a build that compiles from source - it can be considerably slower to start than the laptop it replaced. Speed comes from caching and prebuilding the described result, which is a separate piece of engineering.

And it says nothing about where the environment runs. Putting it in a cloud adds a different set of benefits and a different set of costs, which is a decision to make on its own evidence rather than one that falls out of adopting the concept. Those are covered in the mechanics and in the benefits and trade-offs.