When you do docker-compose up, it's based on a docker-compose.yml file.

This usually brings up a network, builds and runs multiple services. If you do the up with the -d flag, the docker-compose client detaches and let the servers alone.

If you do a docker-compose down, it shuts down the running containers and in addition removes the corresponding networks.

But... what if after the up, the .yml file has gone?


Do you have to manually do the shutdown via docker stop finding manually what are the services of that project, and docker rm and docker network rm and so on?

Or docker-compose is intelligent enough to tag all the things (containers, nets, etc.) with a tag so you can tell it some thing like docker-compose down project-name so it does not look in the .yml (which is now not in the filesystem) file but inspecting the running instances and nets?


AFAIK you cannot just use docker-compose down without a corresponding docker-compose.yml.

However, your idea with the tagging is not so far from reality either: When invoking docker-compose up, docker-compose prefixes all the things it creates by the compose file's directory name. This allows identifying sets of containers which belong together even without the corresponding docker-compose.yml file. I frequently end up writing variations of this into my interactive shell:

docker rm $(docker ps -a | grep ... | cut -c -16)

Of course, if one were to script that "properly", one would use Docker's ability to format and search its output and rely properly on the names or IDs instead of just the first 16 characters from the IDs. Additionally, this is operation is idempotent because it fails if there are no matches for the grep.

Afterwards follow docker network rm ... and docker volume rm ... to clean up the remainder.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.