Understanding the mess is the first step to understanding the cleanup.

Every time you build an image, run a container, or set up a network, Docker creates real objects that persist on your disk, taking up real storage space, until something explicitly removes them. Stopping a container doesn’t delete it. Building a newer version of an image doesn’t automatically erase the older version. Removing a container doesn’t necessarily clean up a network it was using. Left unattended, all of this simply accumulates, month after month, often without anyone noticing until disk space starts running unexpectedly low.

This isn’t a flaw in Docker — it’s a deliberate choice. Automatically deleting things the moment they’re no longer actively in use would be dangerous, since a stopped container or an older image might still be needed again soon. Instead, Docker leaves the decision of what to clean up entirely in your hands, and a system-wide prune is the broad, sweeping tool for making that decision across everything at once.

By default, a system prune targets four specific categories of leftover object.

A system-wide prune isn’t one narrow cleanup action — it’s a combined sweep across several different kinds of object at once, each of which is covered individually, in more detail, in the chapters that follow.

Notice what’s deliberately missing from this list: images that are still tagged and simply unused, and any Docker-managed volumes. Both of these are treated as more sensitive than the categories above, and by default, a standard system prune leaves them completely untouched, requiring an extra, explicit choice to include them, which is covered fully in Chapter 6.

One of the most common sources of accumulated clutter, and a term worth understanding properly.

Every time an image is rebuilt with the same name, the previous version of that image doesn’t disappear — it simply loses its name, becoming what’s called a dangling image: a real set of layers still sitting on disk, but no longer referenced by any meaningful tag, effectively an orphan. It still exists, still takes up space, but has become genuinely difficult to identify or use intentionally, since it no longer has a memorable name attached to it.

flowchart LR
    A["Image built as myapp:latest"] -->|"rebuilt again"| B["New image becomes myapp:latest"]
    A -.->|"old tag reassigned"| C["Original layers remain, now untagged"]
    C -->|"becomes"| D["Dangling Image"]
    style D fill:#fef2f2,stroke:#dc2626
        

Over months of regular development, rebuilding the same image repeatedly, dangling images can accumulate into a genuinely significant amount of wasted disk space, often without anyone noticing, since they don’t show up prominently by name the way properly tagged images do.

Every container you’ve ever run and stopped is potentially still sitting on your disk right now.

As explored in dedicated detail elsewhere, stopping a container never deletes it — the container remains present, along with its own internal filesystem, ready to be started again at any time. This is genuinely useful, but it also means that every quick test, every short-lived experiment, and every container you meant to remove but forgot about can quietly accumulate over time, each one holding onto its own small (or sometimes not-so-small) slice of disk space.

This is precisely why a system prune is such a broadly useful habit for anyone who frequently experiments with short-lived containers: the very act of trying something out and stopping it afterward is exactly what generates the clutter this cleanup targets.

Two less visible, but still meaningful, sources of accumulated leftovers.

Custom networks created for a specific project or set of services don’t automatically disappear once every container using them has been removed. They remain defined, sitting quietly on the system, until something explicitly removes them. A system prune identifies networks with no currently connected containers and clears them away as part of its sweep.

Build cache is a different, but related, kind of accumulation. When an image is built, Docker saves the intermediate results of each build step so that a future build of the same image can reuse those results instead of redoing the work from scratch, dramatically speeding up repeated builds. Over time, though, especially across many different projects, this cache can grow to occupy a very substantial amount of disk space, all of it entirely invisible unless you specifically go looking for it.

Not everything unused is treated equally — some things are considered too risky to remove automatically.

A standard system prune is deliberately conservative about two particular categories: images that still have a meaningful tag but simply aren’t currently being used by any container, and Docker-managed volumes. Both require an extra, explicit choice before they’re included in the cleanup, precisely because removing them carries a meaningfully higher risk of losing something genuinely important.

A system prune doesn’t act silently or instantly — it asks first.

Because a system prune can remove a genuinely large number of objects in one single sweep, it’s designed to first describe exactly what categories of object it’s about to remove and ask for explicit confirmation before doing anything irreversible. This pause exists specifically to give a moment for a second thought before a potentially large, one-way cleanup actually happens.

This confirmation step can be skipped for automated scripts and scheduled maintenance tasks where a person isn’t available to respond, but doing so removes an important safety net, and should only be done once you’re genuinely confident in exactly what’s being cleaned up.

A system-wide sweep isn’t the only cleanup option — sometimes a narrower tool is the better fit.

Docker also offers more targeted cleanup actions that focus on just one category of object at a time — removing only unused containers, only unused images, or only unused networks, without touching anything else. A system-wide prune is essentially a convenient bundle of all of these targeted actions performed together in one sweep.

A targeted cleanup is often the safer, more predictable choice when you have a specific concern in mind, such as “my build cache seems huge,” while a system-wide prune is better suited to a general, periodic tidy-up when you simply want everything unused cleared away at once.

Cleaning up unused Docker objects is a routine part of maintaining any machine that uses Docker regularly.

A short checklist for pruning safely and effectively.

Regular cleanup is a common, practical part of maintaining Docker-based systems across many kinds of teams.

No. As explained in Chapter 4, only stopped (exited) containers are ever removed; a running container is always considered actively in use and left alone.

As covered in Chapter 3, it’s an older set of image layers left behind after rebuilding an image under the same name, no longer referenced by any meaningful tag.

No. As explained in Chapter 6, volumes are excluded by default because of the serious risk of losing important data, and must be included through a separate, deliberate choice.

No — as noted throughout Chapters 6 and 10, a prune is a genuine, permanent removal, which is exactly why the confirmation step in Chapter 7 matters so much.

As discussed in Chapter 8, a system-wide prune sweeps across all default categories at once, while a targeted cleanup focuses narrowly on just one, such as only unused images.

As explained in Chapter 5, Docker keeps intermediate build results around to speed up future builds, and this cache accumulates steadily the more images you build over time.

A system-wide prune is Docker’s broad, convenient cleanup sweep, clearing away stopped containers, dangling images, unused networks, and unused build cache — the everyday clutter that accumulates naturally the more Docker is used. It deliberately leaves tagged-but-unused images and volumes alone by default, since removing either carries a real risk of losing something genuinely needed, and it always asks for confirmation before proceeding. Used thoughtfully and regularly, it’s one of the simplest ways to keep a Docker-using machine running smoothly instead of slowly filling up with forgotten leftovers.