Local Dev Container Cleanup: Remove Services That No One Starts

Local dev container cleanup starts when compose files, devcontainer definitions, seed services, and helper images still start databases, queues, mock APIs, or admin tools that current developers no longer need. The waste shows up as slow onboarding, port conflicts, fragile setup scripts, and confusing docs.

The useful result is a smaller local stack that still supports the workflows developers actually run: boot the app, run tests, debug integrations, and reproduce common incidents.

Key takeaways

• Review compose services, ports, volumes, health checks, seed data, and documentation together.
• Prove whether a service is needed for app boot, tests, demos, or incident reproduction.
• Remove unused services in stages by making them optional before deleting them.
• Preserve fixtures or images that still reproduce important bugs.
• Prevent recurrence with owned local stack profiles.

Service Evidence

Service	Evidence to collect	Cleanup signal
Database	App config, migrations, tests, seed scripts	No current workflow connects to it
Queue or broker	Worker commands, integration tests, retry docs	Worker path moved or is mocked elsewhere
Mock API	Contract tests, local demos, support workflows	Real sandbox or generated fixtures replaced it
Admin tool	Docs, port usage, developer survey	Tool is not needed for routine debugging

Do not remove services based only on container startup frequency. New teammates and rare debugging tasks may still depend on them.

Example Stack Review

dev_stack_review:
  service: legacy-search
  starts_by_default: true
  current_consumers: none
  replacement: hosted search sandbox
  proposed_change: move to optional profile for one release

Making a service optional first gives the team a chance to discover hidden dependencies.

Cleanup Path

First, move suspicious services behind optional profiles or explicit commands. Update onboarding docs and test commands. Watch support questions and CI failures. If no supported workflow needs the service, remove its container definition, volumes, ports, seed files, and stale docs.

Do not rush services used for migrations, contract tests, customer demos, or reproducing production bugs. Do not rush removal when the service is the only offline fallback for developers without access to shared sandboxes.

Prevention

Define local stack profiles such as default, full-integration, demo, and incident-repro. Every new service should declare which profile owns it, what workflow requires it, and when it can be removed. A fast default stack is easier to keep clean than a single all-purpose setup.

FAQ

Should every dependency run locally?

No. Run locally what developers need for fast feedback. Use sandboxes, fixtures, or mocks when they are more reliable.

Is optional profile cleanup enough?

It is a good first step. If no one uses the optional profile after a review period, remove the service entirely.