Loading page
About this tool
Estimate Git LFS storage growth, monthly bandwidth and GitHub data-pack cost from file sizes, update rate and clone frequency.
This calculator estimates Git LFS server storage, monthly bandwidth and cost from five inputs: tracked file count, average file size, new versions per file per month, a projection horizon and clone frequency. The model reflects how LFS actually behaves — every pushed version is stored forever by default, while a fresh clone downloads only the current version of each file — and prices the result in GitHub data packs ($5/month for 50 GiB storage plus 50 GiB bandwidth, beyond the 1 GiB free tier). It is for game, media and ML teams sizing LFS before committing their first large binaries.
Open Git LFS Storage Estimator on AltFTool — it loads instantly in your browser.
Enter the values you already know.
Fine-tune the options to match your scenario.
Read the result and use it in your planning or reporting.
Accounts for LFS keeping every pushed version, the factor that quietly dominates storage.
Multiplies your clone rate (including CI) by the working set to expose the recurring cost.
Converts overages into whole GitHub data packs and shows whether storage or bandwidth binds.
Every GitHub account gets 1 GiB of free LFS storage and 1 GiB per month of free bandwidth. Beyond that, GitHub's published scheme sells data packs at $5 per month, each adding 50 GiB of storage and 50 GiB of monthly bandwidth. GitHub has also announced metered LFS billing on some plans, so confirm the current model on your account.
Yes — each time a tracked file changes and is pushed, the server keeps the new object alongside all previous ones, and old versions are not garbage-collected by default. A 100 MiB asset updated weekly adds roughly 5 GiB of server storage per year on its own, which is why version frequency matters more than initial size.
No. A standard git clone downloads the full git history but only the LFS objects needed for the checked-out commit — the current version of each tracked file. That is why this estimator computes clone bandwidth as clones × working-set size rather than clones × total storage.
Yes — every CI job that does a fresh clone (or a cache-miss checkout) downloads the LFS working set and it counts against the bandwidth quota. Teams are often surprised that CI, not developers, dominates their LFS bandwidth; caching LFS objects in the CI runner is the standard mitigation.
Add the Git LFS Storage Estimatorwidget to your blog or website — free, responsive, no signup. Just keep the “Widget by AltFTool” credit link visible.
<iframe src="https://www.altftool.com/embed/widget/git-lfs-storage-estimator"
title="Git LFS Storage Estimator — free AltFTool widget"
width="100%" height="640" style="border:0;border-radius:12px;overflow:hidden"
loading="lazy" referrerpolicy="no-referrer-when-downgrade"></iframe>
<p style="font-size:12px;margin:4px 0 0">Widget by <a href="https://www.altftool.com/tools/all/git-lfs-storage-estimator?utm_source=embed&utm_medium=widget">AltFTool — free online tools</a></p>