Binary source quota forecast

Git LFS Storage & Bandwidth Planner

Estimate retained large-file versions and typical monthly full-download demand without hardcoding a provider's changing allowance or price.

Decision guide

Forecast version history separately from downloads

What this tool helps you decide

This planner answers two related but independently constrained questions: how much Git Large File Storage history a release process may retain, and how much LFS payload developers or continuous-integration jobs may download in a typical month. It is useful for game assets, design exports, machine-learning fixtures, media, and other binaries that do not belong in ordinary Git objects. The result shows both headroom values, an approximate storage-quota crossing point, and the number of full downloads the entered bandwidth quota can support.

Before you start

Copy current LFS storage and quota values from the host's current billing or usage page. Measure how many genuinely new or changed LFS bytes one representative release introduces; do not use the complete checkout size for version growth unless every object changes. Record release cadence and the time old binary versions remain reachable under your policy. For download demand, measure the LFS payload fetched by a clean checkout and count developer clones, clean agents, CI jobs, deployments, and other downloads that the platform documents as chargeable.

How the calculation works

Monthly stored growth equals changed LFS gigabytes per release multiplied by releases per month. Projected storage adds that growth for the shorter of the planning horizon and entered retention window. Monthly bandwidth equals the full-download payload multiplied by full downloads per month. Each projection is compared with its user-entered quota. Months to storage quota divides remaining storage allowance by monthly growth; maximum full downloads divides bandwidth quota by the payload. Decimal gigabytes are used consistently, and no current provider allowance or price is embedded.

How to interpret the results

A pass on storage does not imply a pass on bandwidth. A repository with modest version growth can still consume download allowance when clean CI agents fetch the same LFS payload repeatedly. A bandwidth pass can coexist with a long-term storage problem when large binary objects change frequently. Negative headroom identifies the size of the modeled shortfall, not an invoice. Compare the provider's actual accounting scope, included allowance, reset period, caching behavior, and retention controls before changing a plan.

Worked example

Suppose current LFS storage is 80 GB, each of four monthly releases introduces 6 GB of changed binary data, and versions are retained for a 12-month horizon. The projected store is 368 GB: 80 GB current plus 288 GB of retained growth. If a clean checkout fetches 24 GB and the team performs 30 full downloads each month, modeled bandwidth is 720 GB. Entered quotas of 500 GB storage and 1,000 GB monthly bandwidth leave 132 GB and 280 GB of headroom.

Assumptions and limitations

The model treats the entered change amount as unique retained bytes and uses a stable release cadence. It does not inspect Git history, detect duplicate objects, predict compression, determine whether a specific download is billable, model regional egress, or reproduce a vendor invoice. Rewritten history, deleted references, delayed reclamation, forks, archives, pull requests, caching, and host-specific object accounting can change observed usage. The provider's current documentation and usage report remain authoritative.

Next steps

Save the measurement date, quota source, release sample, and included download categories with the result. If storage is the constraint, reduce changed binary volume, shorten retention where recovery policy permits, or move generated assets outside source history. If downloads are the constraint, investigate persistent workspaces or a documented cache before suppressing required validation. Continue to the Runner Disk Capacity Checker for clean-checkout workspace demand and the Developer Build Storage Formulas for an independent equation audit.