How to do docker-compose down without the config file that made the up?

Question

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?

Question

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?

Answer 1

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.

Answer 2

To expand on @linux_fan's answer, there is no direct way to perform a down without a docker compose file.

There are two somewhat feasible solutions, which could work, but both come with there limitations:

1: Remove via Container Name Prefix

Important: If you gave a container a custom name, those containers must be removed manually, as they do not contain the prefix.

This method is a variation of linux-fan's solution, but replaces grep with the -f option. You can find where docker believes the docker-compose.yml file to be via docker compose ls. There, in the column name, you will also see the prefix given to each container spawned by Docker Compose.

1. Stop the containers docker container stop $(docker ps -q -f name=<DOCKER_COMPOSE_PREFIX>)
2. Remove the containers docker container rm $(docker ps -a -q -f name=<DOCKER_COMPOSE_PREFIX>)
3. Remove the Network: docker network rm $(docker network ls -q -f name=<DOCKER_COMPOSE_PREFIX>)
4. Remove any Volumes: docker volume rm $(docker volume ls -q -f name=<DOCKER_COMPOSE_PREFIX>)

Explanation

• docker ps prints out all running containers
• -q prints out only id's
• -a prints out all containers, regardless if running or not
• -f filters out so only ids with the prefix in it's name is printed

2: Remove via Network

You could also remove via taking a look at the network the docker compose file spawned. By default, docker compose spawns a network in which all containers are kept.

Warning: This method will shut down any containers that are part of the network (e.g. if you for some reason manually added a different container to the docker compose generated network)

1. docker network ls -q -f name=<DOCKER_COMPOSE_PREFIX>
2. docker network inspect <YOUR_DOCKER_COMPOSE_NETWORK_ID>
3. Find the Containers dictionary
4. Stop and Remove all containers found in this list via docker container stop <CONTAINTER_ID> and docker container rm <CONTAINTER_ID>

This method should catch any containers that have custom names, but are still in the default docker compose network.

Note that this is a very manual procedure, however you probably should be able to generate a bash script via ChatGPT that automates this.