Helm OCI Registry Storage Calculator
Estimate OCI registry storage for Helm charts published as OCI artifacts, accounting for layer deduplication across versions.
Inputs
Number of distinct chart repositories in the OCI registry.
Average versions retained per chart.
OCI layers per chart version (typically a config layer + a content layer).
Average uncompressed size of a single OCI layer.
Fraction of layers that are unique after content-addressable dedup (0.35 = 65% of layer bytes are shared/duplicate).
Storage After Deduplication
1.85MB
Raw Storage Before Deduplication
5,400.0KB
Storage Saved by Deduplication
65.0%
Step by step
Total layers = charts × versions × layers/version
15 × 10 × 2
= 300 layers
Raw storage before dedup
300 × 18KB
= 5400.0KB
Storage after deduplication
5400.0KB × 0.35
= 1890.0KB (1.85MB)
How it works
Since Helm 3.8, charts can be pushed to any OCI-compliant registry (`helm push`) as OCI artifacts made up of content-addressable layers, typically a small config layer plus one or more content layers holding the packaged chart. Because layers are addressed by content digest, identical layers shared across chart versions — common when only a few files change between releases — are stored once, so real-world storage is the raw layer total scaled down by however much cross-version content actually overlaps.
Formula
dedupedStorage = charts × versions × layersPerVersion × avgLayerSize × deduplicationRatio
- C
- Distinct charts
- V
- Versions per chart
- L
- Average layers per version
- A
- Average layer size in KB
- d
- Deduplication ratio (fraction of unique content)
- S
- Storage after deduplication in KB
Frequently Asked Questions
How is Helm OCI storage different from a classic chart repository?
A classic repo (index.yaml + .tgz files) stores every version as a fully independent blob with no sharing; an OCI registry stores content-addressable layers, so bytes identical across versions (e.g. an unchanged Chart.yaml or templates directory) are only stored once registry-wide.
What typically drives good deduplication ratios?
Charts with frequent patch releases that only tweak a few values or one template tend to dedupe well since most layer content is unchanged; charts that regenerate large CRD bundles or vendored dependencies on every release dedupe poorly.
Do different registries implement dedup the same way?
No — dedup effectiveness depends on the registry's blob storage backend and garbage collection behavior; some registries dedupe globally across all repositories, while others scope deduplication per-repository.