Minikube’s disk usage can creep up surprisingly fast, silently eating away at your local storage.
Here’s how to reclaim that space, focusing on the culprit: old Docker images.
First, let’s see what’s gobbling up your disk. Minikube stores its images within a Docker volume. You can inspect the size of this volume using docker system df.
$ docker system df
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 150 4 15.23GB 14.83GB
Containers 30 2 300MB 250MB
Local Volumes 5 1 10GB 8GB
Build Cache 0 0 0B 0B
Notice the Images and Local Volumes sections. The Images are your container images, and Local Volumes can also hold cached data. The RECLAIMABLE column is your best friend here – it tells you how much space can be freed up.
The primary way Minikube manages its disk space is through its internal Docker daemon and its image cache. When you build images or pull them, they are stored within Minikube’s Docker environment. Over time, especially with frequent rebuilds or testing different image versions, this cache can grow significantly.
To clean up unused Docker images within Minikube, the command is minikube image rm --all. This command targets images that are not currently associated with any running containers within your Minikube cluster.
$ minikube image rm --all
After running this, check docker system df again. You should see a noticeable reduction in the SIZE of Images and an increase in RECLAIMABLE.
If minikube image rm --all doesn’t free up as much space as you expect, the next step is to target dangling images. These are images that are no longer tagged and are not referenced by any container. The command to remove these is docker image prune -a. You’ll run this inside the Minikube environment.
To execute commands inside Minikube’s Docker daemon, use minikube ssh.
$ minikube ssh 'docker image prune -a'
This command prompts for confirmation. Type y and press Enter. It will remove all unused images (dangling and unreferenced).
Still not enough space? Minikube also maintains a Docker volume where all its data resides. Sometimes, this volume can become fragmented or contain data that docker image prune doesn’t touch. You can explicitly clean up unused Docker data, including old volumes and networks, with docker system prune. Again, run this via minikube ssh.
$ minikube ssh 'docker system prune'
This command is more aggressive. It will remove:
- All stopped containers
- All networks not used by at least one container
- All dangling images
- All dangling build cache
It will also prompt for confirmation.
If you’re still seeing significant disk usage related to Minikube, it might be that the Minikube VM itself has grown. Minikube uses a virtual machine (usually VirtualBox, KVM, or Hyper-V) to run Docker. You can reset Minikube to its default state, which effectively recreates the VM and its associated disk image, freeing up all accumulated space. Warning: This will delete all your Minikube clusters, deployments, and data within Minikube.
$ minikube delete
$ minikube start
This is the most drastic cleanup, essentially giving you a fresh Minikube environment.
Finally, if you’re using the docker driver, Minikube stores its data in a specific location on your host machine. For Linux, this is typically ~/.minikube/machines/minikube/. For macOS and Windows (using VirtualBox), it’s within the VirtualBox VM’s disk image, which is harder to clean directly without minikube delete. However, if you’re using the docker driver directly on your host, you can manually inspect and clean up the Docker volumes.
# For docker driver on Linux
docker volume ls
# Identify the minikube volume (often named 'minikube')
docker volume rm <minikube_volume_name>
The next issue you’ll likely encounter after aggressively cleaning up images is that minikube start might take longer as it needs to re-download necessary base images.