Skip to main content
logoTetrate Patch ServiceVersion: alpha

Understanding the Release Catalog

The release catalog is the single source of truth for what Tetrate has released: which components exist, which versions of each are out, and the exact images that make them up. Everything in Tetrate Patch Service that says "newer" or "ours" says it by consulting the catalog, so categorization, upgrade markers, and upgrade pull requests can never disagree about what the latest release is.

What Release Manifests Are​

The catalog is a set of release manifests, one machine-readable JSON file per component. Each manifest records the component's latest version and, for every released version, its release date and the exact image references that ship it, pinned by registry-verified digests per platform.

The catalog is published to a public CDN and needs no authentication, so your own tooling can consume the same data the Patch Service does: pin exact digests in your own automation, alert on new releases, or audit what a version contains.

Image Variants​

A release often ships an image in more than one build flavor, for example a distroless build and a FIPS build. Manifests record each flavor as an image variant, and everything that matches images against the catalog matches like for like: a cluster running the FIPS build of a component gets FIPS upgrade targets, never a suggestion to hop to another flavor. An upgrade target is always the latest release of the image's own variant.

How the Catalog Is Used​

Three things in the Patch Service read the catalog:

  • Finding categorization. Every CVE finding is categorized by comparing its image against the catalog: behind the latest release means actionable, with the latest release as the upgrade target; already on the latest release means pending, because the fix has to arrive in a future release; absent from every manifest means third party, an image Tetrate does not distribute.
  • Upgrade markers. The orange Upgrade available arrows in the Clusters view name the catalog's latest release for each image that has fallen behind.
  • Upgrade pull requests. On the managed data plane, a scheduled job in your repository compares your pinned versions against the catalog and opens an upgrade pull request when one falls behind.

Because all three read the same catalog, they always agree: the version an actionable finding names is the version the orange arrow shows and the version the pull request bumps to.

How Releases Are Published​

A catalog entry is added when Tetrate publishes a release, and the pipeline is built so an entry can never point at an image that does not exist: every reference and digest is verified against the registry before the entry is proposed, and a human reviews and merges the change.

Publishing a release also triggers an immediate re-scan of the fleet, so categorization is never stale: the moment a fixing release exists, pending findings it fixes re-categorize to actionable and the upgrade targets update, without waiting for the nightly scan.

Next Steps​