Shared dev containers break on collaborators’ local files
Teams sharing VS Code dev containers rely on local files and paths—such as kubeconfigs, signing keys, and environment files—that differ between collaborators or may not exist on a fresh clone. When the shared configuration treats those files as required, container startup or builds can fail; editing the shared config to make it work locally can also make team updates harder. The host-path discovery request is a related but less central pain.
For teams sharing VS Code Dev Containers across different local setups. Mentioned from Jun 2019 to Nov 2024 on GitHub.
7 different people described this problem in 5 separate discussions.
- Indie fit
- 5.0/10
- Pain
- 6.0/10
- Frequency
- 7.5/10
- Willingness to pay
- 0.0/10
- Momentum
- 5.0/10
- Who pays
- Businesses
- Competition
- Medium
- Build difficulty
- Medium
What people said
Quoted word for word. Follow a link to read the whole discussion.
What usually happens is, that everyone starts the Container, then the first build will fail, people modify their devcontainer.json and re-build so it works again
Some users might not have those files. They will get an error in that case. Feature Request: Mark mounts as optional or check if they exist on startup
Build brief
See what to build and who will buy it
- 2 product ideas with the smallest useful version and pricing
- 3 places to find your first customers
- 6 more quotes from people who have this problem
- Current workarounds, existing solutions and risks