Devfile and devcontainer as standards for configuring Cloud Development Environments (CDEs)

  • Published

Cloud Development Environments (CDEs) are work environments for software developers which are provided remotely, often in the cloud. They aim to remove developer’s dependence on their laptops, by providing an environment where they can work on code and run their applications in the cloud.

CDEs have become increasingly popular in recent years, with several new products entering the market in 2023 and 2024. In August 2023, Gartner added CDEs to their hype cycle of emerging technologies, demonstrating both the increasing popularity as well as the immaturity of CDEs as a product category.

One sign of this immaturity is the lack of standardisation across CDE products. There are large differences in functionality provided by different CDE products. However there is one aspect where standards are used across the majority of CDE products: The configuration of CDEs.

In this article, I explain the standards that exist, what they have in common, where they differ, and why some CDE vendors are not using these standards.

What are devfile and devcontainer?

Devfile and devcontainer are two standards to describe container-based development environments. They both were developed in a time when containers were all the rage, and the idea was born that development environments could be standardised using containers. At that time, the idea was to standardise local development environments by running development containers on developer’s laptops. While the devcontainer standard does have some features that support deployment of development containers to remote environments, this was not the primary use case at the time that these standards were conceived.

What can be configured using devfile and devcontainer?

Both standards rely on Docker to deploy containers. Which containers are deployed can be specified in the devfile.yml or devcontainer.json, which can reference container images in a registry, or docker-compose files to build containers from scratch. Both devfile and devcontainer allow reference to one or several containers. In addition to referencing containers, devfile and devcontainer allow to specify:

  • IDE configuration for some compatible / supported IDEs, e.g. extensions and source code path mappings,
  • Scripts and commands to run in the container(s), e.g. to start services or forward ports.

Devfile and devcontainer both do not specify the development container directly. Instead, they reference either existing containers in a container registry, or dockerfiles or docker-compose files from which containers can be built. Therefore, devfile and devcontainer provide an additional layer of configuration on top of dockerfile and docker-compose.

Some CDE platforms forgo this additional configuration layer entirely and instead use dockerfile or docker-compose directly to describe container-based development environments. This is a characteristic of more open CDE products which don’t limit developers to the use of a specific IDE, which could be customised via devfile or devcontainer. Without IDE customisation, the added value of devfile and devcontainer is limited. Commands and scripts to run inside the container can also be specified directly in dockerfiles and docker-compose files, though for development-specific container customisation, this would require development-specific dockerfiles or docker-compose files instead of using one set of generic container definitions and applying any development-specific configuration via devfile or devcontainer.

Read more: Detailed comparison of devfile and devcontainer vs. dockerfile and docker-compose

What are the benefits of devfile and devcontainer?

There are two main benefits of using devfile and devcontainer:

  1. They are open standards which are supported by a range of tools.
    There are IDEs as well as CDE products that can interpret these standards and deploy development environments based on a devfile.yml or devcontainer.json.
  2. They can be kept in the source code repository. As text-based configuration files, they can be kept in the source code repository next to the codebase for which they describe the development environment. This makes the repositories the single source of information that is required to create a development environment. The idea is that a developer or a tool like an IDE or CDE platform only needs access to the repository in order to be able to deploy a full development environment.

Which CDE platforms use which configuration forma

Vendor CDE config format Comment
Koding
Proprietary config format
Discontinued
Codenvy / Red Hat CodeReady Workspaces / Red Hat OpenShift Dev Spaces
devfile.yml
Eclipse Che
devfile.yml
Dev container deployed to K8s next to multi-container application
Coder
Terraform, can deploy containers based on dockerfile, docker-compose
Codesandbox
Docker- compose, Dockerfile
JetBrains Space
Devfile.yml
Okteto
Proprietary Okteto.yml
Dev container deployed to K8s next to multi-container application
Gitpod
Proprietary Gitpod.yml
Strong Network
GUI
Github Codespaces
Devcontainer.json
DevZero
GUI
Amazon CodeCatalyst
Devfile.yml
GCP Workstationst
Dockerfile
Nimbus
Manual creation of VM snapshots as templates
Discontinued
Microsoft Dev Box
GUI, Windows images
Windows VMs, remote desktop access
Gitlab Workspaces
devfile.yml
General availability since 01/2024
IDX by Google
Nix package
VM-based CDEs, don’t assume containers
DevPod by Loft Labs
devcontainer.json
Desktop application to deploy single-container CDEs to different environments
Dockerfile, docker-compose for containerised applications, custom config for non-containerised applications, can deploy nix packages
VM-based CDEs, don’t assume containers
Hocus
Proprietary hocus.yml
Alpha release with known bugs
Daytona
Not clear: devfile.yml or devcontainer.json or Nix package
Waitlist

Proprietary CDE configuration formats: Gitpod.yml, Okteto.yml, hocus.yml vs. devfile.yml and devcontainer.json

Despite the advantages of devfile and devcontainer as existing standards for describing containerised development environments, some CDE vendors have developed their own configuration formats. There are different reasons for this.The main reason is that they have product-specific configurations that cannot be expressed in devfile and devcontainer.
For example, gitpod offers prebuilds of repositories to speed up the deployment of CDEs. In the gitpod.yml, prebuilds can be configured (among other things). Okteto manifests allow the description of environments to a Kubernetes cluster, referencing helm charts and kubectl commands, which goes far beyond the scope of devfile and devcontainer.

Differences and similarities: Gitpod.yml, hocus.yml, Okteto.yml vs devfile.yml and devcontainer.json vs dockerfile and docker-compose

The table below gives an overview of what can be configured where and how. The table is not exhaustive: There are additional product-specific configuration options available in most of the formats listed here. The table lists only the core features that several of the formats have in common.

# What a single container contains: OS, software How several containers work together Commands and scripts to run in a container Container(s) that are part of the dev environment IDE configuration Port configuration
dockerfile
x
x
docker-compose
x
x
x
devfile.yaml
x
x (several)
x
x
devcontainer.json
x
x (several)
x
x
gitpod.yml
x
x (1 container)
x
x
hocus.yml
x
x (1 container)
x
x
Okteto.yml
x
x (several)
x

Summary

Many CDE products use the devfile and devcontainer to configure CDEs, which are standards to describe container-based development environments. However, they provide only a thin additional layer of configuration on top of containers, which are referenced either as container images in a registry or via dockerfile or docker-compose files. Several CDE products therefore offer configuration directly via dockerfile or docker-compose. Other CDE products have developed their own configuration formats which provide additional, product-specific configuration options. Do you want to compare CDE vendors? Check out our whitepaper “Full list of CDE vendors (+feature comparison table)“.

Margot Mückstein

CEO & co-founder of Cloudomation