developer-experienceperformanceCI

Optimizing Developer Workstations: A 4‑Step Routine to Make Your Build Machine Run Like New

ddevtools

2026-03-09

11 min read

A practical 4‑step routine to reclaim disk, rationalize caches, prune deps, and profile builds — speed up dev workstations and CI runners in 2026.

Hook: Your workstation should help you move fast — not slow you down

Nothing kills developer momentum like a build that takes forever, flaky CI runners, or a machine that fills up overnight with caches and unused dependencies. If you manage multiple projects or run heavy local builds, your workstation quietly accumulates technical debt: bloated disk usage, stale caches, unnecessary packages, and performance regressions.

Inspired by the simple “phone 4‑step routine” everyone uses to make an old phone feel new again, this article adapts that approach for developer workstations. The result is a compact, repeatable, 4‑step routine to restore build performance and reduce cost across local machines and CI runners.

Why this matters in 2026

Through late 2025 and into 2026 we've seen two clear trends: teams increasingly use remote caching and distributed build systems, and hybrid developer environments (local + cloud devmachines) are standard. That makes local workstation efficiency even more important — slow local builds increase cloud usage, inflate remote cache churn, and multiply CI costs. Small per‑developer improvements compound across teams and runbooks.

What this routine fixes

Reclaim disk space: fewer build failures from full volumes and faster I/O.
Smarter cache management: keep helpful caches, evict useless ones.
Smaller dependency surface: reduce install times and security noise.
Visibility into bottlenecks: targeted tuning rather than guesswork.

The 4‑Step Routine (overview)

Disk cleanup: remove cruft and free fast storage for active builds.
Cache triage: rationalize caches (keep hits, purge misses).
Dependency pruning: remove unused/duplicated dependencies and lockfiles sprawl.
Profile and tune: measure, benchmark, and apply targeted fixes.

Step 1 — Disk cleanup: make fast storage available

Free, contiguous, and low‑latency disk space matters for build performance. Cleanups should be safe and idempotent so you can run them regularly (weekly or monthly).

Quick checklist

Identify large directories and old artifacts.
Prune container images/volumes and package caches.
Move ephemeral build dirs to fast NVMe or tmpfs.
Ensure SSD health and TRIM are enabled.

Commands and examples

Linux (and WSL): find big dirs and remove stale files

# show top 20 folders under home
sudo du -ahx ~ | sort -rh | head -n 20

# remove node_modules older than 30 days (be careful: only if you know targets)
find . -type d -name 'node_modules' -mtime +30 -exec rm -rf {} +

# prune Docker artifacts
docker system prune -af --volumes

docker image ls --format 'table {{.Repository}}\t{{.Size}}' | head -n 20

macOS (brew, Xcode):

# Homebrew cleanup
brew cleanup -s

# remove old Xcode simulators and derived data
xcrun simctl delete unavailable
rm -rf ~/Library/Developer/Xcode/DerivedData/*

Windows / WSL:

# WSL cleanup
wsl --shutdown
# then from Windows PowerShell
wsl --export  backup.tar
wsl --unregister  && wsl --import   backup.tar --version 2

# Chocolatey cleanup (remove package cache)
choco clean -y

Docker and CI runner notes

CI runners commonly die when ephemeral disks fill. Add automated pruning in runner maintenance windows:

# recommended monthly cron for self-hosted GitHub Actions / GitLab runners
# - docker system prune to remove dangling objects
# - remove old runner workspaces older than 14 days
0 3 1 * * root docker system prune -af --volumes && find /var/lib/runner/_work -maxdepth 2 -mtime +14 -type d -exec rm -rf {} +

Step 2 — Cache triage: keep the caches that save time

Caches are speed multipliers — when they hit. They also become malware for disk and consistency when they miss. The goal is to keep high‑value caches and purge low‑value or corrupt caches.

Decide cache value

High value: compiler caches (ccache/sccache), Docker build cache with BuildKit, language package wheels/warm caches that are frequently reused.
Low value: gigantic monorepo build artifacts that change every commit, corrupt caches that cause rebuilds, and orphaned caches from old toolchains.

Examples — language/package caches

# Node/npm
npm cache verify
npm cache clean --force  # use cautiously

# pnpm (uses disk store) — check store size
du -sh ~/.pnpm-store
pnpm store prune

# yarn v1
yarn cache clean

# Python pip
pip cache dir
pip cache purge

# Rust (cargo)
du -sh ~/.cargo/registry ~/.cargo/git
cargo cache --autoclean  # requires cargo-cache

# Java/Gradle
# Gradle caches in ~/.gradle/caches can be big; prune unused
rm -rf ~/.gradle/caches/jars-*/modules-2/files-2.1/*/org/some-unused-lib
gradle --stop

Compiler caches and distributed build caches

Enable and tune persistent compiler caches. For native projects, sccache or ccache saves enormous time. For Java/Kotlin, Gradle Remote Build Cache and task output caching matter. For Docker, switch to BuildKit and create a remote cache (or use local BuildKit cache dir).

# enable sccache (Rust/C/C++)
export RUSTC_WRAPPER=$(which sccache)
# show sccache stats
sccache --show-stats

# Docker BuildKit usage
DOCKER_BUILDKIT=1 docker build --cache-from=type=local,src=/path/to/cache -t myimage:latest .

Automate cache eviction with policies

Keep caches for the last N commits or M days.
Evict caches when disk usage exceeds a threshold (e.g., 80%).
In CI, store remote cache keys tied to branches or commit hashes to avoid cross‑branch pollution.

Step 3 — Dependency pruning: shrink install time and security noise

Dependency creep is a silent drag. Multiple package.json files, transitive duplicates, and stale dev dependencies increase install times and attack surface. Address this with targeted pruning and smarter package managers.

Audit & remove unused dependencies

# Node: detect unused deps in a project (dev:true includes devDeps)
npx depcheck --json

# Python: list installed packages not in requirements.txt (use virtualenv)
pip freeze > installed.txt
comm -23 installed.txt requirements.txt

# Ruby: bundler clean
bundle clean --force

# Go: tidy modules
go mod tidy

# Rust: remove unused dependencies and shrink lock file
cargo tree | sed -n '1,200p'

Consolidate duplicates in monorepos

Monorepos often suffer duplicated transitive dependencies. Use tools and package manager features:

pnpm: stores single content‑addressed store to dedupe.
Yarn PnP / Plug’n’Play: removes node_modules overhead.
Gradle: use dependency constraints and version catalogs.

Case study: prune to speed up installs

On a 30‑developer codebase in late 2025 we replaced npm + classic node_modules with pnpm and removed 15% of direct deps after auditing. Result: cold install time dropped from ~4m to ~1m 10s; CI cache size fell 3x, saving $1,200/month in CI storage and egress.

Step 4 — Profile & tune: measure, iterate, and automate

Profiling gives you the answers you need to pick the right fix. Don’t guess whether I/O, CPU, memory, or network is the culprit — measure it.

Benchmarking suggestions

Measure cold vs incremental builds (cold = empty cache; warm = after one build).
Use a reproducible script and a CI job as your baseline.
Run multiple iterations and compute p50/p95 to avoid noise.

Tools & commands

# timing builds with hyperfine (cross-platform, reliable)
hyperfine --warmup 2 'npm run build --silent'

# measure disk I/O and CPU during build
sudo iostat -xz 1
# or use atop, dstat, vmstat

# profile a Java/Gradle build
gradle --profile build
# open the generated profile report in build/reports/profile

# Linux perf and FlameGraphs for hot functions
perf record -g -- 
perf script | stackcollapse-perf.pl | flamegraph.pl > perf.svg

# measure network time for package installs
sudo tcpdump -w install.pcap port 443 and host registry.npmjs.org

Common tuning levers

Move ephemeral build directories to tmpfs for very I/O heavy builds (careful with RAM limits).
Increase file descriptor limits for parallel build tasks (ulimit -n).
Increase worker counts (make -j, Gradle org.gradle.workers.max) but benchmark — oversubscribing cores can hurt due to I/O contention.
Enable parallel dependency resolution (npm ci has improvements, pnpm is parallel by design).
Use compiler caching (sccache/ccache) and remote caches for reproducible artifacts.

Example: measuring cold vs warm Docker builds

# cold build (no cache)
DOCKER_BUILDKIT=1 docker build --no-cache -t test:latest .

# warm build (from local BuildKit cache)
DOCKER_BUILDKIT=1 docker build -t test:latest .

# use hyperfine for repeatable measurement
hyperfine "DOCKER_BUILDKIT=1 docker build --no-cache -t test:latest ." "DOCKER_BUILDKIT=1 docker build -t test:latest ."

Putting the routine into practice — a 30‑minute script

Below is a safe, minimal script you can adapt into your devmachine maintenance cron or run manually. It emphasizes verification before deletion and logs each step.

#!/usr/bin/env bash
set -euo pipefail
LOG=~/dev_cleanup_$(date +%F).log
exec &> >(tee -a "$LOG")

echo "Step 1: Disk top offenders"
du -ahx ~ | sort -rh | head -n 20

read -p "Proceed with Docker prune? (y/N) " ans
if [[ "$ans" =~ ^[Yy]$ ]]; then
  docker system prune -af --volumes || true
fi

echo "Step 2: Verify and clean common caches"
# npm: verify only
npm cache verify || true

# pip: list size
pip cache dir || true

read -p "Purge pip cache? (y/N) " ans2
if [[ "$ans2" =~ ^[Yy]$ ]]; then
  pip cache purge || true
fi

# Step 3: dependency audit (project-local; run per repo)
echo "Run depcheck in repo? (y/N)"
if [[ $(pwd) =~ /path/to/your/repo ]] ; then
  npx depcheck || true
fi

# Step 4: quick profile
echo "Running sample hyperfine for project build"
hyperfine --warmup 1 'npm run build --silent' || true

echo "Cleanup complete. Log: $LOG"

Operationalizing the routine across teams and CI

Make these practices part of onboarding and CI runner maintenance:

Add a monthly runner housekeeping job that prunes Docker, evicts old caches, and logs artifacts removed.
Document cache policies in your README or infra repo (what to keep, TTLs, eviction thresholds).
Include a small benchmark job in PR pipelines to detect surprising build time regressions (e.g., +10% in p50 build duration).
Centralize remote caches where possible — remote build cache usage has been a major cost saver for many orgs in 2025.

Advanced strategies & 2026 trends to watch

Ephemeral cloud devmachines: many teams moved to hybrid dev workflows in 2025; spin up warmed cloud workspaces for heavy builds and keep your local workstation for fast iteration.
Smarter remote caching: expect more standardized remote cache protocols in 2026. Adoptable APIs allow cross‑tool reuse of artifacts.
AI‑aided dependency pruning: automated suggestions that detect unused imports and safe removal candidates are maturing — review suggestions before apply.
Observability for developer workflows: treating local build metrics as telemetry — collect p50/p95 build times, cache hit ratios, and disk usage per developer cohort.

Safety & governance

When doing automated cleanups, guardrails are essential:

Log every deletion and keep a recovery window for critical artifacts.
Use dry‑run mode before mass deletion.
On CI runners, coordinate prune windows with off‑peak times to avoid interrupting jobs.
Maintain backups for developer home directories if you run aggressive cleanups centrally.

Actionable takeaways — the 10‑minute cheat sheet

Run disk scan: du -ahx ~ | sort -rh | head -n 20.
Prune Docker: docker system prune -af --volumes (confirm first).
Verify and clean language caches: npm cache verify, pip cache purge, cargo cache autoremove.
Audit unused deps: npx depcheck, go mod tidy, cargo tree.
Enable compiler caching: sccache/ccache for native builds.
Benchmark builds with hyperfine and collect p50/p95 regularly.
Set cache eviction policies and add periodic cleanup to runner maintenance.

Pro tip: automate a small maintenance job that logs artifacts removed. Having the log makes rollbacks and accountability trivial.

Final checklist for a 20‑minute routine

Clear package manager caches you don't rely on.
Prune container artifacts and old workspaces.
Run a dependency audit and remove unused items from lockfiles.
Run a quick warm and cold build benchmark and save the result.
If the build is I/O bound, move ephemeral build data to NVMe or tmpfs temporarily.

Conclusion — small rituals, big returns

Adopting a simple 4‑step routine — disk cleanup, cache triage, dependency pruning, and profiling — restores workstation performance just like that phone routine makes an old device feel new. The payoff is faster iteration, fewer CI surprises, and measurable cost savings at scale.

Start small: add a monthly maintenance job to your runner fleet and a 10‑minute checklist to your developer onboarding. Track build times and cache hit ratios for a quarter — you’ll be surprised how much low‑effort housekeeping compounds into real productivity and cost optimization.

Call to action

Try the 4‑step routine on one machine this week and record warm + cold build times before and after. Want a ready‑to‑use checklist or a runnable cleanup script adapted to your stack? Reach out to your infra team or copy the example script above and adapt it to your projects — then share results with your team so everyone benefits.

devtools

Contributor

Senior editor and content strategist. Writing about technology, design, and the future of digital media. Follow along for deep dives into the industry's moving parts.