CDEs are a new product category. A lot of new CDE products were announced in 2022 and 2023, and CDEs were included in Gartner’s Hype Cycle of emerging technologies for the first time in 2023.

As a result, a lot of content is being published about CDEs - however most content focused on the benefits of CDEs and either doesn’t really explain how CDEs work, or only touches on the subject superficially. In this blog post, I want to provide a no-bullshit overview of the architecture of CDEs and common patterns on how CDE products work.

What are Cloud Development Environments (CDEs)?

CDEs are work environments for software developers that contain all tools that software developers need to do their work. They are provided remotely, often in the cloud, though they can also be provided on-premise, within the internal network of a company.

How do CDEs work?

Despite being a new product category, first standards are emerging of how CDEs commonly look like. The below diagram shows the very basic layout of a standard CDE.

Typically:

• An IDE thin client of an ssh-capable IDE such as VS Code or the JetBrains IDEs (e.g. IntelliJ) remains on the developer’s laptop. This means that most CDEs do not fully remove the need for local tooling or make a developer fully independent to work from any device: usually at least the IDE client needs to run locally, and be configured to connect to the IDE backend in the CDE via ssh.
• The CDE contains a copy of the source code repository. By accessing the source code via the IDE backend remotely, source code security is ostensibly improved, however remote IDEs might still cache source code locally.
• Any other tools that are required for development also run in the CDE: language runtimes, SDKs, linters, etc. Users can configure which tools they want on their CDE.
  • Two standards for CDE configuration exist: devfile.yml and devcontainer.json. Both assume that the CDE is a single container and allow specification of which tools should be deployed to this container, as well as a reference to scripts that should run after the container has been created.
  • Not all CDE products use these standards, many have custom configuration schemata and/or allow configuration using other tools and standards such as Dockerfiles or Terraform configuration.
  • Other CDE products do not use containers as CDEs but VMs. These tools mostly use a proprietary configuration format, often in combination with tools like Docker Compose.

Which software can run on a CDE?

Next to developer tools, developers need to run the software they work on within their development environments. CDEs differ in what type of software they can run:

• Single-container CDEs are the most common. These allow you to run any software that can sensibly run within a single container. For example, a yarn project with a webserver can easily run in a container - for development of such a project, a single-container CDE is suitable.
• Multi-container CDEs are ones that deploy several containers to Kubernetes, OpenShift, or just with Docker. They assume that the application that developers work on consists of several containers. The CDE container is deployed alongside the application containers. Such a CDE is suitable for developers working on Kubernetes-based applications with several containerised components.
• VM CDEs do not confine the developer to a container but give them full access to a VM where the developer can deploy whatever they want. This also makes it possible to deploy multi-container applications, with the difference that the developer tools are directly on the VM, removing one layer of separation between the developer and the containerised application. VM CDEs also allow the use of existing deployment or local build scripts that assume a VM-based environment.

The choice of CDE should be based on the production deployment of the software that is being developed. If the software runs in a single container in production, then a single container CDE is the best choice. If the software runs in Kubernetes (or similar) in production, then a multi-container CDE should be used. If the software runs on a VM in production, then a VM CDE is the best option.

A special case are Remote Desktop CDEs. Microsoft Dev Box is currently the only vendor that provides remote desktop environments specifically as software development environments. For working on desktop software that requires a Windows environment, or for fat clients without a web frontend, remote desktop CDEs might be the only option.

What is the difference between a CDE and just any container or VM with developer tooling?

Devfile.yml and devcontainer.json are open standards for defining (single container) development environments. So what is the added benefit of paying for a CDE product?

CDE products usually provide:

• Automation to create CDEs based on configuration files. This usually includes automatic creation of the infrastructure as well as deployment of the CDEs themselves.
• A management layer where users can create, start, stop, remove and monitor CDEs, often with additional administrative functionality like CDE access management etc. This management layer is usually available as a web portal and/or a command line interface (CLI).
• Infrastructure where the CDEs run - at least for SaaS offerings. On-premise CDEs come with a clear concept of where and how to run CDEs and automation for this infrastructure.
• Templates for CDEs with common toolstacks, as well as examples and documentation.

Many CDE products offer additional special features such as ultra-fast CDE creation, or automatic prebuild of CDEs on each commit, or special security and insight features, or they are bundled with other products that make software development easier - but those special features are specific to each individual CDE product. Generally, what a CDE product does is: it makes it as easy as possible to create, use and manage CDEs.

What CDEs are not

CDEs do not replace a CI/CD pipeline which deploys your application into production and runs a full set of tests. Some of the same tools might be used, such as Docker Compose or Terraform, however the point of CDEs and the automation behind them is to deploy your application next to or within development environments. Most importantly, CDEs:

• Contain the full source code in plain text, i.e. it is neither compiled nor minimised or packaged
• Contain developer tools which are not needed in production, such as compilers, SDKs, debuggers, OS utilities etc.

Also, CDEs do not replace developer laptops. Developers who use CDEs will need less beefy laptops, however most CDEs still assume that at least an IDE client still runs locally. There are some CDEs that make it possible to work only with a browser, with the IDE also being served in-browser. However not all CDEs support this, and working fully in-browser represents a significant change to how developers work locally.

Summary

• CDEs are work environments for software developers that run on remote servers.
• While all CDEs are slightly different, the most common CDE setup involves an IDE client being installed on a developer’s laptop, which connects via ssh to an IDE backend on a CDE that is either a container or a VM. Besides the IDE backend, the CDE contains the source code as well as developer tools such as language runtimes and SDKs, build tools, linters etc.
• Major differences between CDE products are related to their core architecture: Single-container, multi-container, VM and remote desktop CDEs are compatible with different software development projects.
• CDEs don’t replace CI/CD pipelines, and also don’t make developer laptops obsolete.

For a deep dive into different CDE products, their features and differences, read my whitepaper “Full list of CDE vendors 2024 (+feature comparison table)”.