Helm Release Size Calculator
Estimate the stored size of a Helm release revision from its rendered manifests, hook definitions, and NOTES.txt output.
Inputs
Total size of all rendered Kubernetes manifest YAML for this release.
Combined size of pre/post-install, pre/post-upgrade and other hook manifests.
Size of the rendered NOTES.txt shown after install/upgrade.
Number of historical revisions Helm keeps as Secrets/ConfigMaps in-cluster.
Size per Revision
46.00KB
Total Stored Across Retained Revisions
0.449MB
Manifests Share of Revision Size
87.0%
Step by step
Per-revision size = manifests + hooks + notes
40KB + 5KB + 1KB
= 46.00KB
Total stored across revisions
46.00KB × 10
= 460.00KB (0.449MB)
How it works
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
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.