How to Clean Up Docker Without Deleting Stopped Containers

Last updated on October 23rd, 2026 at 12:44 pm

The safest Docker cleanup starts by separating build cache from containers. A broad cleanup command can delete every stopped container, so it is important to inspect disk use and choose the narrowest command that solves the problem.

Why it happens

Stopped containers still matter. They may preserve configuration or data stored in their writable layers. A command that removes stopped containers can therefore cause real loss even when named volumes remain untouched.

Docker also stores build cache, unused image layers, containers, networks, and volumes. These are different resource types, and each cleanup command targets a different set.

A safer cleanup process

1. Inspect usage first.

   docker system df

   For more detail, use:

   docker system df -v

2. List all containers, including stopped ones.

   docker ps -a

3. Remove only unused build cache.

   docker builder prune

   Read the confirmation summary before accepting it.

4. Optionally remove dangling images.

   docker image prune

   The default image-prune operation targets dangling images; inspect the prompt and retained container references before proceeding.

5. Measure again.

   docker system df

Commands to treat carefully

docker system prune removes stopped containers, unused networks, dangling images, and unused build cache. If all containers are stopped, they are all candidates for removal.

docker system prune -a is broader because it can also remove unused tagged images. Adding --volumes expands the risk to unused volumes.

Cause: choosing a broad command because Docker reports large disk use. Fix: identify whether the space comes from build cache, images, containers, or volumes, then clean only that resource type.

Common mistake

Do not assume that preserving named volumes preserves everything. Data written only inside a container’s writable layer disappears when that container is removed.

Choose the builder you actually use

If builds use a separate Buildx builder, inspect that builder before pruning; its cache can differ from the default builder cache. Rebuilding cache usually costs time rather than application data. Containers, volumes, and writable layers require a separate retention decision.

Start with docker system df, preserve stopped containers unless their removal is intentional, and use the narrowest cleanup command available. The concrete next action is to inspect Docker’s storage report before confirming any prune operation.

Reference: Docker pruning documentation.

Tags:

• cli
• command
• Development
• Docker