Dev Containers
Configure dev container support in your templates using either Docker or Envbuilder.
On this page
Dev containers allow developers to define their development environment as code using the Dev Container specification.
Configuration lives in a devcontainer.json file alongside source code, enabling consistent, reproducible environments.
By adopting dev containers, organizations can:
- Standardize environments: Eliminate "works on my machine" issues while still allowing developers to customize their tools within approved boundaries.
- Scale efficiently: Let developers maintain their own environment definitions, reducing the burden on platform teams.
- Improve security: Use hardened base images and controlled package registries to enforce security policies while enabling developer self-service.
Coder supports two approaches for running dev containers. Choose based on your infrastructure and workflow requirements.
Tip
Nix flakes are an alternate way to handle dependency management. With Nix flakes, developers and template administrators define environments and manage dependencies at a much deeper level, without requiring a container runtime.
To learn how to use them in Coder with or without NixOS, visit the Nix(OS) page.
Dev Containers Integration
The Dev Containers Integration uses the standard @devcontainers/cli and Docker to run containers inside your workspace.
This is the recommended approach for most use cases.
Best for:
- Workspaces with Docker available (Docker-in-Docker or mounted socket)
- Dev container management in the Coder dashboard (discovery, status, rebuild)
- Multiple dev containers per workspace
Configure Dev Containers Integration
For user documentation, see the Dev Containers user guide.
Envbuilder
Warning
Envbuilder is in maintenance mode with no new features planned.
The recommended way to use dev containers in Coder is the built-in Dev Containers Integration. To find the best approach for your deployment, join our community to be guided towards the best approach.
Envbuilder transforms the workspace image itself from a devcontainer.json, rather than running containers inside the workspace.
It does not require a Docker daemon.
Best for:
- Environments where Docker is unavailable or restricted
- Infrastructure-level control over image builds, caching, and security scanning
- Kubernetes-native deployments without privileged containers