Dev Containers: The end of eternal local configurations

Posted by

   

Every developer has experienced at least once the nightmare of having to reconfigure a project's working environment on a new machine. After hours of setup, the new machine is still not 100% operational. Different versions of Node.js, missing libraries, environment variable conflicts: managing the development environment is often a blocker to productivity.

The solution? Development Containers (Dev Containers).

🔗 Do you like Techelopment? Check out the website for all the details!

What is a Dev Container?

Dev Containers (Development Containers) are a way to define and run a complete development environment inside a Docker container, ensuring that all developers work in the same environment regardless of their operating system.

The idea is: instead of manually installing languages, SDKs, libraries, and tools on your PC, you describe everything in a configuration and Docker creates an identical environment every time.

In simple terms, a Dev Container is an isolated, complete, and reproducible development environment defined as code.

Thanks to Docker technology, Dev Containers allow you to encapsulate the entire ecosystem needed to work on a project (languages, runtimes, build tools, editor extensions) inside a container. When you open your editor (such as VS Code), it "connects" to the container: you are no longer writing code on your local operating system, but inside an isolated environment that precisely mirrors what the project requires.


Why do they exist?

Imagine a team developing in Python:

  • You have Python 3.12
  • A colleague has Python 3.10
  • Another uses Windows
  • Another uses Linux

Result: "it works on my machine."

With a Dev Container:

  • everyone uses the same version of Python
  • the same dependencies
  • the same tools
  • the same configuration

and the project behaves the same way for everyone.


Dev Containers vs. "Pure" Docker: What's the Difference?

It's common to think that if you are already using Docker for your production containers, you are already doing "Dev Containers". In reality, there is a substantial difference in purpose and integration:

  • Docker (the engine): Focuses on running the application in an isolated environment, optimized for deployment, scalability, and security in production. When you use "pure" Docker for development, you often have to manually manage volume mappings, port forwarding, and above all, you have a clear separation between your code editor (on the host) and the execution environment (in the container).
  • Dev Containers (the development environment): This is a layer of deep integration on top of Docker. While Docker only gives you the "engine", the Dev Container gives you the entire "workshop".
    • IDE Integration: The Dev Container automatically configures the editor (VS Code) to "live" inside the container. This means that code completion, the debugger, terminals, and editor extensions run directly in the environment where the project's libraries reside.
    • "Batteries-included" Configuration: Beyond defining the language and dependencies, the devcontainer.json file automates the installation of editor plugins, the setup of formatting tools (linting), and even the customization of IDE user settings.
    • User Experience: With pure Docker, you often have to leave the terminal or set up complex scripts to make your PC talk to the container. With Dev Containers, the experience is seamless: you don't feel the difference between working locally and working in a container, except that your environment is finally consistent and isolated.
In summary: Docker is the technology that makes isolation possible; Dev Containers are the implementation that makes that isolation productive, ergonomic, and standardized for the developer.

  • Standard Docker: used to run applications
  • Dev Container: used to create a development environment


Why should every developer use them?

1. Zero "Initial Setup" (Immediate Onboarding)

Imagine bringing a new developer onto the team. Instead of spending two days installing dependencies, databases, and various tools, they just need to clone the repository and click "Reopen in Container". In a few minutes, the environment is ready and identical to everyone else's.

2. Total Consistency

The Dev Container eliminates the "local configuration" variable. Every team member uses the same language and tool versions. If it works in the container, it will work in production.

3. System Isolation (Cleanliness)

You no longer need to install ten different versions of Python or Node.js on your machine. Your operating system stays clean: if you need the project, the container is running; when you no longer need it, you remove it without leaving residues or library conflicts.

4. Configuration as Code

With devcontainer.json files, the environment configuration lives inside the repository. You can version, share, and update the development environment exactly as you do with source code.


Understanding Dev Container Usage

How to get started

To get started, you just need:

  1. Docker installed.
  2. VS Code (or a compatible editor).
  3. Microsoft's "Dev Containers" extension.

Once configured, add a .devcontainer folder to your project with a devcontainer.json file. You will be able to define the Docker image to use and which editor extensions should be automatically installed inside the environment.

How it works

You will typically find a folder structure like:

.devcontainer/
├── devcontainer.json
├── Dockerfile

devcontainer.json

Describes how to launch the environment:

{
  "name": "My App",
  "build": {
    "dockerfile": "Dockerfile"
  }
}

Dockerfile

Defines the container:

FROM python:3.12

RUN pip install poetry

When you open the project in a compatible editor (such as Visual Studio Code), the container is built and your editor automatically connects inside of it.

What do you see as a developer?

From your perspective:

  1. You open the repository.
  2. You click "Reopen in Container".
  3. You wait for Docker to build the environment.
  4. You work normally.

The terminal, debugger, extensions, and tools all run inside the container.


How are cloned repositories handled at the filesystem level to work on them (e.g., in VS Code)?

The answer depends on where the repository is located relative to the container.

Most common case: repository on the host filesystem

When you open a local folder with VS Code and choose "Reopen in Container", the repository remains on your computer.

For example:

Mac/Linux:
~/projects/my-app

Windows:
C:\projects\my-app

Docker mounts that folder into the container via a bind mount.

Diagram:

Host
└── ~/projects/my-app
      │
      ▼
Container
└── /workspaces/my-app

If you run this in the container terminal:

pwd

you might see:

/workspaces/my-app

but the files are physically still on your disk.

Consequences

If you modify:

/workspaces/my-app/src/index.js

you are actually modifying:

~/projects/my-app/src/index.js

on the host.

Because of this:

  • Git tracks changes normally
  • you can use Git tools both inside and outside the container
  • deleting the container does not delete the repository

Codespaces or Remote Containers case

With GitHub Codespaces, the situation is different.

The repository is cloned directly onto a remote VM:

Remote VM
└── /workspaces/my-app

VS Code connects remotely.

Here, the files are not on your PC, but on the server hosting the Codespace.

Where does the container's filesystem live?

In addition to the repository mount, the container has its own internal filesystem:

/
├── usr/
├── bin/
├── etc/
└── workspaces/

Everything you install in the container:

apt install curl

ends up in the container's Docker layer.

If the container is recreated:

docker rm ...

those changes may be lost unless they are described in the Dockerfile.

This is why installations are typically placed in:

RUN apt-get install ...

rather than installing them manually.


Pros and Cons

Pros Description
Extremely Fast Onboarding A new developer can get started in minutes:
git clone ...
Open the Dev Container and you are ready to go.
Reproducible Environment If the container works today, it will work months from now.
No PC "Pollution" You don't need to install dozens of tools on your host system.
Cross-Platform Compatibility Windows, macOS, and Linux all use the exact same development environment.
More Consistent CI/CD You can use Docker images similar to those in your continuous integration and deployment pipeline.


Cons Description
Requires Docker Docker must be installed and running.
Consumes Resources RAM and CPU are used by the container.
Slow Initial Build The first container creation can take several minutes.
Debugging Certain Services For applications interacting with local hardware or graphical user interfaces (GUIs), debugging can be more complex.


Conclusion

Dev Containers are not just a technological addition; they are a paradigm shift. They transform the development environment from a "problem to solve every time" into a standardized and reliable resource.

If you want to boost your team's velocity and drastically reduce bugs caused by misconfigurations, integrating Dev Containers into your workflow is the most logical step to take today.

Are you already using Dev Containers in your daily workflow, or do you prefer keeping your development environments directly on the host?


Links




Follow me #techelopment

Official site: www.techelopment.it
facebook: Techelopment
instagram: @techelopment
X: techelopment
Bluesky: @techelopment
telegram: @techelopment_channel
whatsapp: Techelopment
youtube: @techelopment