Helm Repository Storage Calculator
Project storage needs for a Helm chart repository as versions and charts accumulate.
About Helm Repository Storage Calculator
A classic Helm chart repository (served via ChartMuseum, S3 + index.yaml, GitHub Pages, etc.) stores every published version of every chart as a separate .tgz package, plus a lightweight index.yaml listing metadata for all of them. Total storage scales linearly with the number of charts, how many versions of each are retained, and the average packaged size — with the index.yaml itself usually a negligible fraction of the total once charts number in the dozens.
Formula
storage = charts × versionsPerChart × avgChartSize
- C
- Number of distinct charts
- V
- Versions retained per chart
- P_{avg}
- Average chart package size in KB
- S
- Total repository storage in KB
Worked example
With the default values below, Helm Repository Storage Calculator returns Total Repository Storage of 8.79. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Distinct Chartsaccepts 1–100,000 charts
- 20 charts
- Versions per Chartaccepts 1–10,000 versions
- 15 versions
- Average Chart Package Sizeaccepts 0.1–1,000,000 KB
- 30 KB
Results
- Total Repository Storage
- 8.79 MB
- Total Chart Versions Stored
- 300 versions
- Total Repository Storage
- 0.0086 GB
Step by step
- 1Total versions = charts × versions per chart= 300 versions
- 2Storage = total versions × avg chart size= 9000.0KB (8.79MB)
Assumptions and limits
- The result is derived only from the 3 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to 4 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
Frequently Asked Questions
Does index.yaml storage matter at scale?
It can — index.yaml grows with every version of every chart since it embeds full Chart.yaml metadata per entry, so repositories with thousands of versions can end up with multi-MB index files that slow down `helm repo update`, separate from package storage.
How do I reduce chart repository storage?
Prune old pre-release or superseded versions, deduplicate large static assets by keeping them out of the chart (reference external images/manifests instead), and compress ChartMuseum storage backends where supported.
Is OCI-based storage different from a classic chart repo?
Yes — OCI registries (Helm's default since 3.8) store charts as OCI artifacts with content-addressable layers, which can deduplicate identical layers across versions, unlike a classic repo where every .tgz is a fully independent blob.