Delete Docker Images: rmi for One, prune for the Pile You Forgot About

To delete a specific Docker image, use docker rmi <image> (short for remove image). To clean up the accumulated junk - dangling and unused images silently eating your disk - use docker image prune. The two answer different needs: rmi when you know the image you want gone, prune when you just want your disk back. The thing to know before you run either: you cannot delete an image while a container is using it, and prune has an aggressive -a mode that removes more than you might expect.

Docker disk usage grows quietly. Every build leaves layers, every pull leaves an image, and months later docker system df shows tens of gigabytes you never consciously kept. Knowing rmi from prune is how you get it back without deleting something you needed.

Table of contents

• Deleting a specific image with rmi
• Why it says image is being used
• Reclaiming space with prune
• The bigger cleanup: system prune
• A safe cleanup routine
• How this fits the rest of the stack
• FAQ

Deleting a specific image with rmi

docker rmi nginx:latest          # by name and tag
docker rmi 3f8a4b2c1d9e          # by image ID (first few chars is enough)
docker images                    # list images to find what to delete

docker rmi (or the newer docker image rm) removes one or more images you name. List images first with docker images to see names, tags, and IDs, then remove the ones you want.

If an image has several tags pointing at it, rmi with a tag just removes that tag - the image itself stays until its last tag is gone. To force removal regardless, add -f:

docker rmi -f 3f8a4b2c1d9e

Use -f with care. It will remove an image even if a stopped container references it, which can leave that container unable to restart. The safe habit is to remove the containers first, then the image - which the next section covers.

Why it says image is being used

The most common rmi failure:

Error response from daemon: conflict: unable to delete <image>
(cannot be forced) - image is being used by running container

You cannot delete an image that a container - even a stopped one - depends on. The image is the container’s filesystem template; removing it would leave the container broken. Docker refuses to do it.

The fix is to deal with the container first:

docker ps -a                     # find containers using the image
docker rm <container>            # remove a stopped container
docker rm -f <container>         # force-remove a running one
docker rmi <image>               # now the image will delete

So the order is containers first, then image. If you just want everything related to an image gone, remove its containers, then the image. Trying to force the image out from under a live container is the wrong direction - stop and remove the container, and the image deletes cleanly.

Reclaiming space with prune

When you do not care about specific images and just want disk back, prune is the tool. Start with the safe version:

docker image prune          # removes only DANGLING images

Dangling images are layers with no tag - leftovers from rebuilds, where a new build took the tag and orphaned the old layers. Removing them is safe; nothing references them. This alone often frees several gigabytes.

The aggressive version removes more:

docker image prune -a       # removes ALL images not used by a container

-a deletes every image that no container is currently using - including tagged images you pulled but are not running right now. That can be a lot, and re-pulling them later takes time and bandwidth. Use plain prune for routine cleanup and -a only when you deliberately want a near-empty image store. Both ask for confirmation before deleting, so read what they propose.

The bigger cleanup: system prune

Images are one of several things Docker accumulates. To see the whole picture:

docker system df            # disk used by images, containers, volumes, cache

This shows where the space actually went - often the build cache is the biggest culprit, not images. To clean everything reclaimable in one command:

docker system prune         # dangling images, stopped containers, unused networks, build cache
docker system prune -a --volumes   # also unused images and volumes - aggressive

docker system prune is the periodic maintenance command - run it every so often to keep Docker from silently filling the disk. The -a --volumes form is powerful and dangerous: --volumes removes unused volumes, which can contain data you meant to keep. Never run the volumes variant without knowing exactly which volumes are in play, because a volume you thought was unused might hold your only copy of a database.

A safe cleanup routine

Put it together into a routine you can run without anxiety:

docker system df                 # 1. see what is using space
docker ps -a                     # 2. review containers before removing
docker container prune           # 3. remove stopped containers
docker image prune               # 4. remove dangling images (safe)
docker system df                 # 5. confirm the space came back

That sequence reclaims the easy wins - stopped containers and dangling images - without touching anything a running service needs or any tagged image you might want. It is the version to run on a schedule.

Escalate to docker image prune -a or docker system prune -a only when the safe routine did not free enough and you have looked at what will be removed. The golden rule with Docker cleanup: the safe commands (prune without -a, prune without --volumes) are reversible in effect - you can re-pull or rebuild. The aggressive ones can take data. Start safe, escalate deliberately.

How this fits the rest of the stack

Managing Docker disk by hand is a chore that scales badly - every server you run accumulates the same pile. A platform that builds and runs your images handles the layer lifecycle for you, so image cleanup stops being a thing you remember to do and becomes something the build system already handles. The RunxBuild hosting calculator lays out the service, database, storage, and bandwidth as separate line items, and the RunxBuild dashboard is where the team watches deploys, logs, and restarts as they happen.

Useful related references:

• Docker Desktop vs Rancher Desktop vs colima: Which One Should You Use in 2026?
• Docker Multistage Build: Smaller Images, Separate Build and Runtime
• Docker Secret: The Runtime Pattern, the Build-Time Pattern, and the One Mistake That Ships Them to the Image
• Docker services on RunxBuild

FAQ

How do I delete a Docker image?

Use docker rmi <image> with the image name and tag or its ID - docker rmi nginx:latest or docker rmi 3f8a4b2c. List images first with docker images to find what to remove. You cannot delete an image while a container is using it.

Why can’t I delete a Docker image?

Because a container - even a stopped one - is using it as its filesystem template. Remove the container first with docker rm <container> (or docker rm -f to force a running one), then delete the image. Forcing the image out from under a live container is the wrong approach.

What is the difference between docker image prune and prune -a?

docker image prune removes only dangling images - untagged leftover layers from rebuilds, which is always safe. docker image prune -a removes every image not currently used by a container, including tagged images you pulled but are not running. Use -a only when you want a near-empty image store.

How do I free up disk space used by Docker?

Run docker system df to see what is using space, then docker system prune to remove dangling images, stopped containers, unused networks, and build cache in one step. Avoid the -a --volumes variant unless you are certain, since --volumes can delete data you meant to keep.

What are dangling Docker images?

They are image layers with no tag, left behind when a new build takes over a tag and orphans the previous layers. Nothing references them, so docker image prune removes them safely, often reclaiming several gigabytes.