Development Containers

Containers have historically been used to standardize apps when they’re deployed, but there’s a great opportunity to support additional scenarios, including continuous integration (CI), test automation, and  full-featured coding environments.  

Development containers provide the environment for these scenarios and ensure your project has  the tools and software it needs. While deployment and development containers may resemble one  another, you may not want to include tools in a deployment image that you use during  development. 

Development containers have been supported in Visual Studio Code since 2019, and more recently in GitHub Codespaces. This support is backed  by devcontainer.json, a structured JSON with Comments (jsonc) metadata format to configure a  containerized environment. 

Development Containers Specification

As containerizing production workloads becomes commonplace, development containers have become broadly  useful for scenarios beyond VS Code. A team across Microsoft and GitHub has started the Development Containers Specification, which empowers anyone in any tool to configure a consistent dev  environment. 

You may explore this specification on the related spec site and review both the spec and active  proposals for it in the devcontainers/spec repo. Other repos related to development containers and the  specification effort are also hosted in the devcontainers GitHub org

Let’s dig more into the development containers specification and how you can get started with dev containers today:

Development Container CLI

The development container CLI is an open source reference implementation for the specification. It’s available in  the devcontainers/cli repository. 

When tools like VS Code and Codespaces detect a devcontainer.json in a user’s project, they use a CLI  to configure a development container. This has opened up this CLI so that individual users and other tools can  read in devcontainer.json metadata and create dev containers from it. 

The development containers CLI can either be used directly or integrated into product experiences, similar to how it’s integrated  with remote containers and Codespaces today. The dev container CLI currently supports both a simple single container option and integrates with Docker Compose for multi-container scenarios. 

The dev container CLI can also be used to pre-build images to speed up start times. 

Development Containers for Build and Test 

Beyond repeatable setup, the same development containers provide consistency to avoid environment specific  problems across developers and centralized build and test automation services.  

A GitHub Action and Azure DevOps Task are available in devcontainers/ci for running a repository’s dev container in continuous integration (CI) builds. This allows you to reuse the same setup that you’re using for local development to also build and test your code in CI. 

Development Container Features 

Features in development containers are self-contained units of installation code, designed to install ontop a wide-range of base container images. 

The team at Microsoft and VS Code recently open sourced a new devcontainers/features repository. Referencing features from devcontainers/features is as simple as adding a features property to your devcontainer.json.  

The example below installs the go and docker-in-docker features: 

"name": "my-project-devcontainer", 

"image": "", // Any generic, debian-based  image. 

"features": { 

"": { 

"version": "1.18" 


"": { 

"version": "latest", 

"moby": true 


Here are the official and community-supported development containers features: 

Development containers features

Development Container Feature Authoring 

If you’d like to create your own development container features, a great place to get started is the new development containers features template repository. Beyond including a good template for the contents of a given feature, the template also  includes a GitHub Actions workflow to quickly publish them using the GitHub Container registry for your account to get you up and running as fast as possible. 

A development container feature has two required components:  

  1. The installation entry point script. This is conceptually added as a layer of the  image’s Dockerfile and executed during build time. This entry point script can install languages  (i.e. ruby) and tools (i.e. GitHub CLI). 
  2. devcontainer-feature.json: This contains metadata about the feature, a set of options that  can be passed to a feature’s install script during installation, as well as “pieces” of  devcontainer.json that will be merged into the final dev container.  

Dev container features can be authored in a variety of languages, the most straightforward being shell scripts. If a feature is authored in a different language, information about that feature should be included in the metadata so that users can make informed decisions.  

Development Container Feature Distribution

Development container features are distributed as tarballs. The tarball contains the entire contents of the feature sub directory, including the devcontainer-feature.json,, and any other files in the directory. 

The Open Container Initiative, aka OCI, defines industry standards for containers and container resources. Microsoft treats dev container features as OCI Artifacts and uses the concept of an OCI Registry to distribute them.

The features template repository mentioned above includes a GitHub Actions workflow to automate the publishing process. It packages each feature into a tarball and publishes the assets as an OCI artifact to GHCR. 

Trigger the release.yaml workflow from the template repository by selecting it on the left of  the repository’s Actions tab on GitHub. This will publish each feature to GHCR under the <owner>/<repo> namespace. A feature is only republished when the version property in its devcontainer-feature.json is updated. 

Sharing Development Container Features

If you’d like your contributions to appear in the VS Code remote development containers or GitHub Codespaces UI  for dev container creation, you may do the following: 

• Go to 

• Open a PR to modify the collection-index.yml file 

Contributing development container features

What Else is New for Development Containers?

Along with the new development containers features repo, Microsoft has recently open sourced a devcontainers/images repository where they host a specific set of images that were previously in the vscode-dev-containers repository

The Microsoft team is developing a community distribution plan for development container templates–aka “definitions” in  vscode-dev-containers–which will be similar to features. Updates will be shared in the vscode-dev-containers repo.

Learn More about Development Containers 

If you’re interested in learning more about development containers, you can check out and the devcontainers/spec repo.

In the repo, you’ll be able to review and comment on active proposals, like those for development container features and  features distribution, and create your own proposals. You may also open issues and pull requests across any of  the repos in the devcontainers org to help shape the future of dev containers.

If you’re using GitHub and VS Code in your workflow, consider leveling up your game with GitLens+ for VS Code, offering robust visualization and collaboration features.

Download GitLens Free!

The information in this article was provided by Brigit Murtaugh, senior program manager on the Visual Studio Code team at Microsoft. 

Contact:; @BrigitMurtaugh on Twitter 

Make Git Easier, Safer & more Powerful

With the #1 Git GUI + Git Enhanced CLI

Visual Studio Code is required to install GitLens.

Don’t have Visual Studio Code? Get it now.