workflows, reduces the need for tickets and approvals, and promotes greater

independence for developers.

An administrator should construct or choose a base image and create a template

that includes a`devcontainer_builder` image before a developer team configures

dev containers.

There are several benefits to adding a dev container-compatible template to

Coder:

- Reliability through standardization

- Scalability for growing teams

- Improved security

- Performance efficiency

- Cost Optimization

Use dev containers to empower development teams to personalize their own

environments while maintaining consistency and security through an approved and

hardened base image.

Standardized environments ensure uniform behavior across machines and team

members, eliminating "it works on my machine" issues and creating a stable

foundation for development and testing. Containerized setups reduce dependency

conflicts and misconfigurations, enhancing build stability.

This doc explains how to use Envbuilder to integrate dev containers in a template.

Dev containers allow organizations to handle multiple projects and teams

efficiently.

For the Docker-based Dev Containers integration, follow the[Configure a template for dev containers](../../extending-templates/devcontainers.md) documentation.

You can leverage platforms like Kubernetes to allocate resources on demand,

optimizing costs and ensuring fair distribution of quotas. Developer teams can

use efficient custom images and independently configure the contents of their

version-controlled dev containers.

This approach allows organizations to scale seamlessly, reducing the maintenance

burden on the administrators that support diverse projects while allowing

development teams to maintain their own images and onboard new users quickly.

Since Coder and Envbuilder run on your own infrastructure, you can use firewalls

and cluster-level policies to ensure Envbuilder only downloads packages from

your secure registry powered by JFrog Artifactory or Sonatype Nexus.

Additionally, Envbuilder can be configured to push the full image back to your

registry for additional security scanning.

This means that Coder admins can require hardened base images and packages,

while still allowing developer self-service.

Envbuilder runs inside a small container image but does not require a Docker

daemon in order to build a dev container. This is useful in environments where

you may not have access to a Docker socket for security reasons, but still need

to work with a container.

Create a unique image for each project to reduce the dependency size of any

given project.

Envbuilder has various caching modes to ensure workspaces start as fast as

possible, such as layer caching and even full image caching and fetching via the

[Envbuilder Terraform provider](https://registry.terraform.io/providers/coder/envbuilder/latest/docs).

An administrator should construct or choose a base image and create a template

that includes an Envbuilder container image`coder/envbuilder` before a developer team configures dev containers.

By creating unique images per-project, you remove unnecessary dependencies and

reduce the workspace size and resource consumption of any given project. Full

image caching ensures optimal start and stop times.

Dev containers are a good fit for developer teams who are familiar with Docker

and are already using containerized development environments. If you have a

large number of projects with different toolchains, dependencies, or that depend

on a particular Linux distribution, dev containers make it easier to quickly

switch between projects.

| Capability / Trait| Dev Containers integration (CLI-based)| Envbuilder Dev Containers|

|------------------------------------------|------------------------------------------|-------------------------------------------|

| Build engine|`@devcontainers/cli` + Docker| Envbuilder transforms the workspace image|

| Runs separate Docker container| Yes (parent workspace + child container)| No (modifies the parent container)|

| Multiple Dev Containers per workspace| Yes| No|

| Rebuild when`devcontainer.json` changes| Yes (auto-prompt)| Limited (requires full workspace rebuild)|

| Docker required in workspace| Yes| No (works in restricted envs)|

| Admin vs. developer control| Developer decides per repo| Platform admin manages via template|

| Templates| Standard`devcontainer.json`| Terraform + Envbuilder blocks|

| Suitable for CI / AI agents| Yes. Deterministic, composable| Less ideal. No isolated container|

They may also be a great fit for more restricted environments where you may not

have access to a Docker daemon since it doesn't need one to work.

Consult the full comparison at[Choose an approach to Dev Containers](../../extending-templates/dev-containers-envbuilder.md).

[Dev container Features](https://containers.dev/implementors/features/) allow

owners of a project to specify self-contained units of code and runtime

-[Add a dev container template](./add-devcontainer.md)

-[Add an Envbuilder dev container template](./add-devcontainer.md)

-[Choose an approach to Dev Containers](../../extending-templates/dev-containers-envbuilder.md)