{"id":16952,"date":"2023-04-24T03:09:18","date_gmt":"2023-04-24T01:09:18","guid":{"rendered":"https:\/\/contabo.com\/blog\/?p=16952"},"modified":"2026-06-18T19:43:05","modified_gmt":"2026-06-18T17:43:05","slug":"how-to-remove-docker-volumes-images-and-containers","status":"publish","type":"post","link":"https:\/\/contabo.com\/blog\/how-to-remove-docker-volumes-images-and-containers\/","title":{"rendered":"How to Remove Docker Images, Containers, Volumes, and Networks\u00a0"},"content":{"rendered":"\n<figure class=\"wp-block-image size-large\"><img decoding=\"async\" src=\"https:\/\/contabo.com\/blog\/wp-content\/uploads\/2023\/04\/blog-head_how2-remove-docker-images-containers-and-volumes.jpg.webp\" alt=\"How To Remove Docker Volumes and Images and Containers - Head Image\"\/><\/figure>\n\n\n\n<div style=\"height:30px\" aria-hidden=\"true\" class=\"wp-block-spacer\"><\/div>\n\n\n\n<p>Docker makes it easy to spin up services fast, but that convenience comes with a side effect: unused images, stopped containers, stale volumes, and orphaned networks pile up quietly and consume disk space. This guide covers every practical method to remove Docker images, remove Docker volumes, remove Docker containers, and clean up networks, whether you need a targeted one-liner or a full system wipe.&nbsp;<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"h-quick-cleanup-with-docker-system-prune\"><strong>Quick Cleanup with docker system prune<\/strong>\u00a0<\/h2>\n\n\n\n<p>Before targeting individual resources, it is worth knowing that Docker ships with a single command capable of reclaiming a significant amount of space in one shot: docker system prune. This is the fastest path to a clean environment when you are not concerned about being selective.&nbsp;<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"h-default-prune-vs-full-prune\"><strong>Default Prune vs Full Prune<\/strong>\u00a0<\/h3>\n\n\n\n<p>Running docker system prune without any flags removes stopped containers, dangling images (images not tagged and not referenced by any container), unused networks, and the build cache. It does not touch volumes by default, and it does not remove images that are simply unused but still tagged.&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker system prune\u00a0<\/code><\/pre>\n\n\n\n<p>Docker will prompt for confirmation before proceeding. If you want to skip the prompt in automated scripts, add the -f or &#8211;force flag.&nbsp;<\/p>\n\n\n\n<p>To perform a more thorough docker cleanup that removes all unused images, not just dangling ones, and also removes unused volumes, use the combined flags:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker system prune -a --volumes\u00a0<\/code><\/pre>\n\n\n\n<p>This is the most complete single-command option available and covers nearly every category of unused Docker resource at once. Use it with care on shared hosts or production machines, since it removes every image not currently attached to a running container.&nbsp;<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"h-using-filters-with-prune-commands\"><strong>Using Filters with Prune Commands<\/strong>\u00a0<\/h3>\n\n\n\n<p>Most prune commands accept a &#8211;filter flag that lets you scope the cleanup by label or creation time. This is documented in the official docker system prune documentation and applies across docker image prune, docker container prune, docker volume prune, and docker network prune as well.&nbsp;<\/p>\n\n\n\n<p>For example, to remove only resources older than 24 hours:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker system prune --filter \"until=24h\"\u00a0<\/code><\/pre>\n\n\n\n<p>You can also filter by label when your workflow assigns labels to images or containers:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker system prune --filter \"label=environment=staging\"\u00a0<\/code><\/pre>\n\n\n\n<p>The same &#8211;filter syntax works with docker images &#8211;filter and docker ps &#8211;filter when you want to list or act on specific subsets before pruning. For instance, docker images &#8211;filter dangling=true lists only untagged images, and docker ps &#8211;filter status=exited lists only stopped containers.&nbsp;<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"h-removing-docker-volumes\"><strong>Removing Docker Volumes<\/strong>\u00a0<\/h2>\n\n\n\n<p>Volumes are intentionally excluded from most automatic cleanup commands because they store persistent data. Docker does not remove a volume when its associated container is deleted unless you explicitly tell it to. This means volumes can accumulate over time, especially in active development environments.&nbsp;<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"h-list-and-inspect-volumes\"><strong>List and Inspect Volumes<\/strong>\u00a0<\/h3>\n\n\n\n<p>Before removing anything, get a clear picture of what exists. The docker volume ls command lists all volumes on the host:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker volume ls\u00a0<\/code><\/pre>\n\n\n\n<p>To understand what docker volumes are in more detail: volumes are directories managed by Docker, stored outside the container&#8217;s writable layer. They survive container restarts and removals, which is exactly what makes them useful for databases and persistent application state, but also what makes them easy to forget about.&nbsp;<\/p>\n\n\n\n<p>To list only unused or docker dangling volumes, those not currently mounted by any container, use the filter flag:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker volume ls -f dangling=true\u00a0<\/code><\/pre>\n\n\n\n<figure class=\"wp-block-image size-large\"><img decoding=\"async\" src=\"https:\/\/contabo.com\/blog\/wp-content\/uploads\/2023\/04\/image-22.png.webp\" alt=\"\"\/><\/figure>\n\n\n\n<p>This gives you a focused list of candidates for cleanup without touching anything in active use.&nbsp;<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"h-remove-a-specific-volume\"><strong>Remove a Specific Volume<\/strong>\u00a0<\/h3>\n\n\n\n<p>Once you have identified the volume you want to delete, the docker volume rm command removes it by name:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker volume rm my_volume\u00a0<\/code><\/pre>\n\n\n\n<p>You can remove multiple volumes in a single call by providing additional names:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker volume rm volumeone volumetwo volume_three\u00a0<\/code><\/pre>\n\n\n\n<p>To docker remove a volume by name, you need to know the exact name as it appears in the docker volume ls output. Anonymous volumes have auto-generated names; named volumes use whatever name was defined in the docker-compose.yml or passed at runtime.&nbsp;<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"h-remove-all-unused-volumes\"><strong>Remove All Unused Volumes<\/strong>\u00a0<\/h3>\n\n\n\n<p>To remove all volumes not currently in use by a container, docker volume prune is the right command:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker volume prune\u00a0<\/code><\/pre>\n\n\n\n<p>This removes every volume not attached to at least one container, whether running or stopped. It will prompt for confirmation before proceeding. To prune volumes without a prompt, add the &#8211;force flag:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker volume prune --force\u00a0<\/code><\/pre>\n\n\n\n<p>If you want to docker remove all volumes unconditionally, including those attached to stopped (but not removed) containers, you need to remove those containers first and then run docker volume prune. There is no native Docker command to force-delete every volume without first stopping and removing associated containers.&nbsp;<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"h-remove-a-volume-that-is-in-use\"><strong>Remove a Volume That Is in Use<\/strong>\u00a0<\/h3>\n\n\n\n<p>If you try to docker remove a volume that is in use by a running or stopped container, the command will fail with an error stating the volume is in use:&nbsp;<\/p>\n\n\n\n<p>Error response from daemon: remove myvolume: volume is in use &#8211; [containerid]&nbsp;<\/p>\n\n\n\n<p>To resolve a docker volume rm error where the volume is in use, you need to remove the container first:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker rm container_id\u00a0<\/code><\/pre>\n\n\n\n<p>Then retry:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker volume rm my_volume\u00a0<\/code><\/pre>\n\n\n\n<p>If the container is running, stop it first:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker stop container_id docker rm container_id docker volume rm my_volume\u00a0<\/code><\/pre>\n\n\n\n<p>There is no &#8211;force option for docker volume rm that overrides the in-use check. The only path forward is removing the dependent container first.&nbsp;<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"h-remove-containers-and-associated-volumes-together\"><strong>Remove Containers and Associated Volumes Together<\/strong>\u00a0<\/h3>\n\n\n\n<p>When you delete a container, Docker does not automatically remove its associated volume unless you pass the -v flag. This is the docker rm with volumes option:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker rm -v container_name\u00a0<\/code><\/pre>\n\n\n\n<p>This removes the container and any anonymous volumes attached to it. Named volumes are not removed by this flag, even with -v, because named volumes are considered managed resources that may be intentionally shared across containers. If you want to also remove a named volume, you must specify it separately with docker volume rm.&nbsp;<\/p>\n\n\n\n<p>This distinction matters: docker rm does remove volumes only for anonymous volumes. Named volumes persist until you explicitly remove them.&nbsp;<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"h-removing-docker-images\"><strong>Removing Docker Images<\/strong>\u00a0<\/h2>\n\n\n\n<p>Images are the largest contributors to Docker disk usage. Every docker pull, docker build, and docker-compose up can add layers to your local image store. Regular cleanup with docker rmi and docker image prune keeps this under control.&nbsp;<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"h-remove-a-specific-image\"><strong>Remove a Specific Image<\/strong>\u00a0<\/h3>\n\n\n\n<p>To docker remove an image by name or tag, use the docker image rm command or its shorthand docker rmi:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker rmi ubuntu:22.04\u00a0<\/code><\/pre>\n\n\n\n<p>You can also reference images by their image ID, which you can find by running docker images -a:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker images -a docker rmi a1b2c3d4e5f6\u00a0<\/code><\/pre>\n\n\n\n<p>If you want to delete multiple images at once, list their IDs or tags separated by spaces:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker rmi imageone imagetwo image_three\u00a0<\/code><\/pre>\n\n\n\n<p>The docker rmi command and docker image rm are functionally identical. Either works for the docker delete image workflow.&nbsp;<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"h-remove-dangling-images\"><strong>Remove Dangling Images<\/strong>\u00a0<\/h3>\n\n\n\n<p>Docker dangling images are image layers that have lost their association with a tagged image, typically because a new build replaced an older version and the old layers were left behind. They appear as &lt;none&gt;:&lt;none&gt; in the docker images output.&nbsp;<\/p>\n\n\n\n<p>To list dangling images:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker images -f dangling=true\u00a0<\/code><\/pre>\n\n\n\n<p>To remove dangling images in Docker, use docker image prune:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker image prune\u00a0<\/code><\/pre>\n\n\n\n<p>This targets only the untagged, unreferenced layers and is safe to run regularly. It will ask for confirmation before deleting anything.&nbsp;<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"h-remove-all-unused-images\"><strong>Remove All Unused Images<\/strong>\u00a0<\/h3>\n\n\n\n<p>To go further and remove all images not referenced by at least one container (running or stopped), use docker image prune -a:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker image prune -a\u00a0<\/code><\/pre>\n\n\n\n<p>This is considerably more aggressive than the default prune. It removes every image your system has pulled that is not currently in use, so any future docker run command referencing those images will require a fresh pull. Use this when reclaiming space on a build server or CI runner between jobs.&nbsp;<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"h-force-remove-an-image-in-use-by-a-stopped-container\"><strong>Force-Remove an Image in Use by a Stopped Container<\/strong>\u00a0<\/h3>\n\n\n\n<p>If a docker remove image operation fails because the image is still referenced by a stopped container, you have two options.&nbsp;<\/p>\n\n\n\n<p>The first is to remove the stopped container first, then remove the image:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker rm container_id docker rmi image_name\u00a0<\/code><\/pre>\n\n\n\n<p>The second is to use the &#8211;force flag to docker force remove the image regardless of stopped container references:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker rmi --force image_name\u00a0<\/code><\/pre>\n\n\n\n<p>Note that &#8211;force bypasses the reference check for stopped containers but will not forcibly remove an image that is actively in use by a running container. In that case, you must stop the container first.&nbsp;<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"h-removing-docker-containers\"><strong>Removing Docker Containers<\/strong>\u00a0<\/h2>\n\n\n\n<p>Containers are the most frequently created and discarded Docker resource. Even short-lived containers, test runs, and failed builds leave entries that accumulate quickly in the docker ps -a output.&nbsp;<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"h-remove-a-specific-container\"><strong>Remove a Specific Container<\/strong>\u00a0<\/h3>\n\n\n\n<p>The docker rm command deletes a container by name or ID. Use docker ps -a to list all containers including stopped ones:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker ps -a\u00a0<\/code><\/pre>\n\n\n\n<p>To remove a container by name:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker rm my_container\u00a0<\/code><\/pre>\n\n\n\n<p>To docker remove a container by ID:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker rm a1b2c3d4e5f6\u00a0<\/code><\/pre>\n\n\n\n<p>The docker rm command only works on containers that are not currently running. Attempting to remove a running container returns an error.&nbsp;<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"h-remove-all-stopped-containers\"><strong>Remove All Stopped Containers<\/strong>\u00a0<\/h3>\n\n\n\n<p>To clean up every container that is not currently running, docker container prune is the most direct option:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker container prune\u00a0<\/code><\/pre>\n\n\n\n<p>This removes all stopped and exited containers in one pass and prompts for confirmation. To skip the prompt:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker container prune --force\u00a0<\/code><\/pre>\n\n\n\n<p>Alternatively, you can combine docker ps filters with docker rm to target specific states. To docker remove all exited containers:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker rm $(docker ps -a -f status=exited -q)\u00a0<\/code><\/pre>\n\n\n\n<p>This approach also supports chaining multiple filters. To remove all stopped containers matching either exited status or a specific name pattern:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker rm $(docker ps -a -f status=exited -f name=test -q)\u00a0<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"h-force-remove-a-running-container\"><strong>Force-Remove a Running Container<\/strong>\u00a0<\/h3>\n\n\n\n<p>To force-remove a running container without stopping it first, pass the &#8211;force flag to docker rm:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker rm --force container_name\u00a0<\/code><\/pre>\n\n\n\n<p>This sends a SIGKILL to the container process and removes it immediately. It is equivalent to running docker stop followed by docker rm, but in a single step. Use this when a container is unresponsive or when you need to docker stop and remove a container quickly in a script.&nbsp;<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"h-auto-remove-containers-on-exit\"><strong>Auto-Remove Containers on Exit<\/strong>\u00a0<\/h3>\n\n\n\n<p>If you know a container is ephemeral, for example a test runner or a one-off script, you can instruct Docker to automatically remove the container when it exits using the &#8211;rm flag at startup:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker run --rm image_name\u00a0<\/code><\/pre>\n\n\n\n<p>The container will be removed immediately when the process inside it completes, whether it exits cleanly or with an error. This is the cleanest way to docker remove a container after stop without any manual cleanup step.&nbsp;<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"h-stop-and-remove-all-containers\"><strong>Stop and Remove All Containers<\/strong>\u00a0<\/h3>\n\n\n\n<p>To stop and remove every container on the host, combine docker stop and docker rm with the full container list:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker stop $(docker ps -a -q) docker rm $(docker ps -a -q)\u00a0<\/code><\/pre>\n\n\n\n<p>Run these two commands in sequence. The first stops all running containers, and the second removes all containers (now stopped). This is the docker remove all containers command pattern used most commonly in development environment resets.&nbsp;<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"h-removing-docker-networks\"><strong>Removing Docker Networks<\/strong><\/h2>\n\n\n\n<p>Custom Docker networks persist after the containers using them are removed. Over time, networks from old projects and abandoned Compose stacks can accumulate and interfere with new deployments.&nbsp;<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"h-remove-specific-and-unused-networks\"><strong>Remove Specific and Unused Networks<\/strong>\u00a0<\/h3>\n\n\n\n<p>To list all networks on the host:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker network ls\u00a0<\/code><\/pre>\n\n\n\n<p>In order to remove a specific network by name:\u00a0<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker network rm my_network\u00a0<\/code><\/pre>\n\n\n\n<p>Last but not least, remove all networks not currently used by at least one container, use docker network prune:\u00a0<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker network prune\u00a0<\/code><\/pre>\n\n\n\n<p>This covers the most common cleanup scenario and is safe to run alongside volume and image pruning. For a complete cleanup of all Docker resources in one pass that covers containers, images, volumes, and networks, the previously covered docker system prune -a &#8211;volumes command handles everything.&nbsp;<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"h-docker-compose-cleanup\"><strong>Docker Compose Cleanup<\/strong>\u00a0<\/h2>\n\n\n\n<p>Projects managed with Docker Compose require a slightly different cleanup approach because Compose tracks relationships between services, volumes, and networks as a unit.&nbsp;<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"h-docker-compose-down-with-volumes-and-images\"><strong>Docker Compose Down with Volumes and Images<\/strong>\u00a0<\/h3>\n\n\n\n<p>The base command to stop and remove Compose-managed containers, networks, and the default network is:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker compose down\u00a0<\/code><\/pre>\n\n\n\n<p>This does not remove volumes or images by default. To also remove volumes, add the -v flag:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker compose down -v\u00a0<\/code><\/pre>\n\n\n\n<p>The docker compose down -v command removes both anonymous volumes and named volumes defined in the Compose file&#8217;s volumes section. This is one of the key differences from docker rm -v, which only handles anonymous volumes.&nbsp;<\/p>\n\n\n\n<p>To also remove all images used by the services in the Compose file, add &#8211;rmi all:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker compose down --rmi all\u00a0<\/code><\/pre>\n\n\n\n<p>Combining both flags gives you a full teardown:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker compose down -v --rmi all\u00a0<\/code><\/pre>\n\n\n\n<p>This removes all containers, networks, named and anonymous volumes, and all associated images. It is the equivalent of a clean project reset.&nbsp;<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"h-remove-orphaned-compose-resources\"><strong>Remove Orphaned Compose Resources<\/strong>\u00a0<\/h3>\n\n\n\n<p>When you modify a docker-compose.yml file and remove a service, the containers for that service are not automatically cleaned up by subsequent docker compose down runs. They become orphaned resources.&nbsp;<\/p>\n\n\n\n<p>To include orphaned containers in the cleanup:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker compose down --remove-orphans\u00a0<\/code><\/pre>\n\n\n\n<p>This flag tells Compose to remove containers for services that are no longer defined in the current Compose file. You can combine it with -v to also clean up any volumes left behind by those removed services:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker compose down -v --remove-orphans\u00a0<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"h-clearing-the-build-cache\"><strong>Clearing the Build Cache<\/strong>\u00a0<\/h2>\n\n\n\n<p>The Docker build cache stores intermediate image layers from previous builds. On active development machines and CI systems, the cache can grow to several gigabytes quickly. Clearing it does not affect running containers or existing images, only the cached build layers.&nbsp;<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"h-docker-builder-prune-options\"><strong>Docker Builder Prune Options<\/strong>\u00a0<\/h3>\n\n\n\n<p>To docker clear the cache, use docker builder prune:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker builder prune\u00a0<\/code><\/pre>\n\n\n\n<p>This removes all dangling build cache entries (layers not referenced by any existing image). For a more thorough docker disk cleanup that removes the entire build cache, add the -a flag:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker builder prune -a\u00a0<\/code><\/pre>\n\n\n\n<p>The -a flag removes all build cache, including cache that is still referenced. This forces the next build to start completely fresh, which takes longer but guarantees a clean state.&nbsp;<\/p>\n\n\n\n<p>To filter by age, for example to remove only cache entries older than 48 hours, use:&nbsp;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker builder prune --filter \"until=48h\"\u00a0<\/code><\/pre>\n\n\n\n<p>This is useful in CI environments where you want to preserve recent cache for faster builds while still reclaiming space from stale entries.&nbsp;<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"h-frequently-asked-questions\"><strong>Frequently Asked Questions<\/strong>\u00a0<\/h2>\n\n\n\n<div class=\"schema-faq wp-block-yoast-faq-block\"><div class=\"schema-faq-section\" id=\"faq-question-1781804273515\"><strong class=\"schema-faq-question\"><strong>Does docker system prune remove volumes?<\/strong>\u00a0<\/strong> <p class=\"schema-faq-answer\">No, not by default. Running docker system prune without any flags skips volumes entirely to avoid accidental data loss. To include volumes in the prune operation, you must explicitly pass the &#8211;volumes flag: docker system prune &#8211;volumes. For a complete cleanup, use docker system prune -a &#8211;volumes, which removes all unused images, stopped containers, unused networks, the build cache, and unused volumes in a single pass.\u00a0<\/p> <\/div> <div class=\"schema-faq-section\" id=\"faq-question-1781804284101\"><strong class=\"schema-faq-question\"><strong>What is the difference between docker rm and docker rmi?<\/strong>\u00a0<\/strong> <p class=\"schema-faq-answer\">The docker rm command removes containers, while the docker rmi command removes images. You cannot use docker rm on an image or docker rmi on a container. The docker rm command accepts container names or IDs, and the docker rmi command accepts image names, tags, or image IDs. If you are unsure which to use, check first: docker ps -a lists containers and docker images -a lists images.\u00a0<\/p> <\/div> <div class=\"schema-faq-section\" id=\"faq-question-1781804287902\"><strong class=\"schema-faq-question\"><strong>How do I remove a Docker volume that is in use?<\/strong>\u00a0<\/strong> <p class=\"schema-faq-answer\">You cannot remove a volume that is currently mounted by a container, whether that container is running or stopped. Docker will return an error indicating the volume is in use. The solution is to first remove the container using that volume with docker rm containerid, and then remove the volume with docker volume rm volumename. If the container is running, stop it first with docker stop container_id before removing it.\u00a0<\/p> <\/div> <div class=\"schema-faq-section\" id=\"faq-question-1781804292074\"><strong class=\"schema-faq-question\"><strong>Does docker compose down -v remove named volumes?<\/strong>\u00a0<\/strong> <p class=\"schema-faq-answer\">Yes. Unlike docker rm -v, which only removes anonymous volumes, docker compose down -v removes both anonymous and named volumes that are declared in the volumes section of the docker-compose.yml file. If a named volume is shared between multiple Compose projects and is still in use by another project, it will not be removed. Volumes defined externally using external: true in the Compose file are also excluded from removal.\u00a0<\/p> <\/div> <div class=\"schema-faq-section\" id=\"faq-question-1781804296141\"><strong class=\"schema-faq-question\"><strong>How do I clean up all Docker resources at once?<\/strong>\u00a0<\/strong> <p class=\"schema-faq-answer\">The fastest way to docker clean all resources, including images, containers, volumes, and networks, is:\u00a0<br>docker system prune -a &#8211;volumes &#8211;force\u00a0<br>The -a flag extends the cleanup to all unused images (not just dangling ones), &#8211;volumes adds unused volumes to the scope, and &#8211;force skips the confirmation prompt. This is the most complete single-command option for clearing a Docker environment. Be aware that this will not remove volumes or images that are currently in use by running containers, so any actively running services are left untouched.<\/p> <\/div> <\/div>\n","protected":false},"excerpt":{"rendered":"<p>Remove Docker images, containers, volumes, and networks with step-by-step commands. Covers docker system prune, docker rm, docker rmi, and more.<\/p>\n","protected":false},"author":50,"featured_media":16953,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"_uag_custom_page_level_css":"","site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"set","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":"","_members_access_role":[],"_members_access_error":""},"categories":[18],"tags":[],"ppma_author":[1491],"class_list":["post-16952","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-tutorials"],"uagb_featured_image_src":{"full":["https:\/\/contabo.com\/blog\/wp-content\/uploads\/2023\/04\/blog-head_how2-remove-docker-images-containers-and-volumes.jpg",1200,630,false],"thumbnail":["https:\/\/contabo.com\/blog\/wp-content\/uploads\/2023\/04\/blog-head_how2-remove-docker-images-containers-and-volumes-150x150.jpg",150,150,true],"medium":["https:\/\/contabo.com\/blog\/wp-content\/uploads\/2023\/04\/blog-head_how2-remove-docker-images-containers-and-volumes-600x315.jpg",600,315,true],"medium_large":["https:\/\/contabo.com\/blog\/wp-content\/uploads\/2023\/04\/blog-head_how2-remove-docker-images-containers-and-volumes-768x403.jpg",768,403,true],"large":["https:\/\/contabo.com\/blog\/wp-content\/uploads\/2023\/04\/blog-head_how2-remove-docker-images-containers-and-volumes.jpg",1200,630,false],"1536x1536":["https:\/\/contabo.com\/blog\/wp-content\/uploads\/2023\/04\/blog-head_how2-remove-docker-images-containers-and-volumes.jpg",1200,630,false],"2048x2048":["https:\/\/contabo.com\/blog\/wp-content\/uploads\/2023\/04\/blog-head_how2-remove-docker-images-containers-and-volumes.jpg",1200,630,false]},"uagb_author_info":{"display_name":"Tobias Mildenberger","author_link":"https:\/\/contabo.com\/blog\/author\/tobias\/"},"uagb_comment_info":0,"uagb_excerpt":"Remove Docker images, containers, volumes, and networks with step-by-step commands. Covers docker system prune, docker rm, docker rmi, and more.","authors":[{"term_id":1491,"user_id":50,"is_guest":0,"slug":"tobias","display_name":"Tobias Mildenberger","avatar_url":"https:\/\/secure.gravatar.com\/avatar\/077178d5dce6c3d4c0c0396857a7e544bfdf8adf04145fff5160b33a22e28b1f?s=96&d=mm&r=g","author_category":"","user_url":"https:\/\/contabo.com\/en\/","last_name":"Mildenberger","first_name":"Tobias","job_title":"","description":""}],"_links":{"self":[{"href":"https:\/\/contabo.com\/blog\/wp-json\/wp\/v2\/posts\/16952","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/contabo.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/contabo.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/contabo.com\/blog\/wp-json\/wp\/v2\/users\/50"}],"replies":[{"embeddable":true,"href":"https:\/\/contabo.com\/blog\/wp-json\/wp\/v2\/comments?post=16952"}],"version-history":[{"count":6,"href":"https:\/\/contabo.com\/blog\/wp-json\/wp\/v2\/posts\/16952\/revisions"}],"predecessor-version":[{"id":31707,"href":"https:\/\/contabo.com\/blog\/wp-json\/wp\/v2\/posts\/16952\/revisions\/31707"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/contabo.com\/blog\/wp-json\/wp\/v2\/media\/16953"}],"wp:attachment":[{"href":"https:\/\/contabo.com\/blog\/wp-json\/wp\/v2\/media?parent=16952"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/contabo.com\/blog\/wp-json\/wp\/v2\/categories?post=16952"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/contabo.com\/blog\/wp-json\/wp\/v2\/tags?post=16952"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/contabo.com\/blog\/wp-json\/wp\/v2\/ppma_author?post=16952"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}