Git LFS Storage & Bandwidth Planner
Forecast retained binary versions and full-download demand against user-entered storage and bandwidth quotas.
Plan LFS quotasSource-to-runner capacity workflow
Developer Build Storage Planning
Turn binary version growth, CI retention, cache churn, image layers, and concurrent runner jobs into explicit storage and quota decisions.
CI Artifact Retention Planner
Translate artifact-producing runs and retention days into a steady rolling footprint and maximum quota-safe policy.
Plan artifact retentionBuild Cache Capacity & Churn Planner
Estimate new cache-key churn, desired cache footprint, and the effective window supported by a fixed quota.
Plan cache capacityContainer Registry Retention Planner
Separate shared base layers, per-image changes, tagged retention, and bytes waiting for garbage collection.
Plan registry storageSelf-hosted Runner Disk Capacity Checker
Combine checkout, dependencies, caches, outputs, temporary files, and job concurrency into a peak workspace check.
Check runner diskOne build can occupy several independent storage systems
Large source objects may live in Git LFS, a runner creates a temporary checkout and dependency tree, caches preserve reusable work, artifacts retain job outputs, and registries store deployable image layers. Counting only the final package misses the pressure that causes quota charges, evictions, or “no space left” job failures. Keep each storage class separate, then connect their assumptions in one operating record.
Read How to Plan Storage for Git LFS, CI Builds & Container Images and audit the equations in the Developer Build Storage & Retention Formulas.
Recommended workflow
Follow bytes from source history to disposable workspace
Where to start
Start with the resource that is already approaching a limit. Use the LFS planner for binary source history and repeated downloads, the artifact planner for retained job outputs, the cache planner for cache-key turnover, the registry planner for layers and garbage collection, or the runner checker for an active workspace that fills during concurrent jobs. These tools intentionally do not combine quotas that a platform accounts separately.
Recommended workflow
Measure one representative release and one representative CI job. Forecast LFS versions, set an artifact policy, estimate cache churn, model image-layer retention, and finally check peak runner concurrency. Re-run the sequence after adding a platform, branch policy, matrix build, larger dependency set, new image base, or more runner slots. Save the entered quota source and measurement date beside each result.
What to prepare
Bring current usage and quota reports, LFS payload and change rate, artifact size after compression, producing runs per day, cache entry size and new-key rate, compressed image and shared-layer estimates, registry deduplication scope, garbage-collection delay, per-job workspace measurements, concurrency, and desired reserve. Use current platform documentation rather than assuming that a tag deletion or expired object immediately frees billed bytes.
What to do next
Apply the smallest policy change that fixes the identified constraint: reduce binary version growth, narrow artifact retention, stabilize cache keys, clean unreferenced image layers, or reduce runner concurrency. Then measure actual usage after a complete policy cycle. Use the Local Network Transfer Time Calculator only after storage demand is known, and the VM & Container SSD Endurance Planner when persistent write endurance—not peak capacity—is the next decision.