• Windows
  • Workflows

A Windows development machine that does not fill up every quarter

Shared caches, a second drive for the right things, and four settings that stop the recurring cleanup.

6 min read

Cleaning a development PC every quarter is a setup problem rather than a discipline problem. Most of the recurring growth has a configuration answer, and Windows gives you more places to put things than macOS does.

The four settings worth changing once

  1. A shared plugin cache for anything that defaults to per project copies, starting with Terraform.
  2. Move package caches to a second drive, using each tool's own environment variable rather than a junction.
  3. Docker's disk on another drive, one setting in Docker Desktop, and usually the largest single move.
  4. Long path support on, which prevents a whole class of confusing failures.
npm config set cache D:\dev\npm-cache
[Environment]::SetEnvironmentVariable('NUGET_PACKAGES','D:\dev\nuget','User')
[Environment]::SetEnvironmentVariable('CARGO_HOME','D:\dev\cargo','User')
[Environment]::SetEnvironmentVariable('GOMODCACHE','D:\dev\go\pkg\mod','User')
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem' -Name LongPathsEnabled -Value 1

What belongs where

Keep on the fast driveMove to the second
Active project foldersArchived repositories
Build output being written nowContainer images and WSL disks
The IDE and SDKsModel weights and datasets
The repository you are in todayOld build artefacts and releases

The split is write frequency rather than size. A folder written thousands of times during a build belongs on the fastest drive; one read monthly does not.

The quarterly command

Get-ChildItem $env:USERPROFILE -Recurse -Directory -Include node_modules,target,bin,obj,.next -Depth 5 -Force -EA SilentlyContinue |
  Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-90) } |
  ForEach-Object {
    $s = (Get-ChildItem $_.FullName -Recurse -Force -File -EA SilentlyContinue | Measure-Object Length -Sum).Sum
    [PSCustomObject]@{ MB = [math]::Round($s/1MB); Path = $_.FullName }
  } | Sort-Object MB -Descending | Select-Object -First 25

Everything that prints is build output from a project untouched for three months. Removing it costs one rebuild if you return, and this single command is usually worth more than everything else on this page combined.

The Windows specific wins

  • Defender exclusions for source and build folders, which is speed rather than space but is the most felt change.
  • A Dev Drive on Windows 11 for the same reason, covered in Dev Drive.
  • WSL compaction after clearing inside, because deleting in the guest frees nothing outside.
  • DISM component cleanup quarterly, since a long lived machine accumulates superseded packages.

Common questions

How do I stop a Windows dev machine filling up?

Configure shared caches, move package caches and Docker's disk to a second drive using each tool's own setting, enable long paths, and run a quarterly pass over build output older than 90 days.

Should I use junctions to move developer caches?

No. Use each tool's own environment variable or config setting. Junctions work until an uninstaller follows one or an update replaces it, and the failure then looks like something else.

What belongs on the fast drive on a dev machine?

Anything written constantly: active projects, build output, the IDE and SDKs. Archived repositories, container images, WSL disks and datasets can live on a slower second drive.

Is developer cleanup risky on Windows?

Less than any other category, because build output and caches are regenerated. Protect source, lock files and unpushed work, and everything else is safe.

Read next