Helm Release Size Calculator
Estimate the total manifest size of a Helm release stored in cluster secrets.
About Helm Release Size Calculator
Every Helm install or upgrade stores a full release record — rendered manifests, hook definitions, and NOTES.txt — as a Secret (or ConfigMap) in the release namespace. Because Helm keeps a configurable number of historical revisions for rollback, the actual in-cluster storage footprint is the per-revision payload multiplied by how many revisions are retained, which is easy to underestimate on charts with large CRD manifests.
Formula
totalStorage = (manifests + hooks + notes) × revisions
- M
- Rendered manifests size in KB
- H
- Hooks size in KB
- N
- NOTES.txt size in KB
- R
- Revisions retained
- S
- Total stored size in KB
Worked example
With the default values below, Helm Release Size Calculator returns Size per Revision of 46.00. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Rendered Manifests Sizeaccepts 0–100,000 KB
- 40 KB
- Hooks Sizeaccepts 0–100,000 KB
- 5 KB
- NOTES.txt Sizeaccepts 0–10,000 KB
- 1 KB
- Revisions Retainedaccepts 1–1,000 revisions
- 10 revisions
Results
- Size per Revision
- 46.00 KB
- Total Stored Across Retained Revisions
- 0.449 MB
- Manifests Share of Revision Size
- 87.0%
Step by step
- 1Per-revision size = manifests + hooks + notes= 46.00KB
- 2Total stored across revisions= 460.00KB (0.449MB)
Assumptions and limits
- The result is derived only from the 4 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 3 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
Where does Helm actually store this data?
By default Helm 3 stores each release revision as a base64-encoded, gzip-compressed Secret in the release's namespace (storage backend is configurable to ConfigMaps or SQL).
Why does revision count matter for storage?
Helm keeps a history of past revisions to support `helm rollback`. Each retained revision is a separate stored object, so storage grows linearly with `--history-max` until old revisions are pruned.
How can I reduce release storage size?
Lower `--history-max` (default 10), split very large charts into smaller subcharts, and avoid embedding large static assets or verbose CRDs directly in templated manifests.