I'm developing on Windows 11 with Docker Desktop using the WSL2 backend. I start my project with `docker compose up --build` roughly 20–30 times a day, and over time Docker's `docker_data.vhdx` has grown to about 90 GB.
I've tried `docker system prune -a`, `docker builder prune`, `wsl --shutdown`, and compacting the virtual disk with DiskPart. Those steps recover some space, but the VHDX starts growing again after several days.
Is this expected when running Compose builds so frequently? Should I only use `--build` when the Dockerfile or dependencies change? What's a good daily development workflow for controlling build cache, unused images, volumes, and the size of the WSL2 VHDX?
3 Answers
Installing Docker directly inside WSL2 usually won’t eliminate the issue, because WSL distributions also use dynamically growing VHDX files. Switching installation methods may change where the data lives, but it doesn’t remove the need to manage caches, volumes, and virtual-disk compaction.
The VHDX normally grows as Docker creates image layers, build cache, containers, and volumes. Pruning removes data from inside the virtual disk, but it usually doesn’t make the Windows file smaller automatically. After pruning, shut down WSL and compact the VHDX; using the newer Optimize-VHD tooling may reclaim more space than a basic DiskPart compaction. Also check whether a container or volume is generating unexpected data.
You generally don’t need `--build` on every run. Use `docker compose up` for normal development, and add `--build` when the Dockerfile, build context, or dependency files have changed. Docker reuses cached layers when possible, but repeated builds can still accumulate cache and intermediate data, especially if build inputs change often.
A practical routine is to rebuild only when needed, periodically run `docker builder prune` or a more targeted cleanup, remove unused volumes carefully, then compact the VHDX after shutting down WSL.
Having free disk space is fine, but a large VHDX can still contain mostly unused data. In that case, pruning followed by proper VHDX compaction is what actually reduces the file size.