Image lifecycle

Every image in the public catalogue follows the same lifecycle. No special cases, no hidden tracks.

Build

Each image is built from a minimal source recipe held in this repo at registry/. The recipe declares:

• The upstream package source and version.
• The OCI base (usually a scratch or a minimal hardened base we maintain in-house).
• The exact set of packages and versions to include.
• An entrypoint and a default user.

Builds are reproducible: given the same input recipe, you get a bit-identical image. We test reproducibility on every release.

Daily rebuild

Every image is rebuilt every 24 hours against the latest advisory data, even if no recipe changed. This is the patch loop.

If the daily rebuild produces an image with a different content digest from yesterday, that digest is signed, scanned, and published as the new latest tag. Stable tags (postgres:17, postgres:17.2) are rotated to point at the new digest.

If you pin by digest, you do not float — your image stays the same until you choose to upgrade.

Patch promise

For each image we publish a patch SLA in the open, measured from upstream advisory publication to a signed, scanned, published image:

• Critical (CVSS ≥ 9.0): patched and published within 24 hours.
• High (7.0 – 8.9): within 72 hours.
• Medium / Low: within the daily rebuild cycle.

If we miss this, we say so on the blog.

Tag rotation

For production, pin by digest. For development, pin by :<major.minor> and let the patches flow.

Deprecation

We deprecate an image only when its upstream is end-of-life. Deprecation is announced on the blog at least 90 days before the final build, and surfaces on the catalogue listing.