OpenShift Registry Storage Calculator
Size the internal image registry from image streams, tags retained, shared base layers and daily build churn.
Inputs
Registry Storage Required
327 GiB
Unique Bytes per Extra Tag
180.0MiB
Steady-State Image Storage
228.52GiB
Storage Held by Build Churn
73.83GiB
Daily Growth
6 GiB
Saved by Layer Sharing
51.5%
Step by step
Values used
Image streams = 200 streams; Compressed image size = 450 MiB; Image made of shared base layers = 60 %; Tags retained per stream = 5 tags; Builds per day = 30 builds; Prune retention window = 14 days; Metadata and filesystem overhead = 8 %
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).
Registry Storage Required
= 350,610,259,968
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,115,295,232
Saved by Layer Sharing
= 51.5
How it works
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
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.
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