Docker Compose Down: What Gets Removed, and What Stays

Running docker compose down is a teardown, not a pause. It stops and removes the project’s service containers and Compose-managed networks. By default, it leaves volumes and images alone.

That distinction matters most when your stack stores database or application data in volumes. The command is usually safe for recreating containers, but adding -v can delete data you meant to keep.

Choose the command based on what you want to keep

Use stop for a temporary pause, down to remove the project’s containers and networks, and down -v only when you intentionally want to remove Compose-managed volume data.

Goal	Command	Result
Pause services and keep their containers	docker compose stop	Containers stop but remain; resume them with docker compose start.
Tear down the project	docker compose down	Service containers and Compose-managed networks are removed.
Tear down and remove Compose-managed volumes	docker compose down -v	Containers, networks, and applicable volumes are removed.
Recreate and start services	docker compose up -d	Compose creates or recreates containers as needed and starts the services.

If you’re deciding what happens after startup, how docker compose up -d handles detached startup and container recreation explains that side of the lifecycle.

The important difference: containers versus data

A container is a runtime instance of a service. A volume is separate storage that a container can use. Removing a database container does not necessarily remove the volume holding the database files.

With plain docker compose down, named volumes are kept. Afterward, docker compose up -d can create new containers that reuse those named volumes. This is why a normal teardown and recreation can preserve database data.

The -v option changes that behavior:

docker compose down -v

It removes named volumes declared in the Compose file and anonymous volumes attached to the project’s containers. Treat it as a data-removal operation, not as a more thorough version of a routine restart.

External volumes are different: they are managed outside the Compose project and aren’t removed by down. Images also remain after plain down. If your goal is to remove service images too, Compose provides --rmi local and --rmi all; use those only when image cleanup is part of the task.

Anonymous volumes have a gotcha. Plain down keeps them, but because they don’t have a stable name for automatic reuse, a later up does not automatically remount the same anonymous volume. If data must persist predictably between container recreations, use a named volume or an explicit bind mount.

A cautious teardown workflow

Before removing anything—especially on a remote or shared server—confirm which Compose project you’re targeting and inspect its services:

cd /path/to/app
docker compose ps
docker compose down

The command operates on the Compose project identified by the configuration and project name. If you have several stacks on one host, check the working directory and Compose file before running it. docker compose ps gives you a chance to catch a wrong-project mistake before teardown.

When you’re ready to start the project again:

docker compose up -d

If you want to inspect a running service before deciding what to do, you can use docker exec to run a command in an existing container. That’s a different operation from tearing down the Compose project.

Options that make teardown broader

A few flags change what Compose cleans up:

docker compose down --remove-orphans
docker compose down --rmi local
docker compose down --rmi all
docker compose down --timeout 30

--remove-orphans also removes containers associated with the project whose services are no longer defined in the current Compose configuration. The --rmi options remove service images: local applies to images without a custom tag, while all removes images used by the project’s services. --timeout sets how long Compose allows containers to shut down before teardown proceeds.

These options can be combined, but don’t make a destructive combination your default. For example, docker compose down -v --remove-orphans --rmi all removes volumes as well as containers, networks, orphan containers, and service images. Use that only for an intentional cleanup where you understand what data will be lost.

Stop, down, or restart?

Use docker compose stop when you want to pause services and later resume the same containers with docker compose start. Use docker compose down when you want to remove containers and project networks, then recreate them later with docker compose up -d.

If you only need to restart running service containers, docker compose restart is another option. Keep in mind that a restart doesn’t apply Compose configuration changes such as updated environment variables; recreating with up is the relevant workflow when configuration has changed.

A practical default is simple: use plain docker compose down for a teardown that should preserve named-volume data. Add -v only when deleting that data is intentional, and use stop when you want to keep the existing containers.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.