Skip to content
Calcrivo

OpenShift Registry Storage Calculator

Size the internal image registry from image streams, tags retained, shared base layers and daily build churn.

Inputs

streams
MiB
%

Registries store each layer once, so shared bases are counted only one time.

tags
builds
days
%

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

  1. 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 %

  2. 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).

  3. Registry Storage Required

    = 350,610,259,968

  4. Unique Bytes per Extra Tag

    = 180.0 MiB

  5. Steady-State Image Storage

    = 228.52 GiB

  6. Storage Held by Build Churn

    = 73.83 GiB

  7. Daily Growth

    = 6,115,295,232

  8. 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