2026 Six-Region Remote Mac Out of Disk? 1TB/2TB Upgrade vs Cache Cleanup vs Second Machine—FinOps Pick-One Decision Matrix

Six pain points teams misread when a remote Mac runs out of disk

1. Treating reclaimable bloat as structural shortage. DerivedData, old Simulator runtimes, Docker layers, and Gradle caches often account for 40–70% of recoverable space. Only when a weekly cleanup still drops free space below 15% within seven days should you open the upgrade-or-second-machine discussion.
2. Watching df percentages without directory attribution. APFS snapshots, local Time Machine snapshots, and “Other users” buckets can paint the root volume red while the real Xcode drag is a single directory growing linearly. Use layered du sampling—not a blind rm -rf.
3. Assuming more disk fixes CPU or memory queues. When iostat shows disk utilization below 40% for long stretches yet builds stay slow, the limit is parallelism or linker memory. An M4 Pro or a second machine beats 2TB in that profile.
4. Running Monorepo plus multiple Simulators on a 256GB baseline. Partial clone shrinks fetch size, but local intermediates and simulator images still accumulate per branch and OS version. Read alongside the Monorepo slim-down checklist instead of reinventing it.
5. One node doing everything across six regions. Build, UI test, and signing upload on the same disk means peak weeks hit every watermark at once. The multi-machine build-pool FinOps runbook covers role split; here we decide single-node disk policy first, then whether a second machine is worth it.
6. Monthly disk upgrades for a two-week sprint, or daily wipes for a year-long baseline. FinOps rule: predictable permanent growth fits 1TB/2TB locked with monthly or quarterly leases; short spikes fit cleanup plus a daily-rent peak machine—do not lock a year tier for fourteen days.

Dedicated remote Macs give you a clear physical disk boundary, but clarity does not auto-match workload. On Apple Silicon unified memory, disk pressure and RAM pressure often move together: parallel Simulators, Swift incremental compiles, and container layer caches raise IO and memory at once. Without a pick-one decision, teams bounce between “clean the disk again” and “add another box,” wasting lease budget and slowing releases.

The multi-region node rental cost guide answers which country and lease length to pick; this article answers first-order disk handling on the node you already chose. It complements the CocoaPods/SPM mirror and disk checklist—dependency tuning reduces false-full signals but cannot replace DerivedData and simulator asset governance.

Six-step runbook: from sampling to a signed pick-one branch

1. Freeze the watermark baseline. Record total capacity, free percentage, main mount points; note node ID, Xcode version, and last cleanup commit (script version).
2. Layered du sampling (top 12 directories). Sample ~/Library/Developer, DerivedData, CoreSimulator, ~/.gradle, ~/Library/Containers, etc.; export CSV for audit.
3. Run the standard cleanup pack. In order: DerivedData (keep current scheme if needed), unused Simulator runtimes, dangling Docker images, old Archives (confirm with release owner).
4. Retest 24h slope. If free space drops more than three percentage points per day without an explained release event, mark structural growth.
5. Map to the matrix branch. Cache governance / 1TB·2TB / second machine—do not deploy cleanup + upgrade + extra machine without written rationale.
6. Lock FinOps notes and lease term. Structural → monthly/quarterly + upgrade; short peak → daily/weekly second machine; record review date in the ledger.

# Top directory sampling on the remote Mac (replace WORK path)
export WORK="$HOME"
df -h /
echo "---- top dirs under Library/Developer ----"
du -hd 1 "$HOME/Library/Developer" 2>/dev/null | sort -hr | head -12
echo "---- DerivedData total ----"
du -sh "$HOME/Library/Developer/Xcode/DerivedData" 2>/dev/null
echo "---- CoreSimulator ----"
du -sh "$HOME/Library/Developer/CoreSimulator" 2>/dev/null

Three quantitative thresholds for the review meeting (replace constants with your baseline)

• Cleanup yield ratio. Standard cleanup should reclaim at least 18% of currently used space; below 12% means growth is structural—enter the upgrade/second-machine matrix instead of repeating cleanup.
• Free-space red line. Production build hosts should keep ≥20% free; below 15%, block full Archive plus parallel UI tests (share gate fields with the POC scale-up KPI matrix).
• Post-upgrade IO check. Within 48h after 1TB/2TB expansion, if median disk busy% stays below 25% and build time does not improve, close the “add more disk” option in review and inspect CPU, memory, and artifact RTT.

Close: do not hide architecture splits behind “one more disk”

On six-region remote Macs, disk decisions come down to separating incompressible working sets from compressible caches. Reclaimable → govern; not reclaimable → upgrade or split machines; not reclaimable and compute-saturated → stop buying disk—that only comforts a queue bottleneck.

Self-hosted Mac colocation or short-lived cloud instances often split “disk” and “ops” into two invoices, so teams underestimate the compound cost of snapshots, simulator assets, and shared disks. Laptop handoffs hit disk and sleep policy at the same time during release weeks. For teams that need dedicated Apple Silicon, predictable disk tiers, and six-region nodes, attaching this matrix to procurement and aligning 1TB/2TB with lease terms on MACCOME Mac cloud usually beats ad-hoc disk adds or blind second machines—and gives CI and on-call the same watermark language.

Once you lock upgrade or second machine, bring region and lease line items into the same review. Pricing and cycle details stay on the product page; keep stability acceptance and Monorepo articles as attachments so release week discusses capacity and pipeline together.