Your IDE Lives Outside the Container — Your Tools Live Inside
Think of a Dev Container like a rental workshop. Your hands (the VS Code GUI) stay in the real world, but all the actual work — compiling, running tests, installing packages — happens inside a fully equipped workshop that someone else set up and that you can throw away when you're done.
Dev Containers (standardized by the Dev Container Specification, popularized by VS Code and GitHub Codespaces) split your development experience into two layers:
- The editor GUI runs locally on your Mac or Windows machine. VS Code renders on your screen as normal.
- The environment runs inside a Docker container. Python, Node, Go, Terraform,
kubectl, and even specific VS Code extensions are installed inside that container.
When you open a project, VS Code detects the Dev Container configuration, spins up the Docker container, and connects to it transparently. Your terminal, your file system, your debugger — all of it runs inside the container. Your local machine stays completely clean. You do not need Python installed locally to write Python code.
The Config: .devcontainer/devcontainer.json
The entire environment is defined by a single JSON file checked into the repository at .devcontainer/devcontainer.json. A realistic configuration for a Python project that also uses Terraform would specify a base image, layer on a couple of tool features, list the VS Code extensions and settings to apply inside the container, run a post-create command to install project dependencies, and set a non-root remote user. Breaking down each key field:
| Field | Purpose |
|---|---|
image |
The base Docker image. Microsoft publishes pre-built images for Python, Node, Go, Java, and more. |
features |
Composable add-ons that install additional tools (Terraform, AWS CLI, kubectl) on top of the base image. |
customizations.vscode.extensions |
VS Code extensions installed automatically inside the container. |
customizations.vscode.settings |
Editor settings applied only inside this container. |
postCreateCommand |
A shell command run once after the container is built — ideal for installing project dependencies. |
remoteUser |
The Linux user inside the container. Using a non-root user is a security best practice. |
Features: Composable Tool Layers
The features system is one of the most powerful aspects of Dev Containers. Instead of writing a custom Dockerfile that installs Terraform, you reference a pre-built, versioned feature from a registry. Features are composable — you can stack as many as you need without writing any Dockerfile logic yourself. The Dev Container CLI assembles them into a final image at build time.
This means a team can maintain a single base image and let individual projects declare which additional tools they need via features, rather than maintaining dozens of custom Dockerfiles.
Interviewers sometimes ask: "How do you ensure all developers on your team use the same version of a CLI tool like Terraform?" A weak answer is "we document it in the README." A strong answer describes codifying it in a Dev Container feature with a pinned version ("version": "1.7.0"), so the tool version is enforced automatically rather than trusted to human discipline. Follow up by mentioning that the .devcontainer/ directory is committed to version control, so tool upgrades go through code review.