How to remove all stopped containers with docker container prune

Clean up your Docker host without losing your mind. If you’ve ever stared at a long list of containers, many of them stopped but not removed, you know how quickly disk space and memory can start nagging you. The good news is there’s a simple, reliable way to reclaim those resources: prune the stopped containers.

What’s the right command here?

If you’re faced with a multiple-choice style reminder, the correct choice is docker container prune. This command specifically targets containers that aren’t running. It’s a focused cleanup tool—think pruning a hedge, not reshaping your entire garden.

Let me explain why this one is the right move and what the others aren’t doing.

• docker container prune: the exact job you want

• What it does: it removes all containers that are not running. It’s a surgical cleanup, not a full hammer-down delete of every container you’ve ever created.

• What you’ll see: when you run it, Docker asks for confirmation. You get a chance to pause and double-check before anything gets deleted.

• How to skip the prompt if you’re automating or confident: docker container prune -f (or --force). It’s a timesaver when you know you’re cleaning up a sandbox or a disposable test environment.

• Why the other options aren’t right for this task

• docker rm -a: there’s no -a flag for docker rm. If you try it, you’ll get an error, and nothing gets cleaned up. You can remove specific containers by name or ID with docker rm container_name, but you’d be picking and choosing one by one—not a bulk cleanup of stopped containers.

• docker clean containers: not a real command. Docker’s CLI doesn’t recognize this, so you’ll get a “command not found” vibe rather than a clean sweep.

• docker remove --all: also not valid. The canonical removal commands are docker rm [container] or docker container prune for bulk removal of stopped containers. There’s no --all switch to make a blanket removal of all containers, regardless of state, through a single command.

Now that you know what to run, here’s the practical why and how.

A quick map of why prune matters

• Speed and space: stopped containers linger in the background, consuming disk space and occupying ID slots. Pruning them frees up space and makes the system more responsive.

• Lower cognitive load: fewer containers on the list means you can focus on the ones you actually want to run.

• Safer experimentation: in development environments, you often spin up lots of temporary containers. Pruning keeps the testbed honest and easier to manage.

What happens under the hood

• Stopped vs. running: docker container prune deletes only containers that aren’t currently running. If a container is in a paused or stopped state, it can be removed; if it’s still active, it stays put.

• An intentional wipe: it won’t touch images, networks, or volumes (not by default). This is by design to prevent accidentally wiping something you still need.

A little demo to make it click

If you want to see it in action, here’s a tiny, harmless walk-through you can try on a test host:

• Create a quick, short-lived container:

• docker run --name demo-nginx -d nginx

• Stop it to make it a candidate for pruning:

• docker stop demo-nginx

• Check what’s around:

• docker ps -a

• Now prune:

• docker container prune

• Confirm (you’ll be prompted). After that, the demo-nginx container should be gone if it’s stopped.

• Quick verification:

• docker ps -a should list only any other containers that are running or not yet cleaned up.

If you want to skip the prompt during the demo, run:

• docker container prune -f

A couple of practical tips you’ll actually use

• Be mindful of data in containers

• If your container’s writable layer holds important data (not recommended for production, but it happens in development), prune will remove that container along with its writable layer. If the data is important, consider using a volume for persistence. Volumes tend to survive container removal, which is often exactly what you want for data you need to keep.

• Volumes and images: what gets pruned when

• By default, docker container prune will not touch volumes. If you ever want to clean up unused volumes as well, you’d use docker system prune --volumes, but that’s a broader cleanup that touches more than just containers. Use it with care, especially on shared hosts.

• Images aren’t touched by docker container prune unless they’re dangling (not used by any container). If you want a wider cleanup that also targets unused images, you’d look at docker image prune or docker system prune with appropriate flags. Again: know what you’re removing to avoid surprises.

Connecting this to the bigger picture

• The Docker CLI is built to move fast and stay predictable. Pruning is a reminder that you can keep a tidy environment without overthinking it.

• Clean hosts help you test and iterate more smoothly. You want to be able to pull a new image, spin up a container, and not be reckoning with “this old thing” that’s been hugging your disk for weeks.

• In real-world workflows, you’ll often loop through a simple pattern: run -> stopped -> prune -> verify. It’s like cleaning a workspace between tasks—nothing fancy, just efficient.

A couple of caveats worth knowing

• Don’t prune on a production host without a plan

• Production environments tend to have containers tied to volumes, data stores, or long-running services. A blanket prune can interrupt those services or erase data you didn’t intend to lose.

• Schedule wisely

• If you frequently generate a lot of stopped containers, consider a small, regular cleanup window or a scripted job that prunes with a force flag after you’ve validated there’s nothing you need to preserve.

A few extra clean-up ideas

• For routine housekeeping, you might also explore:

• docker system prune: a broader sweep that can remove unused containers, networks, images, and optionally volumes. It’s powerful, so use with awareness of what each item means for your environment.

• docker image prune: removes dangling images that aren’t referenced by any container. Handy when you’re onboarding new images and want to reclaim space tied up by stale layers.

• docker volume prune: frees up unused volumes when you know a set of volumes aren’t needed anymore.

Bringing it home

So, when you’re cleaning up a host with a mix of running and stopped containers, the command you’ll reach for is docker container prune. It’s precise, safe by default (thanks to the confirmation prompt), and fast enough to keep your work environment nimble. For those moments when you need a tougher cleanse, you can tack on -f to skip the prompt, but always pause to confirm what’s about to go away.

If you’re exploring Docker as part of a broader skill set, this little cleanup habit pays big dividends. It keeps your environment lean, minimizes surprises, and reinforces a practical, hands-on understanding of container lifecycle—from creation to stop to cleanup. And yes, a tidy host makes the next project feel a little less messy and a lot more doable. After all, in tech as in life, a clean space is often the first step to clear thinking.