A cloud development environment moves the work off your machine. The editor, the terminal, the installed dependencies, the build and the running application all live on a machine somewhere else, and you reach it from a browser tab or a thin client. A file in the repository describes the environment, its language versions, tools and services, so it can be built again from scratch in minutes rather than set up by hand over a day.
It is a practice rather than a rung because it changes where the work happens, not how much of the engineering you take on. A site builder, an agent in the editor and a delegated agent can all run in one. Delegated agents increasingly do, which is why the category is often lumped in with them.
What it is for
- Working on a project your own machine cannot run: too little memory for the build, too little disk for the dependencies, too slow for the test suite.
- Keeping heavy downloads off a metered connection. The packages install on the remote machine, over its connection rather than yours.
- Work that survives your power supply. A laptop that dies in a power cut takes nothing with it, because the files and the environment were never on it.
- A new contributor working within the hour from the repository's own definition, instead of after a day of setup and a list of things that only worked on one person's machine.
- Somewhere for a delegated agent to run that is not your laptop, with its own copy of the code and nothing else of yours within reach.
Who it suits
Developers whose hardware, power or connection is the constraint, a larger group than most tooling is designed for. For someone on a low-end laptop and a patchy connection, moving the environment off the machine is not a convenience. It is what makes the work possible.
Also teams that onboard often, and teams that run autonomous coding agents and want each one working in an environment that is separate from everything else and easy to throw away.
How to tell this is your category
- Your editor or your terminal is connected to a machine you have never seen.
- The repository carries a file that describes the environment, and the environment is built from it.
- Closing the laptop does not stop the build.
- If the machine in question is where the software runs for its users, rather than where you write it, keeping it running is AI DevOps and cloud engineering.
What it costs you later
The practices page names three costs: a connection and a provider to depend on, your code on someone else's hardware, and one more configuration to maintain. This is how each of them arrives.
- No connection, no work. Everything you type into a remote terminal waits on the round trip, and on a slow connection that wait is on every command. When the connection drops mid-command, a plain remote shell can take the command down with it. Run long jobs in a session that survives a disconnect, and know what you would do on a day the connection does not come back.
- The data moves, it does not disappear. The installs happen over the remote machine's connection, but the session itself crosses yours for as long as you work. On metered data, measure what an ordinary working day costs before you count on it being cheaper than working locally.
- Machine time is billed. Find out what an hour costs, what a larger machine costs, and whether an environment you forgot to stop keeps costing. If there is a free allowance, it is a budget. Know what happens when it runs out in the middle of a week you are working to a deadline.
- Your code, and your secrets, live with the provider. The repository, the environment's variables and anything the tests need sit on hardware you do not control. On client work, where the code may live is the client's decision as much as yours, and worth agreeing before it moves. Keep production credentials out of any environment an agent works in. Test credentials, scoped to the least they need, are the most it should hold.
- The definition is code, and it rots. The environment file pins language versions, tools and services, and every one of them goes out of date. An environment that installs one version while production runs another passes the tests and fails the deploy. Review a change to it as carefully as a change to the code, and keep its versions in step with what production runs.
- One provider's format. A definition only one provider can read ties the repository to that provider. Prefer a plain definition that another provider, or a local machine, can also build from. That is also the fallback for the day the provider is down or the account lapses: a repository that runs somewhere else, even slowly, is one you can still work on.
Before you move the work off your machine
- What does an ordinary working day cost in data, measured rather than guessed?
- What does an hour of machine time cost, and what stops an idle environment?
- Who can read the code and the secrets in it, and has the client agreed to that?
- Is the environment defined in a file in the repository, readable by more than one provider?
- What happens to a running command when the connection drops?
- Can the project still be worked on, even slowly, somewhere else?