OpenShift Registry Storage Calculator
Size the internal image registry from image streams, tags retained, shared base layers and daily build churn.
About OpenShift Registry Storage Calculator
A container registry is content-addressed, so it stores each layer once no matter how many images reference it. A second tag of the same application therefore costs only its application layers, not the whole image. Build churn is what actually fills registries: CI produces new layers all day and they persist until the pruner's retention window expires. Registry storage is the most commonly under-sized persistent volume in an OpenShift cluster, and a full registry breaks builds and deployments simultaneously — while an aggressive pruner breaks rollbacks instead.
Formula
OpenShift Registry Storage
storage = (streams × (image + (tags − 1) × unique layer bytes) + builds per day × retention × unique layer bytes) × (1 + overhead), where unique layer bytes = image × (1 − shared base share).
- unique layer bytes
- Bytes a new tag actually adds once shared base layers are excluded
- build churn
- Images produced by CI that pruning has not yet removed
- retention window
- Days the pruner keeps untagged and superseded images
Worked example
With the default values below, OpenShift Registry Storage Calculator returns Registry Storage Required of 327 GiB. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Image streamsaccepts 1–100,000 streams
- 200 streams
- Compressed image sizeaccepts 1–102,400 MiB
- 450 MiB
- Image made of shared base layersaccepts 0–95 %
- 60 %
- Tags retained per streamaccepts 1–200 tags
- 5 tags
- Builds per dayaccepts 0–20,000 builds
- 30 builds
- Prune retention windowaccepts 1–365 days
- 14 days
- Metadata and filesystem overheadaccepts 0–40 %
- 8 %
Results
- Registry Storage Required
- 327 GiB
- Unique Bytes per Extra Tag
- 180.0 MiB
- Steady-State Image Storage
- 228.52 GiB
- Storage Held by Build Churn
- 73.83 GiB
- Daily Growth
- 6 GiB
- Saved by Layer Sharing
- 51.5%
Step by step
- 1Values used
- 2OpenShift Registry Storage
- 3Registry Storage Required= 350,610,259,968
- 4Unique Bytes per Extra Tag= 180.0 MiB
- 5Steady-State Image Storage= 228.52 GiB
- 6Storage Held by Build Churn= 73.83 GiB
- 7Daily Growth= 6,115,295,232
- 8Saved by Layer Sharing= 51.5
Assumptions and limits
- The result is derived only from the 7 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 2 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
How is OpenShift Registry Storage calculated?
storage = (streams × (image + (tags − 1) × unique layer bytes) + builds per day × retention × unique layer bytes) × (1 + overhead), where unique layer bytes = image × (1 − shared base share). A container registry is content-addressed, so it stores each layer once no matter how many images reference it. A second tag of the same application therefore costs only its application layers, not the whole image. Build churn is what actually fills registries: CI produces new layers all day and they persist until the pruner's retention window expires.
Why does OpenShift Registry Storage matter?
Registry storage is the most commonly under-sized persistent volume in an OpenShift cluster, and a full registry breaks builds and deployments simultaneously — while an aggressive pruner breaks rollbacks instead.
What values do I need to enter?
This calculator takes 7 inputs: Image streams, Compressed image size, Image made of shared base layers, Tags retained per stream, Builds per day, Prune retention window, Metadata and filesystem overhead. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
Why does pruning retention matter more than image size?
Steady-state image storage is bounded by streams times tags, but build churn is unbounded until the pruner runs. Thirty builds a day retained for a fortnight can hold more storage than every tagged release in the registry combined.
Related Calculators
- OpenShift Project Quota Calculator
- OpenStack Swift Storage Calculator
- OpenShift Upgrade Time Calculator
- OpenShift Node Capacity Calculator
- Hypervisor Consolidation Calculator
- VMware VM Density Calculator
- OpenShift Cluster Health Calculator
- OpenShift Pod Density Calculator
- OpenShift Route Capacity Calculator
- OpenStack Cinder Storage Calculator
You might also need
- OpenStack Swift Storage CalculatorCommonly used together
- OpenShift Project Quota CalculatorCommonly used together
- OpenShift Upgrade Time CalculatorCommonly used together
- OpenShift Node Capacity CalculatorAlso in Virtualization & Private Cloud
- Hypervisor Consolidation CalculatorAlso in Virtualization & Private Cloud
- VMware VM Density CalculatorAlso in Virtualization & Private Cloud
