Chapter 8. Advanced configuration
The following sections cover advanced configuration options for when the default deployment settings do not meet your organization’s needs for performance, security, or existing infrastructure integration.
8.1. Using an external PostgreSQL database Copy linkLink copied to clipboard!
When using your own PostgreSQL database with Red Hat Quay, you must ensure that the required configuration and extensions are in place before deployment.
Do not share the same PostgreSQL database between Red Hat Quay and Clair deployments. Each service must use its own database instance. Sharing databases with other workloads is also not supported, because connection-intensive components such as Red Hat Quay and Clair can quickly exceed PostgreSQL’s connection limits.
Connection poolers such as pgBouncer are not supported with Red Hat Quay or Clair.
When managing your own PostgreSQL database for use with Red Hat Quay, the following best practices are recommended:
-
*
pg_trgm
extenion: Thepg_trgm
extension must be enabled on the database for a successful deployment. - Backups: Perform regular database backups using PostgreSQL-native tools or your existing backup infrastructure. The Red Hat Quay Operator does not manage database backups.
- Restores: When restoring a backup, ensure that all Red Hat Quay pods are stopped before beginning the restore process.
- Storage sizing: When using the Operator-managed PostgreSQL database, the default storage allocation is 50 GiB. For external databases, you must ensure sufficient storage capacity for your environment, as the Operator does not handle volume resizing.
- Monitoring: Monitor disk usage, connection limits, and query performance to prevent outages caused by resource exhaustion.
8.1.1. Integrating an existing PostgreSQL database Copy linkLink copied to clipboard!
Configure Red Hat Quay on OpenShift Container Platform to use an existing PostgreSQL database to leverage your current data storage setup.
The following procedure uses the OpenShift Container Platform web console to configure the Red Hat Quay registry to use an external PostgreSQL database. For most users, use the web console is simpler.
This procedure can also be done by using the oc
CLI and following the instructions in "Modifying the QuayRegistry CR by using the CLI" and " Modifying the configuration file by using the CLI".
Procedure
-
On the OpenShift Container Platform web console, click Operators
Installed Operators. - Click Red Hat Quay.
- Click Quay Registry.
- Click the name of your Red Hat Quay registry, for example, example-registry.
- Click YAML.
Set the
postgres
field of theQuayRegistry
CR tomanaged: false
. For example:- kind: postgres managed: false
- kind: postgres managed: false
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Click Save.
-
Click Details
the name of your Config Bundle Secret
resource. -
On the Secret Details page, click Actions
Edit Secret. Add the
DB_URI
field to yourconfig.yaml
file. For example:DB_URI: postgresql://test-quay-database:postgres@test-quay-database:5432/test-quay-database
DB_URI: postgresql://test-quay-database:postgres@test-quay-database:5432/test-quay-database
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Optional: Add additional database configuration fields, such as
DB_CONNECTION_ARGS
or SSL/TLS connection arguments. For more information, see Database connection arguments. - Click Save.
8.2. Using an external Redis database Copy linkLink copied to clipboard!
Redis is a critical component that supports several Red Hat Quay features, such as build logs and user event tracking. When using an externally managed Redis database with Red Hat Quay, you must ensure that it is properly configured and available before deployment.
Do not share the same Redis instance between Red Hat Quay and Clair deployments. Each service must use its own dedicated Redis instance. Sharing Redis with other workloads is not supported, because connection-intensive components such as Red Hat Quay and Clair can quickly exhaust available Redis connections and degrade performance.
8.2.1. Integrating an external Redis database Copy linkLink copied to clipboard!
Configuring Red Hat Quay to use an external Redis database
You can configure Red Hat Quay on OpenShift Container Platform to use an existing Redis deployment for build logs and user event processing.
The following procedure uses the OpenShift Container Platform web console to configure Red Hat Quay to use an external Redis database. For most users, using the web console is simpler.
You can also complete this procedure by using the oc
CLI. For more information, see "Modifying the QuayRegistry CR by using the CLI" and "Modifying the configuration file by using the CLI".
Procedure
-
In the OpenShift Container Platform web console, navigate to Operators
Installed Operators. - Click Red Hat Quay.
- Click QuayRegistry.
- Click the name of your Red Hat Quay registry, for example, example-registry.
- Click YAML.
Set the
redis
component to unmanaged by adding the following entry underspec.components
:- kind: redis managed: false
- kind: redis managed: false
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Click Save.
-
Click Details
the name of your Config Bundle Secret
resource. -
On the Secret details page, click Actions
Edit Secret. In the
config.yaml
section, add entries for your external Redis instance. For example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow ImportantIf both the
BUILDLOGS_REDIS
andUSER_EVENTS_REDIS
fields reference the same Redis deployment, ensure that your Redis service can handle the combined connection load. For large or high-throughput registries, use separate Redis databases or clusters for these components.-
Optional: Add additional database configuration fields, such as
DB_CONNECTION_ARGS
or SSL/TLS connection arguments. For more information, see Redis configuration fields. - Click Save.
8.3. About Horizontal Pod Autoscaling (HPA) Copy linkLink copied to clipboard!
By default, Red Hat Quay deployments include managed Horizontal Pod Autoscalers (HPAs) for key components to ensure availability and performance during load spikes or maintenance events. HPAs automatically adjust the number of running pods based on observed CPU and memory utilization.
A typical Red Hat Quay deployment includes the following pods:
-
Two pods for the Red Hat Quay application (
example-registry-quay-app-*
) -
One Redis pod for Red Hat Quay logging (
example-registry-quay-redis-*
) -
One PostgreSQL pod for metadata storage (
example-registry-quay-database-*
) -
Two
Quay
mirroring pods (example-registry-quay-mirror-*
) -
Two pods for Clair (
example-registry-clair-app-*
) -
One PostgreSQL pod for Clair (
example-registry-clair-postgres-*
)
HPAs are managed by default for the Quay
, Clair
, and Mirror
components, each starting with two replicas to prevent downtime during upgrades, reconfigurations, or pod rescheduling ev
8.3.1. Managing Horizontal Pod Autoscaling Copy linkLink copied to clipboard!
Managing Horizontal Pod Autoscalers (HPA) by setting the HPA component to unmanaged (managed: false
) in the QuayRegistry
custom resource allows you to customize scaling thresholds or replica limits.
The following procedure shows you how to disable the horizontalpodautoscaler
component and explicitly set replicas: null
in the quay
, clair
, and mirror
component definitions.
The following procedure uses the OpenShift Container Platform web console to configure the Red Hat Quay registry to use an external PostgreSQL database. For most users, use the web console is simpler.
This procedure can also be done by using the oc
CLI and following the instructions in "Modifying the QuayRegistry CR by using the CLI" and " Modifying the configuration file by using the CLI".
Procedure
Edit your
QuayRegistry
CR:oc edit quayregistry <quay_registry_name> -n <quay_namespace>
$ oc edit quayregistry <quay_registry_name> -n <quay_namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- After setting
replicas: null
, a new replica set might be generated because theQuay
deployment manifest changes toreplicas: 1
.
Create a custom
HorizontalPodAutoscaler
resource with your desired configuration, for example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Apply the new HPA configuration to your cluster:
oc apply -f <custom_hpa>.yaml
$ oc apply -f <custom_hpa>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
horizontalpodautoscaler.autoscaling/quay-registry-quay-app created
horizontalpodautoscaler.autoscaling/quay-registry-quay-app created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Verification
Verify that your Red Hat Quay application pods are running:
oc get pod | grep quay-app
$ oc get pod | grep quay-app
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
quay-registry-quay-app-5b8fd49d6b-7wvbk 1/1 Running 0 34m quay-registry-quay-app-5b8fd49d6b-jslq9 1/1 Running 0 3m42s quay-registry-quay-app-5b8fd49d6b-pskpz 1/1 Running 0 43m
quay-registry-quay-app-5b8fd49d6b-7wvbk 1/1 Running 0 34m quay-registry-quay-app-5b8fd49d6b-jslq9 1/1 Running 0 3m42s quay-registry-quay-app-5b8fd49d6b-pskpz 1/1 Running 0 43m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Verify that your custom HPA is active:
oc get hpa
$ oc get hpa
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE quay-registry-quay-app Deployment/quay-registry-quay-app 67%/90%, 54%/90% 3 20 3 51m
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE quay-registry-quay-app Deployment/quay-registry-quay-app 67%/90%, 54%/90% 3 20 3 51m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.4. Configuring custom ingress Copy linkLink copied to clipboard!
You can configure custom ingress for Red Hat Quay by disabling the Operator-managed route
component and managing your own routes or ingress controllers. This configuration is useful when your environment requires a custom SSL/TLS setup, specific DNS naming conventions, or when Red Hat Quay is deployed behind a load balancer or proxy that handles TLS termination.
The Red Hat Quay Operator separates route management from SSL/TLS configuration by introducing a distinct tls
component. You can therefore manage each independently, depending on whether Red Hat Quay or the cluster should handle TLS termination. For more information about using SSL/TLS certificates with your deployment, see "Securing Red Hat Quay".
If you disable the managed route
, you are responsible for creating and managing a Route
, Ingress
, or Service
to expose Red Hat Quay. Ensure that your DNS entry matches the SERVER_HOSTNAME
configured in config.yaml
.
8.4.1. Disabling the Route component Copy linkLink copied to clipboard!
Use the following procedure to prevent the Red Hat Quay Operator from creating a route.
Procedure
In your
quayregistry.yaml
file, set theroute
component asmanaged: false
:Copy to Clipboard Copied! Toggle word wrap Toggle overflow In your
config.yaml
file, configure Red Hat Quay to handle SSL/TLS. For example:# ... EXTERNAL_TLS_TERMINATION: false SERVER_HOSTNAME: example-registry-quay-quay-enterprise.apps.user1.example.com PREFERRED_URL_SCHEME: https # ...
# ... EXTERNAL_TLS_TERMINATION: false SERVER_HOSTNAME: example-registry-quay-quay-enterprise.apps.user1.example.com PREFERRED_URL_SCHEME: https # ...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow If the configuration is incomplete, the following error might appear:
{ "reason":"ConfigInvalid", "message":"required component `route` marked as unmanaged, but `configBundleSecret` is missing necessary fields" }
{ "reason":"ConfigInvalid", "message":"required component `route` marked as unmanaged, but `configBundleSecret` is missing necessary fields" }
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.4.2. Configuring SSL/TLS and routes Copy linkLink copied to clipboard!
Support for OpenShift Container Platform edge termination routes is provided through the tls
component. This separation allows independent control of route management and TLS certificate handling.
EXTERNAL_TLS_TERMINATION: true
is the default, opinionated setting, which assumes the cluster manages TLS termination.
-
When
tls
is managed, the cluster’s default wildcard certificate is used. -
When
tls
is unmanaged, you must supply your own SSL/TLS certificate and key pair.
Multiple valid configurations are possible, as shown in the following table:
Option | Route | TLS | Certs provided | Result |
---|---|---|---|---|
My own load balancer handles TLS | Managed | Managed | No | Edge route using default cluster wildcard certificate |
Red Hat Quay handles TLS | Managed | Unmanaged | Yes | Passthrough route with certificates mounted in the Red Hat Quay pod |
Red Hat Quay handles TLS | Unmanaged | Unmanaged | Yes | Certificates set inside the Red Hat Quay pod; user must manually create a route |
8.5. Disabling the monitoring component Copy linkLink copied to clipboard!
When installed in a single namespace, the monitoring
component of the Red Hat Quay Operator must be set to managed: false
, because it does not have permission to create cluster-wide monitoring resources. You can also explicitly disable monitoring in a multi-namespace installation if you prefer to use your own monitoring stack.
Monitoring cannot be enabled when the Red Hat Quay Operator is installed in a single namespace.
You might also disable monitoring in multi-namespace deployments if you use an external Prometheus or Grafana instance, want to reduce resource overhead, or require custom observability integration.
Example unmanaged monitoring configuration
8.6. Disabling the mirroring component Copy linkLink copied to clipboard!
Repository mirroring in Red Hat Quay allows you to automatically synchronize container images from remote registries into your local Red Hat Quay instance. The Red Hat Quay Operator deploys a separate mirroring worker component that handles these synchronization tasks.
You can disable the managed mirroring component by setting it to managed: false
in the QuayRegistry
custom resource.
Disabling managed mirroring means that the Operator does not deploy or reconcile any mirroring pods. You are responsible for creating, scheduling, and maintaining mirroring jobs manually. For most production deployments, leaving mirroring as managed: true
is recommended.
Unmanaged mirroring example YAML configuration
8.7. Configuring QuayRegistry CR resources Copy linkLink copied to clipboard!
You can manually adjust the resources on Red Hat Quay on OpenShift Container Platform for the following components that have running pods:
-
quay
-
clair
-
mirroring
-
clairpostgres
-
postgres
This feature allows users to run smaller test clusters, or to request more resources upfront in order to avoid partially degraded Quay
pods. Limitations and requests can be set in accordance with Kubernetes resource units.
The following components should not be set lower than their minimum requirements. This can cause issues with your deployment and, in some cases, result in failure of the pod’s deployment.
-
quay
: Minimum of 6 GB, 2vCPUs -
clair
: Recommended of 2 GB memory, 2 vCPUs -
clairpostgres
: Minimum of 200 MB
You can configure resource requests on the OpenShift Container Platform UI or directly by updating the QuayRegistry
CR via the CLI.
The default values set for these components are the suggested values. Setting resource requests too high or too low might lead to inefficient resource utilization, or performance degradation, respectively.
8.7.1. Configuring resource requests by using the OpenShift Container Platform web console Copy linkLink copied to clipboard!
Use the following procedure to configure resources by using the OpenShift Container Platform web console.
Procedure
-
On the OpenShift Container Platform developer console, click Operators
Installed Operators Red Hat Quay. - Click QuayRegistry.
- Click the name of your registry, for example, example-registry.
- Click YAML.
In the
spec.components
field, you can override the resource of thequay
,clair
,mirroring
clairpostgres
, andpostgres
resources by setting values for the.overrides.resources.limits
and theoverrides.resources.requests
fields. For example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.7.2. Configuring resource requests by using the CLI Copy linkLink copied to clipboard!
You can re-configure Red Hat Quay to configure resource requests after you have already deployed a registry. This can be done by editing the QuayRegistry
YAML file directly and then re-deploying the registry.
Procedure
Edit the
QuayRegistry
CR by entering the following command:oc edit quayregistry <registry_name> -n <namespace>
$ oc edit quayregistry <registry_name> -n <namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Make any desired changes. For example:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Save the changes.