DEV Community: Sarmad Hussain

Docker Desktop is Secretly Hoarding 30GB — Here's How to Reclaim It

Sarmad Hussain — Tue, 13 Oct 2026 21:07:59 +0000

You open System Settings → General → Storage on your Mac and see the dreaded label: "System Data: 98 GB". You haven't downloaded movies, and your Downloads folder is empty. Yet your 512GB SSD is choking.

If you are a developer on macOS, the primary suspect is almost certainly Docker Desktop.

Even with just a few containers or a local Postgres instance, Docker on macOS silently hoards 30GB to 80GB of disk space. Worse: when you delete containers or images inside Docker, macOS doesn't automatically get that disk space back.

In this guide, we'll dissect Docker Desktop's storage architecture on macOS, explain why the virtual disk never shrinks on its own, and provide Terminal commands to reclaim your space.

1. Why Docker on macOS is Fundamentally Different

On Linux, Docker runs natively against the host kernel using cgroups and overlay filesystems (overlay2). Files write directly to /var/lib/docker on your host drive.

macOS, however, uses the Darwin kernel with no native Linux container primitives. To run containers, Docker Desktop spins up a lightweight Linux virtual machine via Apple's Hypervisor framework.

┌────────────────────────────────────────────────────────┐
│ macOS Host (APFS Filesystem)                           │
│  ~/Library/Containers/com.docker.docker/Data/vms/...   │
│  └── 📁 Docker.raw (Virtual Disk Image: 64 GB)        │
│        ▲                                               │
│        ▼ [Block-level virtualized disk]                │
│  ┌──────────────────────────────────────────────────┐  │
│  │ Linux VM (ext4 Filesystem)                       │  │
│  │  /var/lib/docker/ (overlay2, buildkit, volumes)  │  │
│  └──────────────────────────────────────────────────┘  │
└────────────────────────────────────────────────────────┘

Everything inside Docker—container layers, pulled images, BuildKit caches, and volume mounts—is packed into a single virtual disk file on your host drive named Docker.raw (or Docker.qcow2).

2. Locating `Docker.raw` on APFS

The virtual disk image is typically located at:

~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw

The APFS Sparse File Trap: Apparent vs. Physical Size

If you check the file with ls -lh:

ls -lh ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw

You might see 64G. However, Docker.raw is an APFS sparse file; it only allocates physical blocks on your SSD as data is written. To see how much physical space it actually consumes, use du:

du -sh ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw

If du -sh reports 38G, Docker is actively taking 38 GB of physical flash storage.

3. Why Docker's Virtual Disk Never Shrinks

Here is the fundamental architectural trap with docker mac storage:

When you run docker build or pull an image, Linux writes blocks into the virtual disk.
The APFS host sees new blocks written and expands the physical footprint of Docker.raw.
Later, you run docker rm or delete an old project. The Linux VM marks those sectors as free within its ext4 filesystem.
However, APFS on macOS has no automatic way of knowing that those blocks were freed inside the Linux VM.

Unless an explicit TRIM/DISCARD command is passed down through the virtual block device driver to APFS, the host file stays bloated at its peak high-water mark. Your Mac SSD thinks that space is occupied, even if 80% of Docker's internal filesystem is empty air.

4. Diagnosing Docker Bloat from the Terminal

Before touching anything, let’s see what is actually consuming space inside Docker's virtual disk. Run:

docker system df

You will see output similar to this:

TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          18        4         12.4GB    8.6GB (69%)
Containers      8         2         840MB     620MB (73%)
Local Volumes   14        3         14.2GB    11.1GB (78%)
Build Cache     142       0         18.9GB    18.9GB (100%)

Notice that Build Cache and Local Volumes often represent the vast majority of bloat!

For a granular breakdown of every individual container, image layer, and volume:

docker system df -v

5. The Step-by-Step Reclamation Guide

Let's methodically reclaim this space, from the safest non-destructive steps to deep pruning.

Step 1: Purge the BuildKit Cache (The Biggest Hidden Hog)

Modern Docker builds use BuildKit by default. BuildKit aggressively caches intermediate compilation layers, npm installs, and apt packages so future builds are fast. But over months of active development, this cache routinely balloons past 20GB.

To reclaim the build cache:

docker builder prune -f

To purge all build cache, including non-dangling build stages:

docker builder prune -a -f

[!TIP]
This does not delete any running containers or active project images. It only clears build cache layers. The next time you build an image from scratch, Docker will simply re-download or re-compile missing layers.

Step 2: Remove Dangling and Unused Images

When you rebuild a Dockerfile with the same tag (e.g. myapp:latest), the previous image build becomes an untagged <none>:<none> dangling image.

To delete dangling images:

docker image prune -f

To delete all images not currently linked to a running container:

docker image prune -a -f

Step 3: Remove Stopped Containers

Every time you docker run without the --rm flag, the container's read-write filesystem overlay remains on disk when it exits:

docker container prune -f

Step 4: Audit Dangling Volumes

Anonymous volumes created by database containers (Postgres, Redis, MongoDB) are persistent by design. If you discard a test container without removing its volume (docker run -v /data), that volume remains forever:

# List orphaned volumes not attached to any container
docker volume ls -qf dangling=true

# Remove dangling volumes safely
docker volume prune -f

[!WARNING]
If you have a local dev database in an anonymous volume that isn't named, pruning volumes will wipe that database! Ensure active databases are backed up or defined with named volumes before running volume prune.

6. Docker Cleanup Strategy Matrix

Here is how the different Docker commands compare in terms of disk savings and safety:

Command	What It Cleans	Typical Savings	Safety Level	Risk / Impact
`docker builder prune -a`	BuildKit compilation cache	10 GB – 25 GB	🟢 High	Slower initial rebuild for your next `docker build`
`docker image prune`	Untagged dangling images (`<none>`)	2 GB – 10 GB	🟢 High	Zero impact; unreferenced layers only
`docker container prune`	Stopped containers	1 GB – 5 GB	🟡 Medium	Removes logs and ephemeral writable layer of exited containers
`docker volume prune`	Dangling anonymous volumes	5 GB – 30 GB	🟠 Moderate	Discards orphaned volume data; protect dev databases first
`docker system prune -a --volumes`	Everything not actively running	25 GB – 70 GB	🔴 Aggressive	Wipes all unused images, caches, stopped containers, and volumes

7. Shrinking `Docker.raw` on APFS

After pruning internally, ensure host APFS actually reclaims the space.

Method A: Docker Desktop Compact

Docker Desktop (v4.20+) includes a native disk compaction utility:

Open Docker Desktop settings.
Go to Settings → Resources → Advanced (or the Troubleshoot bug icon).
Select "Clean / Purge data" or click "Compact virtual disk".

Method B: Resetting the Virtual Disk

If Docker.raw remains stubbornly large, reset it cleanly:

killall Docker
rm -f ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw

When restarted, Docker initializes a fresh virtual disk of just ~1.5 GB.

8. Automated Intelligence: Dusty's Docker Overlay Detection

If auditing sparse files and BuildKit layers manually is tedious, Dusty handles it automatically.

Dusty is an AI-powered macOS storage cleaner built in native Swift for developers.

How Dusty Handles Docker Storage:

Docker VM & Overlay Detection: Automatically pinpoints Docker.raw, displaying true physical usage vs logical size.
Google Gemini AI Explanations: Explains obscure cache layers and overlay paths in plain English before cleanup.
Trash-First Safety: Files move to macOS Trash rather than permanent deletion.
Developer Bloat Scanning: Simultaneously clears orphaned node_modules, Xcode DerivedData, and WhatsApp media.
Transparent Pricing: $9.99 lifetime license (pay once, own forever) with a 24-hour free trial. No subscriptions.

Quick Install via Homebrew:

brew install sarmadhussainch/dusty/dusty

GitHub Tap: github.com/sarmadhussainch/homebrew-dusty

Official site: dustystorage.com

Final Thoughts

Docker Desktop is essential for modern development, but on macOS, its storage footprint demands vigilance. Audit docker system df monthly and prune your BuildKit cache to keep your SSD fast and healthy.

What About Your Machine?

How much space was Docker.raw taking on your Mac? Did clearing BuildKit make the biggest difference? Share your numbers in the comments!

5 Hidden Folders Eating Your Mac's Storage (And How to Safely Reclaim 100GB+)

Sarmad Hussain — Tue, 13 Oct 2026 15:06:24 +0000

You sit down to build a new feature or pull a container image, and macOS interrupts you with a familiar nightmare:

⚠️ "Your disk is almost full"

You open System Settings → General → Storage, hoping for clear answers. Instead, macOS presents an enormous, opaque bar:

[ ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ ]
System Data: 138.4 GB

Where did 140 GB vanish? Your Documents folder is only 15 GB, and your Applications take 25 GB.

The culprit is hidden inside Unix directories that macOS excludes from user categories and dumps into generic "System Data." If your mac storage full alert is firing, here is a technical breakdown of the 5 hidden folders silently consuming your Mac's storage, the Terminal commands to audit them, and how to safely reclaim 100GB+ without breaking your development workflow.

The 5 Hidden Storage Killers at a Glance

Directory	Typical Size	What Lives There	Safe to Purge?
`~/Library/Caches`	15 GB – 45 GB	App, browser, & Electron framework caches	✅ Yes (App-by-app)
`~/Library/Developer/Xcode/DerivedData`	20 GB – 70 GB	Build artifacts, index symbols, module caches	✅ Yes (Xcode regenerates)
`~/Library/Group Containers/group.net.whatsapp.WhatsApp.shared`	10 GB – 40 GB	Cached media, video duplicates, voice notes	⚠️ Yes (Keep SQLite DB)
`~/.gradle/caches`	10 GB – 35 GB	JVM/Android build transforms & stale jars	✅ Yes (Stop daemon first)
`~/Library/Containers/com.docker.docker/Data`	30 GB – 80 GB	Docker Desktop Linux VM disk (`Docker.raw`)	⚠️ Yes (Via Docker CLI)

1. `~/Library/Caches`: The App Landfill

What creates it?

Every macOS application stores discardable cache files in ~/Library/Caches/<bundle-identifier>. This includes browsers (Chrome, Safari), development editors (VS Code, Cursor), Electron apps (Slack, Discord, Spotify), and system frameworks.

Why it grows

While apps should prune old files, they rarely do. Slack caches media from channels you haven't opened in years; Spotify keeps gigs of cached streams; and VS Code accumulates language server indexes. Worse, when you drag an application to the Trash, its directory inside ~/Library/Caches remains behind forever.

Inspect its size

Audit the 10 largest cache hogs in Terminal:

du -sh ~/Library/Caches/* 2>/dev/null | sort -hr | head -n 10

How to clean it safely

Never run rm -rf ~/Library/Caches/* with open apps, which can corrupt running cache databases. Instead, close the target app and purge its folder:

# Chrome cache
rm -rf ~/Library/Caches/Google/Chrome/*

# Slack cache
rm -rf ~/Library/Caches/com.tinyspeck.slackmacgap/*

# Spotify audio cache
rm -rf ~/Library/Caches/com.spotify.client/Data/*

💡 Tip: Purging caches won't log you out—user sessions and preferences live in ~/Library/Application Support.

2. `~/Library/Developer/Xcode/DerivedData`: The Build Artifact Monster

What creates it?

Whenever you compile iOS, macOS, watchOS, or Swift packages—or run React Native and Flutter projects invoking native compilers—Xcode writes intermediate build objects, module caches, and index files into DerivedData.

Why it grows

Xcode retains separate build artifacts for every branch, configuration, and project workspace. If you worked on a client project months ago, its 15GB compilation footprint remains indefinitely. Xcode provides no automatic expiration policy.

Inspect its size

du -sh ~/Library/Developer/Xcode/DerivedData 2>/dev/null

On active developer machines, this folder routinely swells past 40 GB.

How to clean it safely

DerivedData contains purely ephemeral build artifacts and indexes. Purging it is completely safe:

rm -rf ~/Library/Developer/Xcode/DerivedData/*

Your next build will re-index symbols and compile clean binaries, immediately reclaiming tens of gigabytes.

3. WhatsApp Desktop Shared Media: The Secret Video Mirror

What creates it?

WhatsApp Desktop uses macOS App Group containers to share data across its sandboxed helper processes and notification services:
~/Library/Group Containers/group.net.whatsapp.WhatsApp.shared

Why it grows

Every video, voice memo, GIF, and PDF shared across your personal chats and work groups is stored in this directory. Even if you clear media on your phone, WhatsApp Desktop often keeps local duplicates on your Mac.

Inspect its size

du -sh ~/Library/Group\ Containers/group.net.whatsapp.WhatsApp.shared 2>/dev/null

How to clean it safely

⚠️ CAUTION: Do not wipe the entire folder. It contains ChatStorage.sqlite, which houses your message history and encryption keys!

Instead, purge only media payloads older than 30 days or larger than 10MB:

# Inspect media size
du -sh ~/Library/Group\ Containers/group.net.whatsapp.WhatsApp.shared/Message/Media 2>/dev/null

# Safely prune video files larger than 10MB while keeping chat history intact
find ~/Library/Group\ Containers/group.net.whatsapp.WhatsApp.shared/Message/Media -type f -size +10M -delete

4. `~/.gradle/caches`: The Multi-Gigabyte JVM Reservoir

What creates it?

If you build Android, React Native, Kotlin, or backend Spring apps, Gradle stores downloaded dependencies (JARs, AARs) and compiler transform outputs inside ~/.gradle/caches.

Why it grows

Gradle preserves dependency resolutions across every wrapper version you've ever compiled. When libraries update, previous versions remain on disk indefinitely.

Inspect its size

du -sh ~/.gradle/caches 2>/dev/null

How to clean it safely

Stop running background daemons first to unlock active files:

# 1. Stop background daemons
./gradlew --stop 2>/dev/null || pkill -f gradle

# 2. Flush cached dependencies and daemons
rm -rf ~/.gradle/caches/*
rm -rf ~/.gradle/daemon/*

Gradle will re-download only the exact dependencies needed on your next build.

5. `~/Library/Containers/com.docker.docker/Data`: The Runaway VM Disk

What creates it?

Because macOS runs the Darwin kernel, Docker Desktop spins up a lightweight Linux VM via Apple's Virtualization.framework. All images, containers, and volumes reside inside a single virtual disk file (Docker.raw).

Why it grows

Docker.raw is an APFS sparse file. As you pull images and build layers, it expands. However, when you delete images or stop containers, APFS does not automatically reclaim unused space, leaving a bloated virtual disk on your Mac SSD.

Inspect its size

du -sh ~/Library/Containers/com.docker.docker/Data 2>/dev/null

How to clean it safely

Avoid rm -rf directly on the disk image while Docker runs. Instead, prune unused Docker objects cleanly:

# 1. Check Docker disk utilization
docker system df

# 2. Prune unused containers, networks, dangling images, and build cache
docker system prune -a --volumes --force

If Docker.raw remains oversized, open Docker Desktop Settings → Resources → Virtual disk limit and adjust the ceiling to trim the allocated sparse file.

Reclaimed Space Summary

Cleaning these five targets produces massive storage gains:

1. User Caches (Slack, Chrome, Spotify): ~15 GB
2. Xcode DerivedData:                    ~40 GB
3. WhatsApp Cached Media:                ~15 GB
4. Gradle Build Caches:                  ~12 GB
5. Docker VM Prune:                      ~25 GB
------------------------------------------------
TOTAL ESTIMATED RECLAIMED SPACE:        ~107 GB

Automating Storage Hygiene with Dusty

Manual terminal maintenance works, but remembering paths, avoiding destructive deletions, and crawling directories manually every few weeks is tedious.

That's why we created Dusty — an AI-powered macOS storage cleaner engineered specifically for developers and power users.

Why Developers Use Dusty:

Google Gemini AI File Explanations: Wondering what an obscure 8GB folder in ~/Library/Caches does? Dusty uses Gemini AI to analyze file headers and explain in plain English what created it and whether it's safe to delete.
Developer Bloat Scanner: Scans for orphaned node_modules, Xcode DerivedData, Gradle artifacts, and Docker overlays across your entire disk in seconds.
Surgical WhatsApp Cleaner: Reclaims heavy media while protecting your SQLite message database.
Trash-First Safety: Files are never erased permanently on first pass; they move safely to the macOS Trash for instant restoration.
Pay Once, Own Forever: No recurring $40/year subscriptions. Just a $9.99 lifetime license (with a 24-hour free trial).

Install Dusty in seconds via Homebrew:

brew install sarmadhussainch/dusty/dusty

Or download the universal binary at dustystorage.com.

Keep Your SSD Healthy

When an APFS SSD dips below 10-15% available storage, wear leveling slows down and swap memory stalls. Running a quick audit on these five hidden folders guarantees your Mac stays fast and responsive.

💬 What is the largest hidden folder you've uncovered on your Mac? Share your findings and favorite cleanup tricks in the comments!

Taming Local Disk Bloat: Where Did My 512GB Mac SSD Go and How to Clean It Safely

Sarmad Hussain — Tue, 13 Oct 2026 13:41:40 +0000

Every developer working on a Mac has encountered that sudden, dreaded system alert:

⚠️ "Your disk is almost full"

You open System Settings → General → Storage, hoping for answers. Instead, macOS gives you a massive, mysterious gray bar labeled:

System Data: 142 GB

What on earth is in that 142 GB? Why is it growing? And more importantly: how do you reclaim it without corrupting your active Git repositories or breaking your dev environment?

In this guide, we'll dissect the real culprits behind hidden developer disk bloat on macOS, provide native Terminal commands to find them, and explain how to clean them safely.

1. The Real Culprits Behind Developer Disk Bloat

Standard Mac cleaners scan for browser cookies, language packs, and user caches. But for developers, those are trivial pennies. The real gigabyte-scale storage hogs are buried in your developer toolchains:

Storage Hog	Typical Size	Where It Hides
Orphaned `node_modules`	20 GB – 80 GB	Forgotten tutorial projects, abandoned feature branches
Xcode `DerivedData` & Simulators	30 GB – 70 GB	`~/Library/Developer/Xcode/DerivedData`
Docker VM Overlays & BuildKit	25 GB – 60 GB	`~/Library/Containers/com.docker.docker/Data/vms`
Gradle & Maven Caches	10 GB – 30 GB	`~/.gradle/caches`, `~/.m2/repository`
Homebrew Downloads & Stale Bottles	5 GB – 15 GB	`~/Library/Caches/Homebrew`
WhatsApp / Slack Desktop Media	15 GB – 40 GB	`~/Library/Group Containers/group.net.whatsapp.WhatsApp.shared`

2. Terminal Deep-Dive: Finding Bloat with Native Commands

Before running third-party scripts, let's inspect our disk using native Unix utilities already built into macOS.

Finding Forgotten `node_modules` Directories

If you've been developing in JavaScript, TypeScript, or React for a couple of years, you likely have dozens of stale projects lingering in your ~/Projects, ~/Sites, or ~/Developer folders.

To find all node_modules folders taking up more than 500MB:

find ~/Projects -name "node_modules" -type d -prune -exec du -sh {} + 2>/dev/null | sort -hr | head -n 20

Warning: Never delete node_modules blindly using global rm -rf scripts while an active project is compiling or using symbolic links.

Finding Xcode DerivedData Bloat

Every time you compile an iOS or macOS app in Xcode, index files, intermediate build objects, and module caches accumulate:

du -sh ~/Library/Developer/Xcode/DerivedData 2>/dev/null

If that folder is over 30 GB, you can safely wipe its contents:

rm -rf ~/Library/Developer/Xcode/DerivedData/*

(Xcode will seamlessly regenerate whatever it needs during your next build).

Inspecting Docker Storage

Docker on macOS runs inside a lightweight Linux virtual machine disk image (Docker.raw or Docker.qcow2). Over time, unreferenced images, stopped containers, and build cache layers expand this virtual disk to maximum capacity:

docker system df

To safely reclaim unused Docker build cache and dangling images:

docker system prune --volumes

3. The Trust Problem: Why Traditional Cleaners Fail Developers

Traditional "one-click" Mac cleaning software operates like an opaque black box:

They report a vague counter: "24.8 GB of System Junk found!"
They ask for full disk access permissions.
They delete files with zero explanation of what they actually were.
And worse: they demand $40/year recurring subscriptions for a basic cron job.

When a cleaner touches a developer's machine, trust is paramount. Deleting a configuration file in ~/Library/Application Support or removing a SQLite database from a local test environment can cost hours of debugging.

4. Introducing Dusty: AI-Explained macOS Storage Management

To solve this trust gap, we built Dusty natively in Swift and SwiftUI.

Dusty is engineered specifically for developers and power users who need complete transparency and surgical control over their disk space.

Key Architectural Pillars:

Plain-English AI Explanations: When inspecting obscure cache files in ~/Library/Caches, Dusty connects to Google Gemini AI to analyze file headers and directory trees. It explains in plain English:
- What application created this file?
- Why is it taking up this much space?
- Is it safe to delete, or will it cause an app to re-index?
Developer Bloat Scanner: Directly targets node_modules, Xcode DerivedData, Docker container overlays, Gradle caches, and .next build caches across all project directories.
Surgical WhatsApp Media Cleaner: Scans WhatsApp Desktop storage and lets you safely reclaim gigabytes of forwarded videos and audio notes without touching your chat history or ChatStorage.sqlite.
Trash-First Safety Architecture: Nothing is permanently deleted without your explicit review. Every cleaned file moves safely to native macOS Trash first, so you can inspect or restore it at any time.
Zero Subscriptions: An honest $9.99 lifetime license (with a 24-hour full free trial). Pay once, own forever.

5. Quick Install via Homebrew

You can install Dusty in seconds directly through Homebrew:

brew install sarmadhussainch/dusty/dusty

Or download the universal binary (Apple Silicon M1/M2/M3/M4 & Intel) directly from the official website:

🔗 https://dustystorage.com

GitHub Tap: https://github.com/sarmadhussainch/homebrew-dusty

Summary Checklist for Developer Disk Hygiene

Run find or use an analyzer to audit old node_modules directories.
Flush ~/Library/Developer/Xcode/DerivedData every few months.
Run docker system prune when disk space dips below 20%.
Clean WhatsApp Desktop forwarded media attachments.
Keep your Mac SSD at least 15% free so APFS wear-leveling and swap memory perform optimally!

What's the biggest storage hog you've discovered on your Mac? Let me know in the comments below!

Why We Built a Zero-Signup, Ephemeral AI Text Humanizer in React

Sarmad Hussain — Thu, 08 Oct 2026 17:09:12 +0000

By Sarmad Hussain — Founder, ClearWrite by I.T & All

The modern web is suffering from severe account fatigue.

Try finding an online text tool today. Within three seconds of landing on the page, you are greeted by an aggressive modal demanding your Google OAuth authorization, an email verification code, or a "Free 3-Day Trial" that asks for your credit card.

Worse, when you paste sensitive work emails, internal memos, or draft assignments into these tools, your raw data is silently saved in their database to train models, build user profiles, or sell enterprise upgrades.

We wanted to build something different: a fast, distraction-free writing workbench with zero signups, zero tracking, and completely ephemeral processing.

Here is how we architected and launched ClearWrite.

The Problem: The "Robotic Sameness" of AI Text

Large language models (ChatGPT, Claude, Gemini) write with an unmistakable digital accent. Even non-technical readers can spot AI text instantly due to three telltale patterns:

Over-synthesized sentence cadence: Every sentence is 18–22 words long, perfectly balanced, and devoid of human rhythm.
Predictable transition words: Overuse of "Furthermore," "Delve," "Testament," "In conclusion," and "Crucial."
Hyper-defensive hedging: Constant caveats ("It is important to remember that...", "While opinions vary...") that weaken persuasive copy.

Existing tools like QuillBot or Wordtune often replace robotic phrases with even clunkier synonyms that sound like a student using a thesaurus for the first time.

We wanted an engine that restructures syntax from the ground up—varying sentence length, injecting colloquial pacing, and preserving genuine human intent.

The 4 Core Writing Workflows

Rather than bundling everything into a bloated, generic "AI rewriter", we engineered 4 distinct, single-purpose modes:

1. Free AI Text Humanizer

Designed for students, content creators, and founders who use LLMs to draft ideas but refuse to publish sterile, robotic prose. It breaks robotic cadence, removes formulaic transition markers, and rewrites sentences with natural human burstiness.

2. Email Tone Checker

In remote workplaces (Slack, Microsoft Teams, Gmail), flat text is easily misinterpreted as passive-aggressive, rude, or overly cold. This mode analyzes interpersonal tone—flagging unintentional condescension, apologizing too much, or sound overly pushy—and suggests polite, assertive phrasing.

3. Simplify Text Online

Engineered for technical writers, medical communicators, and engineers. It strips out dense bureaucratic jargon and translates complex explanations into crisp, accessible 8th-grade readability without dumbing down the core insight.

4. Make Text Professional

A rapid transformation engine that takes messy, casual notes or brain dumps and shapes them into executive-ready communication.

Technical Architecture & Privacy by Design

Here is the tech stack powering ClearWrite:

Frontend: React 18 + Vite for sub-100ms client hydration.
Styling: Tailwind CSS with a zero-friction dark mode interface.
Edge Delivery: Cloudflare CDN with custom cache rules for instant global asset distribution.
Ephemeral Processing Policy:
- When a user submits text (up to 500 words per pass), the payload is processed in-memory and immediately returned.
- Zero logs are retained.
- No user accounts exist in the database. There is literally no user table, no email list, and no session tracking cookies.

Why Ephemeral Software is the Future

As AI becomes commoditized, the real value proposition of utility software isn't more feature bloat—it is respect for user time and privacy.

If a student needs to polish an introduction paragraph before submitting, or a founder needs to check an email tone before hitting send on a high-stakes deal, they shouldn't need to create an account, verify a captcha, and navigate a paywall.

ClearWrite is live, completely free, and open to anyone without an account:
👉 Try it here: https://itandall.com

How to Reclaim 60GB+ of Hidden macOS Bloat Without Paying $40/yr Subscriptions

Sarmad Hussain — Fri, 25 Sep 2026 20:18:05 +0000

If you develop on macOS, you’ve probably seen the dreaded "Disk Full" warning while macOS Storage Settings claims you have 80GB to 120GB of mysterious "System Data".

Commercial utilities often charge steep $40/year recurring subscriptions and mostly scan superficial browser caches, completely ignoring where developer storage actually vanishes.

Here is an architectural breakdown of where that hidden bloat actually lives on modern macOS (Sonoma & Sequoia), the native Terminal commands to inspect them, and how to safely clean them.

1. Orphaned `node_modules` Trees (30GB – 60GB)

Every JavaScript, TypeScript, or frontend project clones its own independent tree of dependencies. If you work on multiple client projects or clone repositories to test, dozens of forgotten node_modules folders sit on your SSD indefinitely.

Terminal Inspection Command:

find ~ -name "node_modules" -type d -prune -exec du -sh {} + 2>/dev/null | sort -hr | head -n 20

Notice: Deleting active project dependencies will break your build until you run npm install again. Only remove node_modules from archived or inactive repositories.

2. WhatsApp Desktop Media Bloat (10GB – 30GB)

WhatsApp Desktop downloads every voice note, video clip, and PDF attachment locally. Even if you delete the chat inside your phone, macOS retains cached local media files inside application containers:

~/Library/Containers/net.whatsapp.WhatsApp/Data/Library/Application Support/WhatsApp/

Crucial Safety Rule: Never touch ChatStorage.sqlite. Only delete cached audio/video attachments.

3. Stale Xcode DerivedData & Simulator Caches (20GB – 50GB)

If you build Swift, Flutter, or React Native apps, Xcode generates gigabytes of intermediate build artifacts, index files, and device logs that are never automatically purged:

~/Library/Developer/Xcode/DerivedData

You can safely remove everything inside DerivedData; Xcode will rebuild it automatically on your next compile.

4. Docker Virtual Disk Overlays (20GB – 40GB)

Docker Desktop creates a raw virtual disk (Docker.raw) that expands dynamically as you pull images, but does not automatically shrink when containers are removed:

docker system prune -a --volumes

The Problem with Blind Automation

Running manual shell commands works, but running rm -rf on obscure ~/Library directories carries real risk of breaking system state or losing important project files.

To solve this, I built Dusty:

AI-Explained Decisions: Uses Google Gemini AI to analyze file metadata and provide a plain-English explanation of what each folder is, what app created it, and whether it is safe or rebuildable.
Developer Bloat Focus: Automatically locates stale node_modules, Xcode caches, Docker overlays, and WhatsApp media.
100% Trash-First: Nothing is permanently erased; files move safely to macOS Trash first.
No Subscriptions: Built with a pay-once, own-forever model ($7.99 lifetime license with a 24-hour full-access free trial).

You can install Dusty directly via Homebrew:

brew install theappcenter/tap/dusty

Or explore the open web version and direct DMG at dustystorage.com.

What’s the largest hidden directory you’ve ever found eating your Mac’s storage? Let me know in the comments below!

Where Did My 512GB Go? How Developers Lose 50GB+ to Node, Docker & macOS Build Artifacts

Sarmad Hussain — Wed, 19 Aug 2026 00:37:22 +0000

If you develop on a MacBook (especially a 256GB or 512GB model), you've probably seen the dreaded "Disk Almost Full" notification.

When you check macOS Storage Settings, Apple simply labels 100GB+ under the ambiguous "System Data" banner.

Here is an honest breakdown of where that disk space actually disappears—and how to reclaim it safely without breaking active projects.

The 4 Biggest Storage Hogs on Developer Macs

1. Orphaned `node_modules` Folders

Every tutorial, side project, and prototype you worked on 6 months ago still has a 500MB–1.5GB node_modules tree sitting quietly on your drive.

If you have 30 inactive repositories, that's 30GB–50GB of pure disk waste.

2. Framework & Bundler Build Artifacts

Modern full-stack toolchains leave heavy caching artifacts:

.next and .nuxt build outputs
.turbo and .parcel-cache
Composer vendor folders

3. Xcode DerivedData & Simulators

Even if you aren't an iOS developer, installing packages with native dependencies or running React Native / Flutter builds causes ~/Library/Developer/Xcode/DerivedData to silently balloon to 20GB+.

4. WhatsApp Desktop & Communication Apps Local Cache

WhatsApp Desktop on macOS caches all incoming media locally at ~/Library/Containers/desktop.WhatsApp/Data/Library/Application Support/WhatsApp/. This can easily consume 15GB–40GB of stale videos and voice notes.

Quick CLI Inspection Commands

To see your top 10 largest folders inside your projects directory:

du -sh ~/Projects/* | sort -rh | head -n 10

To calculate the total space consumed by node_modules across your machine:

find ~/Projects -name "node_modules" -type d -prune -exec du -chs {} +

Why Standard Mac Cleaners Are Risky for Developers

Most generic Mac cleaner utilities search for browser cache and system logs, but they fail developers in two ways:

They ignore developer project artifacts completely.
If they do find them, they delete blindly without explaining whether a folder is rebuildable or critical.

To solve this transparency issue, I built Dusty, an AI-explained macOS storage cleaner tailored specifically for developers.

It classifies files into transparent risk tiers (Safe, Rebuildable, Review First, Never Touch) and uses Gemini AI to give a plain-English explanation before moving anything safely to the macOS Trash.

You can check out our in-depth guide on how developers can clean hidden Mac storage safely.

What's your current Mac cleanup routine?

Do you use shell aliases, npx scripts, or dedicated tools? Share your setup in the comments!

Check redirect chains free: how to inspect 301/302 redirects before launch

Sarmad Hussain — Mon, 11 May 2026 17:31:57 +0000

Redirects are easy to ignore until a launch goes wrong.

A page may look fine in the browser, but the request path can still have problems:

http redirects to https
non-www redirects to www, or the other way around
old URLs redirect to new slugs
tracking links add another hop
a CMS or proxy adds one more redirect without anyone noticing

One redirect is normal. A long chain is where problems start.

Why redirect chains matter

Every redirect adds a request before the visitor reaches the final page. That can slow down crawlers, make analytics harder to read, and hide mistakes that only appear after deployment.

Common examples:

http://example.com/page
-> https://example.com/page
-> https://www.example.com/page
-> https://www.example.com/new-page

That page works, but it takes three hops to reach the final URL.

What to check before launch

Before shipping a site migration, landing page, or SEO update, check:

Does the URL end at the page you expect?
Are there more redirects than necessary?
Are redirects using the right status code?
Is there a redirect loop?
Does the final URL return 200?
Are http, https, www, and non-www variants consistent?

301 vs 302 in plain terms

Use 301 when the move is permanent. This is the usual choice for old pages, changed slugs, and canonical domain redirects.

Use 302 when the move is temporary. This is useful for short campaigns, experiments, or temporary routing.

The important thing is consistency. A permanent URL migration that accidentally uses temporary redirects can create confusion for crawlers and reporting.

A simple redirect audit workflow

Pick the important URLs first:

homepage
top landing pages
pages with backlinks
old URLs from the previous site
paid campaign URLs
sitemap URLs
links used in email or social campaigns

Then inspect each URL and record:

starting URL
every hop
status code for each hop
final URL
final status code

If the final URL is correct and the chain is short, the redirect is probably fine. If there are multiple hops, loops, or unexpected destinations, fix the redirect rules before launch.

Free browser tool

I made a browser-based redirect checker inside I.T & All:

https://itnall.com/tools/redirect-checker?utm_source=devto&utm_medium=article&utm_campaign=redirect-checker

It is useful when you want to check a URL quickly without opening terminal tools or browser devtools.

When terminal tools are better

If you are checking redirects inside CI or auditing hundreds of URLs, use command-line tools or a crawler. For one-off checks, launch QA, and quick debugging, a browser-based checker is usually faster.

Final checklist

Before launch:

Keep redirect chains short.
Prefer one canonical domain.
Use 301 for permanent moves.
Use 302 only for temporary moves.
Make sure the final page returns 200.
Recheck after deployment, not only locally.

Small redirect mistakes are easy to miss, but they are much easier to fix before search engines and users start hitting the new URLs.

DEV Community: Sarmad Hussain

Docker Desktop is Secretly Hoarding 30GB — Here's How to Reclaim It

1. Why Docker on macOS is Fundamentally Different

2. Locating Docker.raw on APFS

The APFS Sparse File Trap: Apparent vs. Physical Size

3. Why Docker's Virtual Disk Never Shrinks

4. Diagnosing Docker Bloat from the Terminal

5. The Step-by-Step Reclamation Guide

Step 1: Purge the BuildKit Cache (The Biggest Hidden Hog)

Step 2: Remove Dangling and Unused Images

Step 3: Remove Stopped Containers

Step 4: Audit Dangling Volumes

6. Docker Cleanup Strategy Matrix

7. Shrinking Docker.raw on APFS

Method A: Docker Desktop Compact

Method B: Resetting the Virtual Disk

8. Automated Intelligence: Dusty's Docker Overlay Detection

How Dusty Handles Docker Storage:

Quick Install via Homebrew:

Final Thoughts

What About Your Machine?

5 Hidden Folders Eating Your Mac's Storage (And How to Safely Reclaim 100GB+)

The 5 Hidden Storage Killers at a Glance

1. ~/Library/Caches: The App Landfill

What creates it?

Why it grows

Inspect its size

How to clean it safely

2. ~/Library/Developer/Xcode/DerivedData: The Build Artifact Monster

What creates it?

Why it grows

Inspect its size

How to clean it safely

3. WhatsApp Desktop Shared Media: The Secret Video Mirror

What creates it?

Why it grows

Inspect its size

How to clean it safely

4. ~/.gradle/caches: The Multi-Gigabyte JVM Reservoir

What creates it?

Why it grows

Inspect its size

How to clean it safely

5. ~/Library/Containers/com.docker.docker/Data: The Runaway VM Disk

What creates it?

Why it grows

Inspect its size

How to clean it safely

Reclaimed Space Summary

Automating Storage Hygiene with Dusty

Why Developers Use Dusty:

Keep Your SSD Healthy

Taming Local Disk Bloat: Where Did My 512GB Mac SSD Go and How to Clean It Safely

1. The Real Culprits Behind Developer Disk Bloat

2. Terminal Deep-Dive: Finding Bloat with Native Commands

Finding Forgotten node_modules Directories

Finding Xcode DerivedData Bloat

Inspecting Docker Storage

3. The Trust Problem: Why Traditional Cleaners Fail Developers

4. Introducing Dusty: AI-Explained macOS Storage Management

Key Architectural Pillars:

5. Quick Install via Homebrew

Summary Checklist for Developer Disk Hygiene

Why We Built a Zero-Signup, Ephemeral AI Text Humanizer in React

The Problem: The "Robotic Sameness" of AI Text

The 4 Core Writing Workflows

1. Free AI Text Humanizer

2. Email Tone Checker

3. Simplify Text Online

4. Make Text Professional

Technical Architecture & Privacy by Design

Why Ephemeral Software is the Future

How to Reclaim 60GB+ of Hidden macOS Bloat Without Paying $40/yr Subscriptions

1. Orphaned node_modules Trees (30GB – 60GB)

Terminal Inspection Command:

2. WhatsApp Desktop Media Bloat (10GB – 30GB)

3. Stale Xcode DerivedData & Simulator Caches (20GB – 50GB)

4. Docker Virtual Disk Overlays (20GB – 40GB)

The Problem with Blind Automation

Where Did My 512GB Go? How Developers Lose 50GB+ to Node, Docker & macOS Build Artifacts

2. Locating `Docker.raw` on APFS

7. Shrinking `Docker.raw` on APFS

1. `~/Library/Caches`: The App Landfill

2. `~/Library/Developer/Xcode/DerivedData`: The Build Artifact Monster

4. `~/.gradle/caches`: The Multi-Gigabyte JVM Reservoir

5. `~/Library/Containers/com.docker.docker/Data`: The Runaway VM Disk

Finding Forgotten `node_modules` Directories

1. Orphaned `node_modules` Trees (30GB – 60GB)

1. Orphaned `node_modules` Folders