Docker Compose Down vs Stop vs Kill

I ran docker compose stop expecting the stack to fully disappear. A few seconds later, docker compose ps still listed every container and the default network was still there — nothing had been removed, just stopped. That's not a bug in Compose; it's a genuinely different command from down, and I'd been treating the two as interchangeable.

What each command actually tears down

Command	Containers	Default network	Named volumes
docker compose stop	Stopped, not removed	Left in place	Left in place
docker compose down	Removed	Removed	Left in place
docker compose down -v	Removed	Removed	Deleted
docker compose kill	Force-stopped immediately, not removed	Left in place	Left in place

stop and down both send SIGTERM first, not SIGKILL

Both docker compose stop and docker compose down shut a container's main process down the same way: they send SIGTERM, a signal a well-behaved process can catch to flush data, close connections, and exit cleanly. Docker then waits — by default 10 seconds — for the process to actually exit. Only if it hasn't exited by then does Docker escalate to SIGKILL, which cannot be caught, blocked, or ignored; the process ends immediately, mid-whatever-it-was-doing.

docker compose kill skips straight to that last step. It sends SIGKILL on the first try, with no SIGTERM, no grace period, and no chance for the app to save anything in flight.

The container that wouldn't stop

One background-worker container on this homelab ignored docker compose stop outright — the process didn't have a SIGTERM handler at all, so the signal did nothing, and after the usual 10-second wait Docker escalated to SIGKILL on its own and the container went down anyway, just ten seconds slower than expected. That's the mechanism working as designed: stop always eventually forces the issue if the grace period runs out. The only time it's worth reaching for docker compose kill directly is when you already know a container won't respond to SIGTERM — an unresponsive process, a container stuck in a bad state — and you'd rather skip the guaranteed 10-second wait than let stop discover the same thing on a timer.

When kill is actually the right call

Reach for docker compose kill over stop specifically when a container is already known to be unresponsive — hung, deadlocked, or ignoring signals from a previous stop attempt — and waiting out another grace period has no upside. For anything with in-flight state worth protecting (a database mid-write, a job queue with an active task), always prefer stop or down and let the SIGTERM grace period do its job; kill gives the process zero chance to clean up.

A CI script or automation job is the other legitimate case: if a pipeline step needs to tear a test stack down as fast as possible and nothing in it holds state worth preserving, skipping the 10-second grace period on purpose is a reasonable trade of a small time saving for a shutdown that's slightly less clean — as long as that's a deliberate choice, not a default reached for out of impatience on a stack that does hold real data.

down -v: the one command that also touches volumes

Of these four, only down -v can delete data — it removes every named volume declared in the compose file, on top of everything down already does. That's a storage decision, not a shutdown-signal decision, and it deserves its own deep dive rather than a repeat here: see the volumes and backups guide for exactly what a named volume holds, how to back one up, and how close a down -v came to costing a year of data on this same homelab.

Decision table

Situation	Command
Pausing a stack, plan to restart it soon, want fastest possible restart	docker compose stop
Done with a stack for now, want containers and network cleaned up but data kept	docker compose down
Genuinely done with a stack and its data, want a clean slate	docker compose down -v
Container is unresponsive and a stop attempt already timed out	docker compose kill
Database or anything mid-write needs to shut down	docker compose stop with an adequate stop_grace_period — never kill

Which network a container rejoins on the next up is a separate decision covered in Docker Compose networking, and whether it restarts automatically afterward depends on the restart policy — shutdown method, networking, and restart policy are three independent choices, not one setting.

The bottom line

stop pauses, down removes containers and the network but keeps data, down -v is the only one of the four that can delete data, and kill is the only one that skips the graceful SIGTERM grace period entirely. Reach for kill only when a container is already known to be unresponsive — for everything else, stop or down give an app the same 10-second chance to shut down cleanly before Docker forces the issue anyway.

Frequently asked questions

Does docker compose stop remove the network?

No. docker compose stop only stops the containers' processes — the containers themselves, the default network, and any volumes are all left in place. Use docker compose down to remove the containers and network too.

What signal does docker compose kill send?

SIGKILL, immediately, with no prior SIGTERM and no grace period. The process is terminated on the spot with no chance to clean up or save in-flight data.

Is docker compose down -v safe to run?

Only if you're certain about every named volume declared in that compose file — down -v deletes all of them permanently, with no confirmation prompt. It's the only one of stop/down/down -v/kill that can lose data.

What's the difference between docker compose stop and docker compose down?

stop only stops the containers' processes and leaves the containers, network, and volumes in place, ready to start again. down additionally removes the containers and the default network, though it still leaves named volumes untouched unless -v is added.