# Objective
Docker Compose devcontainers currently resume only the primary container
when an existing environment is stopped. Supporting services listed in
`runServices`, such as databases and caches, remain stopped.
Fixes#60779
## Solution
Reuse the Docker Compose startup path when resuming an existing
Compose-based devcontainer.
The resume path now:
- Runs `docker compose up -d --no-recreate`.
- Targets the services configured in `runServices`.
- Uses the original Compose files and project name.
- Avoids recreating the existing devcontainer.
- Preserves the existing `docker start` behavior for non-Compose
devcontainers.
A regression test verifies that the requested services are resumed,
unrelated services are excluded, and the existing container is not
recreated.
## Testing
Tested on macOS with:
- `cargo fmt --all --check`
- `cargo test -p dev_container`
- `cargo clippy -p dev_container --tests -- -D warnings`
All 112 `dev_container` tests pass.
Also tested against a multi-service Docker Compose devcontainer
containing a workspace, web server, PostgreSQL, Redis, and Celery. All
configured services resumed while the workspace container retained the
same container ID.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Release Notes:
- Fixed Docker Compose dev containers not starting all configured
services when resuming an existing environment.
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
