Glossary of Terms

This page defines the terminology used throughout this section for further clarity.


Red Hat Partner Connect

The Red Hat Technology Partner portal website resolved by

Red Hat Ecosystem Catalog

The official Red Hat software catalog for containers, operators and other software from both Red Hat and Technology Partners, as resolved by

Red Hat Container Catalog / RHCC Registry

Often abbreviated as the RHCC registry or simply RHCC, this is the container image registry provided by Red Hat for hosting partner-provided, certified container images. It is resolved by

External Registry

This is any container image registry that is not hosted by Red Hat, such as, or any other third party or private image registry.

Scan Registry

The scan registry is the Red Hat internal registry or staging area used during the container image scanning process. It is kept behind the scenes, and is not a point of user interaction for multi-arch images.


A project is analogous to a container image repository and exists within the context of the Red Hat Partner Connect website. You typically need a project created for every container image that you intend to certify.


In this section, the term operator generally refers to the operator's container (or controller) image.


The operand is the operator's workload container image. There can be, and often are multiple operand images for any particular operator.


The directory containing the operator deployment manifests/ and metadata/ directories, and optionally the tests/ directory for additional custom tests. It is usually named for the release version it deploys (such as 1.0.0/). This is what gets submitted to GitHub per the operator release workflow.


The SHA 256 digest of a particular container image (which is actually the digest of the manifest for that image).


The metadata or descriptor file of a container image. This contains the labels applied when the image was created, a list of the layers within the image along with their respective digests, and other descriptive information. This file should conform to the OCI specification.

Manifest List

This is a type of manifest which is nothing more than a list of other manifests (by their respective digest and architecture). The list usually contains one manifest for each supported CPU architecture. The intent is to support a single multi-arch image that could match the corresponding architecture of the machine it's being run on. This is also defined in the OCI spec.

Did we miss anything? If you find a confusing term anywhere in this section, please let us know and we'll get it added to the list above.

Last updated