Project storage needs for a Helm chart repository as versions and charts accumulate.
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.
storage = charts × versionsPerChart × avgChartSize
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.
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.
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.