Chapter 2. Red Hat Quay prerequisites

Image storage for Red Hat Quay holds all binary blobs and can be local, highly available, or geo-replicated. You can use local storage for proof of concept or choose supported object storage such as Ceph, Red Hat OpenShift Data Foundation, or cloud providers for production.

The Red Hat Quay database backend stores registry metadata such as users, organizations, images, and tags. PostgreSQL is the preferred database for Red Hat Quay and Clair.

Red Hat Quay stores all of its configuration information in the config.yaml file. Logs can be pushed to ElasticSearch and Splunk if required.

Support for MySQL and MariaDB as the database backend is deprecated since the Red Hat Quay 3.6 release and is planned for removal. Until then, MySQL remains supported according to the support matrix, but does not receive additional features or explicit testing coverage. The Red Hat Quay Operator supports only PostgreSQL deployments when the database is managed. If you want to use MySQL, you must deploy it manually and set the database component to managed: false.

Deploying Red Hat Quay in a highly available (HA) configuration requires that your database services are provisioned for high availability. If Red Hat Quay is running on public cloud infrastructure, use the PostgreSQL services that your cloud provider offers; MySQL is also supported.

Geo-replication requires a single, shared database that is accessible from all regions.

Red Hat Quay uses Redis for ephemeral builder logs. You do not need high availability for Redis because the data is not persistent.

If Redis fails, you will lose access to build logs, builders, and the garbage collector service. Additionally, user events will be unavailable.

You can use a Redis image from the Red Hat Software Collections or from any other source you prefer.