Project reference ↗

Unused container images and stopped containers can consume disk space on a Docker host. Spotify’s docker-gc script removed selected unused resources, and this historical chart ran it on every Kubernetes worker. The project is inactive, and Kubernetes already manages image and container cleanup through its node components. Modern workers may not use Docker at all. For an inherited installation, investigate the actual disk-pressure problem and runtime before retaining a second cleanup process with access to node resources.

Current guidance

The historical chart runs Spotify’s Docker garbage-collection script on every node. Upstream labels the project inactive and says no new features are being developed. Its suggestion to consider Docker’s prune command is aimed at Docker environments; it is not a recommendation to run indiscriminate pruning alongside kubelet on Kubernetes nodes.

Kubernetes has its own cleanup mechanisms for unused images and containers. Many current nodes use containerd or another CRI runtime rather than Docker, so the original socket and command assumptions may not apply at all. External cleanup can interfere with resources managed by the node agent and make image pulls or workload recovery less predictable.

For an inherited deployment, identify what it actually deletes, whether volume removal is enabled and which nodes mount the Docker socket. Replace the operational need with supported kubelet/runtime configuration and monitoring of disk pressure, image usage and log growth. Validate cleanup under a representative workload before removing retained artifacts. Keep manual emergency cleanup as a controlled incident procedure, not an unreviewed cluster-wide cron job copied from this archived chart.

Historical upstream link check · 2026-10-09

The recorded upstream address responded successfully (HTTP 200) on 2026-10-09. GitHub confirms that helm/charts is archived: this is a historical chart distribution, not evidence that the application itself is retired. Link availability does not certify the historical installation instructions or current security support.

Source for this check ↗

Website availability is separate from project, chart and image support. Use the current guidance and primary sources on this page to assess the distribution.

The original record

Historical Kubedex content

Original publication: 2018-09-19T15:29:42+00:00. Preserved for context. Commands, versions, prices and results below reflect the original research.

This chart wraps the Spotify/docker-GC Docker image in the form of a DaemonSet so that Docker resource garbage collection occurs on all nodes of a given Kubernetes cluster.

It is unclear if this should be used on a Kubernetes cluster since Kubelet has many of these cleanup features.

Chart Details

This chart will do the following:

  • Deploy one pod running the Spotify/docker-GC container to each node in a Kubernetes cluster, configured with the values provided.
  • A simple Docker container and image garbage collection script.
  • Containers that exited more than an hour ago are removed.
  • Images that don’t belong to any remaining container after that are removed.
  • Optionally, remove volumes that are not associated with any remaining container after removal (Available only for docker >= 1.9.0)

Although docker normally prevents removal of images that are in use by containers, we take extra care to not remove any image tags (e.g., Ubuntu:14.04, busybox, etc) that are in use by containers. A naive docker RMI $(docker images -q) will leave images stripped of all tags, forcing docker to re-pull the repositories when starting new containers even though the images themselves are still on disk.

This script is intended to be run as a cron job, but you can also run it as a Docker container.

Manual Usage

To use the script manually, run docker-GC. The system user under which docker-GC runs needs to have read and write access to the $STATE_DIR environment variable which defaults to /var/lib/docker-GC.

Excluding Images From Garbage Collection

There can be images that are large that serve as a common base for many application containers, and as such, make sense to pin to the machine, as many derivative containers will use it. This can save time in pulling those kinds of images. There may be other reasons to exclude images from garbage collection. To do so, create /etc/docker-GC-exclude, or if you want the file to be read from elsewhere, set the EXCLUDE_FROM_GC environment variable to its location. This file can contain image name patterns (in the grep sense), one per line, such as Spotify/Cassandra: latest or it can contain image ids (truncated to the length shown in docker images which are 12.

An example image excludes file might contain:

  • spotify/cassandra:latest
  • redis:.*
  • 9681260c3ad5

Excluding Containers From Garbage Collection

There can also be containers (for example data only containers) which you would like to exclude from garbage collection. To do so, create /etc/docker-GC-exclude-containers, or if you want the file to be read from elsewhere, set the EXCLUDE_CONTAINERS_FROM_GC environment variable to its location. This file should contain name patterns (in the grep sense), one per line, such as MariaDB-data.

An example container excludes file might contain:

  • MariaDB-data
  • drunk_goodall

Excluding Volumes From Garbage Collection

There can be occasions where you don’t want to remove a dangling volume. To enable this functionality you can create a file named /etc/docker-GC-exclude-volumes (or specify EXCLUDE_VOLUMES_IDS_FILE env var with any path for such file), containing name patterns (in the grep sense), one per line, of volumes that will be excluded from garbage collection.

Forcing deletion of images that have multiple tags

By default, docker will not remove an image if it is tagged in multiple repositories. If you have a server running docker where this is the case, for example in CI environments where dockers are being built, re-tagged, and pushed, you can enable a force flag to override this default.

FORCE_IMAGE_REMOVAL=1 docker-gc

Preserving a minimum number of images for every repository

You might want to always keep a set of the most recent images for any repository. For example, if you are continually rebuilding an image during development you would want to clear out all but the most recent version of an image. To do so, set the MINIMUM_IMAGES_TO_SAVE=1 environment variable. You can preserve any count of the most recent images, e.g. save the most recent 10 with MINIMUM_IMAGES_TO_SAVE=10.

Forcing deletion of containers

By default, if an error is encountered when cleaning up a container, Docker will report the error back and leave it on disk. This can sometimes lead to containers accumulating. If you run into this issue, you can force the removal of the container by setting the environment variable below:

FORCE_CONTAINER_REMOVAL=1 docker-GC

Excluding Recently Exited Containers and Images From Garbage Collection

By default, docker-GC will not remove a container if it existed less than 3600 seconds (1 hour) ago. In some cases, you might need to change this setting (e.g. you need exited containers to stick around for debugging for several days). Set the GRACE_PERIOD_SECONDS variable to override this default.

GRACE_PERIOD_SECONDS=86400 docker-gc

The post Spotify’s Docker-GC appeared first on kubedex.com.

Sources & further reading

  1. docker-gc inactive status and behavior
  2. Kubernetes garbage collection ownership
  3. Upstream inactive repository metadata
  4. Recovered historical source

Spotted something that needs another look?

Help improve this page →