A cloud development environment (CDE) is a development workspace that runs on remote compute instead of your laptop, built from a version-controlled definition so anyone on the team can provision an identical copy on demand.
The pitch is always onboarding: clone the repo, open the workspace, the runtime is already there, and nobody loses a morning to a native dependency that wants a Python version their machine lacks.
The developers who moved tell a different story. The biggest thread on the subject is titled “Dev environments in the cloud are a half-baked solution” and runs past three hundred comments. The complaints repeat: environments drift anyway, working over a network feels bad, browser editors are worse than the one already installed. Nearly every page ranking for this term was written by a vendor or an analyst, and almost none of them mention any of it.
Both halves are below.
What Is a Cloud Development Environment?
A cloud development environment is remote compute plus a declarative definition of what belongs on it. The compute is a container or a VM. The definition is a file: a devcontainer.json, a Terraform template, or a provider-specific configuration object. Opening the project applies it and hands back a shell, a filesystem, and a running toolchain.
That definition is the difference between a CDE and a box you SSH into: a machine configured by hand a year ago cannot be rebuilt by anyone else.
Three shapes are common in practice:
- A spec file in the repo. The Development Containers specification, an open format for “enriching containers with development specific content and settings”, is the closest thing this category has to a standard. Ona, formerly Gitpod, builds environments directly from a
devcontainer.jsonat the project root. - Infrastructure as code. Coder describes each workspace with a Terraform template covering EC2 VMs, Kubernetes pods or Docker containers, and runs on infrastructure you host yourself.
- A managed configuration object. Google Cloud Workstations uses a workstation configuration pinning the VM instance type, persistent storage, container image and editor, then runs workstations on ephemeral Compute Engine VMs with a persistent disk attached for the session.
CDE vs. Cloud IDE vs. Remote Development
These three get used interchangeably and are not the same thing. A cloud IDE is an editor. Remote development is a workflow. A cloud development environment is a workspace defined in code.
| Cloud IDE | Remote development | Cloud development environment | |
|---|---|---|---|
| What it actually is | An editor delivered in a browser tab | A way of working: local editor, remote compute | A whole workspace built from a definition |
| Where the editor UI runs | Remote, rendered in the browser | Locally, on your machine | Either |
| Where code executes | Remote | Remote | Remote |
| Defined by | Nothing. It is a user interface | Your SSH config, if anything | A versioned file in the repo |
| Reproducible by a teammate | No | No | Yes, and that is the point |
VS Code Remote Development is the clearest example of the middle column. Its SSH, Dev Containers, WSL and Tunnels modes install a VS Code Server on the remote host, so extensions and language servers run next to the code while the interface stays on your desk. If your objection to CDEs is the browser editor, you are objecting to the first column.
When Your Laptop Stops Being Enough
The honest case for a CDE is capacity, not convenience.
The most upvoted answer in the largest recent r/devops thread on the question comes from a team whose stack outgrew what a Mac could power, and who moved for that reason rather than for onboarding. That argument does not depend on you enjoying remote work surfaces. It is arithmetic.
The triggers:
- The stack does not fit. Twenty containers, a search index, a broker and two databases exhaust a laptop’s RAM long before they exhaust a server.
- Architecture mismatch. Production images are usually amd64 and modern Macs are arm64. Docker’s own documentation says its VM manager does not support Rosetta, so emulating amd64 is slow. Developers on Reddit report the Apple Silicon transition breaking local VM setups outright, which is consistent with that caveat.
- Proximity to data. If the dataset lives in a cloud region, moving compute to the data beats pulling an extract down a home connection.
- Onboarding is a recurring cost. This only matters at hiring volume. For a team of four it does not pay for the overhead.
Why Developers Push Back on Cloud Dev Environments
Because most of the objections are correct, and two of the four are fixable.
Drift happens anyway, and this is the serious one. It attacks the core claim. A definition file pins only what it names. A base image tagged :latest, an apt-get install without a version, an npm install resolving differently in September than it did in May: all of it produces environments that diverge while claiming to be identical. Pinning versions and rebuilding from scratch on a schedule is the fix, and somebody has to own it. A CDE nobody maintains drifts like a laptop, except now it drifts for everyone at once.
Browser IDEs are worse than local editors. Often true, and avoidable. Google Cloud Workstations supports VS Code and JetBrains IDEs over SSH alongside its browser editor, and Coder connects through VS Code, JetBrains, Cursor, a web terminal or plain SSH.
Depending on the network for everything feels bad. Not fixable, only weighed. When the connection drops, the terminal and the test runner go with it. Placing the environment near the team shortens the round trip but never removes the dependency.
Cost is asymmetric. An idle laptop costs nothing extra. An idle cloud workstation bills until something turns it off, which is why idle timeouts are a standard feature.
The decision rule. If your stack still fits on the laptop, a CDE is mostly ceremony. If it does not, drift and latency are the price, and both are cheaper than the problem you already have.
Where CDEs and Agent Sandboxes Are Converging
The clearest signal of where the category is going is that Gitpod, one of the original CDE vendors, relaunched as Ona and now leads with running background agents in the cloud, describing each agent’s environment as “more than a sandbox” with tools, network access and permissions attached.
The shapes are the same: a remote Linux machine, built from a definition, discarded when finished. What differs is the target. A CDE optimizes for a human’s edit-run-debug loop, so latency and editor integration dominate. An agent sandbox optimizes for containment and for resetting to a known state, a separate problem covered under agent sandboxes.
Cloud Development Environments on Fly.io
Fly.io provides the substrate rather than a turnkey CDE product, which fits if you want to define the workspace yourself. A Fly Machine is a Firecracker microVM on a dedicated physical server, started and stopped at subsecond speeds through flyctl or a REST API. That covers provisioning: an environment per developer, or per branch, created and destroyed on demand.
- Persistent state. A Fly Volume is a slice of NVMe on the same physical server as the Machine it mounts, and it survives restarts, so a checkout and its dependencies outlive a stop.
- Private access. Every organization gets a 6PN network, a WireGuard mesh over IPv6.
fly wireguard createputs your laptop on it, so a local editor reaches the environment without it being exposed to the public internet. - Idle handling. Fly Proxy stops Machines when they go idle and starts them on the next request, and a stopped Machine is not billed for CPU and RAM.
- Placement. Machines run in 18 regions, so the environment sits near the team.
Frequently Asked Questions
What does CDE stand for?
CDE stands for cloud development environment: a workspace that runs on remote compute and is built from a version-controlled definition rather than assembled by hand. On Fly.io, the compute underneath one is a Machine, a Firecracker microVM with a persistent volume attached.
What is the difference between a cloud IDE and a cloud development environment?
A cloud IDE is an editor in a browser tab. A cloud development environment is the whole workspace behind it: operating system, runtimes, dependencies and services, built from a definition file. On Fly.io you can run one with no browser editor at all, connecting a local editor over SSH.
Is a cloud development environment better than local development?
No, not universally. It wins when the stack outgrows the laptop, when the team runs mixed operating systems and CPU architectures, or when onboarding is a recurring cost. Local development still wins offline and on hardware access. Many teams edit locally and run the heavy services on Fly.io Machines.
Do cloud development environments actually prevent environment drift?
No, not by themselves. A definition file pins only what it names, so floating image tags and unpinned installs still diverge over time. Pinning versions and rebuilding from scratch on a schedule is the fix, and running that rebuild as a job on Fly.io catches drift before a developer does.
Can I use my own editor instead of a browser IDE?
Yes. VS Code Remote Development installs a server on the remote host and runs extensions and language servers there while the interface stays local, and JetBrains IDEs connect the same way. A Fly.io Machine on your organization’s private WireGuard network works as that host.
Are there open source cloud development environment options?
Yes. The Development Containers specification behind devcontainer.json is an open standard, and Coder is a self-hosted platform that defines workspaces as Terraform templates and runs on infrastructure you control. Fly.io is one place to put that infrastructure, since Machines are driven by flyctl and a REST API.
How much does a cloud development environment cost to run?
The cost is compute time plus storage, which is why every serious implementation has an idle timeout. On Fly.io, Fly Proxy stops Machines when they go idle and starts them on the next request, and a stopped Machine is not billed for CPU and RAM, though its volume still is.
Do cloud development environments work offline?
No. The compute is remote, so a dropped connection takes the terminal and the test runner with it. Teams who need to work on a plane keep a local checkout and treat the Fly.io environment as where the full stack runs.