You prepackage an image with everything you need to run your app, then you mount your local directory as a volume where you COPY it into your container (the volume mount will override that file system path) and now you can run your container, edit your code, see live-reload do its thing (if you have that) and when it’s time to deploy - simply don’t mount your local directory and let the COPY do its thing.
Also, any 3rd party things (database for example) can be done with a docker-compose.local.yml omitting your app image and instead building it from .
This is directly parallel with non-containerized workflows. Dev servers often incorporate hot-reload and debugging. Production servers are polished with fewer entry points
Honestly, unless you have a requirement to use docker containers in local, I would simply use the IDE directly and containerize the other parts of the stack that you can. then test with containers
The question was “how can I dev with local containers”. I agree with you. What I described is that halfway point between “I need to debugger” and “Throw it all in a container and ship it to dev”. There are legit reasons to develop out of a container like this. Keeping the layers audited is one…
Also, any 3rd party things (database for example) can be done with a docker-compose.local.yml omitting your app image and instead building it from .