Skip to content
ENExplore Calculators

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

  1. 1Values used
  2. 2OpenShift Registry Storage
  3. 3Registry Storage Required= 350,610,259,968
  4. 4Unique Bytes per Extra Tag= 180.0 MiB
  5. 5Steady-State Image Storage= 228.52 GiB
  6. 6Storage Held by Build Churn= 73.83 GiB
  7. 7Daily Growth= 6,115,295,232
  8. 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.

OpenShift Registry Storage Calculator | Calcrivo