There’s no single “correct” way to customize a devcontainer, just like there’s no one right way to use most tools in software development. Devcontainers can be great for solo projects, to yield an isolated development workspace with no risks of polluting (or being polluted by) the external environment. They can also give teams a consistent, baseline environment for bootstrapping engineers, with integrations like GitHub Codespaces exposing that environment in a variety of ways. But the gap between those workflows is large, and managing it sometimes requires weighing a team’s needs vs. individual preferences.

It’s a balancing act, and getting it wrong can make your containers brittle, difficult to maintain, and cause enough overall frustration to outshine the benefits.

Yet there are options available for a more-granular approach. We don’t have to decide just between bare-minimum or include-everything – we can curate containers that are focused on the core tools used across the entire team, while still providing room for per-user expansions.

Today, we’ll explore a few approaches for customizing a shared devcontainer setup across different team scenarios, without having to abandon shared devcontainers altogether.