Chapter 9. Component and feature configuration fields
The Component and Feature Configuration section describes the configurable fields available for fine-tuning Red Hat Quay across its various subsystems. These fields allow administrators to customize registry behavior, enable or disable specific features, and integrate with external services and infrastructure. While not required for a basic deployment, these options support advanced use cases related to security, automation, scalability, compliance, and performance.
9.1. Core configuration overview Copy linkLink copied to clipboard!
The following core configuration fields set the registry hostname, protocol, authentication, and other fundamental Red Hat Quay behavior.
9.1.1. Registry branding and identity fields Copy linkLink copied to clipboard!
Customize registry branding, contact information, and footer links that appear in the Red Hat Quay user interface.
The following configuration fields allow you to modify the branding, identity, and contact information displayed in your Red Hat Quay deployment. With these fields, you can customize how the registry appears to users by specifying titles, headers, footers, and organizational contact links shown throughout the UI.
Some of the following fields are not available on the Red Hat Quay v2 UI.
| Field | Type | Description |
|---|---|---|
| REGISTRY_TITLE | String |
If specified, the long-form title for the registry. Displayed in frontend of your Red Hat Quay deployment, for example, at the sign in page of your organization. Should not exceed 35 characters. Default: |
| REGISTRY_TITLE_SHORT | String |
If specified, the short-form title for the registry. Title is displayed on various pages of your organization, for example, as the title of the tutorial on your organization’s Tutorial page. Default: |
| CONTACT_INFO | Array of String | If specified, contact information to display on the contact page. If only a single piece of contact information is specified, the contact footer will link directly. |
| [0] | String |
Adds a link to send an e-mail. Pattern: |
| [1] | String |
Adds a link to visit an IRC chat room. Pattern: |
| [2] | String |
Adds a link to call a phone number. Pattern: |
| [3] | String |
Adds a link to a defined URL. Pattern: |
| Field | Type | Description |
|---|---|---|
| BRANDING | Object | Custom branding for logos and URLs in the Red Hat Quay UI. |
| .logo (Required) | String |
Main logo image URL. The header logo defaults to 205x30 PX. The form logo on the Red Hat Quay sign in screen of the web UI defaults to 356.5x39.7 PX. Example: |
| .footer_img | String |
Logo for UI footer. Defaults to 144x34 PX. Example: |
| .footer_url | String |
Link for footer image. Example: |
| Field | Type | Description |
|---|---|---|
| FOOTER_LINKS | Object | Enable customization of footer links in Red Hat Quay’s UI for on-prem installations. |
| .TERMS_OF_SERVICE_URL | String |
Custom terms of service for on-prem installations. Example: |
| .PRIVACY_POLICY_URL | String |
Custom privacy policy for on-prem installations. Example: |
| .SECURITY_URL | String |
Custom security page for on-prem installations. Example: |
| .ABOUT_URL | String |
Custom about page for on-prem installations. Example: |
Registry branding and identity example YAML
# ...
REGISTRY_TITLE: "Example Container Registry"
REGISTRY_TITLE_SHORT: "Example Quay"
CONTACT_INFO:
- mailto:support@example.io
- irc://chat.freenode.net:6665/examplequay
- tel:+1-800-555-1234
- https://support.example.io
BRANDING:
logo: https://www.mend.io/wp-content/media/2020/03/5-tips_small.jpg
footer_img: https://www.mend.io/wp-content/media/2020/03/5-tips_small.jpg
footer_url: https://opensourceworld.org/
FOOTER_LINKS:
"TERMS_OF_SERVICE_URL": "https://www.index.hr"
"PRIVACY_POLICY_URL": "https://www.example.hr"
"SECURITY_URL": "https://www.example.hr"
"ABOUT_URL": "https://www.example.hr"
# ...
9.1.2. SSL/TLS configuration fields Copy linkLink copied to clipboard!
Configure SSL/TLS settings, hostname, cipher suites, and session cookie security for Red Hat Quay.
This section describes the available configuration fields for enabling and managing SSL/TLS encryption in your Red Hat Quay deployment.
Additional resources
| Field | Type | Description |
|---|---|---|
| PREFERRED_URL_SCHEME | String |
One of |
| SERVER_HOSTNAME (Required) | String |
The URL at which Red Hat Quay is accessible, without the scheme Example: |
| SSL_CIPHERS | Array of String |
If specified, the nginx-defined list of SSL ciphers to enabled and disabled Example: [ |
| SSL_PROTOCOLS | Array of String |
If specified, nginx is configured to enabled a list of SSL protocols defined in the list. Removing an SSL protocol from the list disables the protocol during Red Hat Quay startup. Example: |
| SESSION_COOKIE_SECURE | Boolean |
Whether the |
| EXTERNAL_TLS_TERMINATION | Boolean |
Set to |
SSL configuration example YAML
# ...
PREFERRED_URL_SCHEME: https
SERVER_HOSTNAME: quay-server.example.com
SSL_CIPHERS:
- ECDHE-RSA-AES128-GCM-SHA256
SSL_PROTOCOLS:
- TLSv1.3
SESSION_COOKIE_SECURE: true
EXTERNAL_TLS_TERMINATION: true
# ...
9.1.3. IPv6 configuration field Copy linkLink copied to clipboard!
Use the FEATURE_LISTEN_IP_VERSION field to configure whether Red Hat Quay listens on IPv4, IPv6, or dual-stack networks.
You can use the FEATURE_LISTEN_IP_VERSION configuration field to specify which IP protocol family Red Hat Quay should listen on: IPv4, IPv6, or both (dual-stack). This field is critical in environments where the registry must operate on IPv6-only or dual-stack networks.
| Field | Type | Description |
|---|---|---|
| FEATURE_LISTEN_IP_VERSION | String |
Enables IPv4, IPv6, or dual-stack protocol family. This configuration field must be properly set, otherwise Red Hat Quay fails to start. Default: |
IPv6 example YAML
# ...
FEATURE_LISTEN_IP_VERSION: dual-stack
# ...
9.1.4. Logging and debugging variables Copy linkLink copied to clipboard!
Configure logging, debugging, and health check variables for troubleshooting Red Hat Quay.
The following variables control how Red Hat Quay logs events, exposes debugging information, and interacts with system health checks. These settings are useful for troubleshooting and monitoring your registry
| Variable | Type | Description |
|---|---|---|
| DEBUGLOG | Boolean | Whether to enable or disable debug logs. |
| USERS_DEBUG |
Integer. Either |
Used to debug LDAP operations in clear text, including passwords. Must be used with + Important
Setting |
| ALLOW_PULLS_WITHOUT_STRICT_LOGGING | Boolean | If true, pulls will still succeed even if the pull audit log entry cannot be written . This is useful if the database is in a read-only state and it is desired for pulls to continue during that time. Default: False |
| ENABLE_HEALTH_DEBUG_SECRET | String | If specified, a secret that can be given to health endpoints to see full debug info when not authenticated as a superuser |
| HEALTH_CHECKER | String |
The configured health check Example: |
| FEATURE_AGGREGATED_LOG_COUNT_RETRIEVAL | Boolean | Whether to allow retrieval of aggregated log counts Default: True |
Logging and debugging example YAML
#...
DEBUGLOG: true
USERS_DEBUG: 1
ALLOW_PULLS_WITHOUT_STRICT_LOGGING: "true"
ENABLE_HEALTH_DEBUG_SECRET: "<secret_value>"
HEALTH_CHECKER: "('RDSAwareHealthCheck', {'access_key': 'foo', 'secret_key': 'bar'})"
FEATURE_AGGREGATED_LOG_COUNT_RETRIEVAL: true
# ...
Additional resources
9.1.5. Registry state and system behavior configuration fields Copy linkLink copied to clipboard!
The following configuration fields control Red Hat Quay registry operational state, including read-only mode and webhook hostname restrictions.
| Field | Type | Description |
|---|---|---|
| REGISTRY_STATE | String |
The state of the registry. Values: |
| WEBHOOK_HOSTNAME_BLACKLIST | Array of String | The set of hostnames to disallow from webhooks when validating, beyond localhost |
Registry state and system behavior example YAML
# ...
REGISTRY_STATE: normal
WEBHOOK_HOSTNAME_BLACKLIST:
- "169.254.169.254"
- "internal.example.com"
- "127.0.0.2"
# ...
9.2. User Experience and Interface Copy linkLink copied to clipboard!
The following fields configure how users interact with the UI, including branding, pagination, browser behavior, and accessibility options like recaptcha. This also covers user-facing performance and display settings.
9.2.1. Web UI and user experience configuration fields Copy linkLink copied to clipboard!
The following configuration fields control the behavior and appearance of the Red Hat Quay web interface and overall user experience. Options in this section allow administrators to customize login behavior, avatar display, user autocomplete, session handling, and catalog visibility.
| Field | Type | Description |
|---|---|---|
| AVATAR_KIND | String |
The types of avatars to display, either generated inline (local) or Gravatar (gravatar) Values: |
| FRESH_LOGIN_TIMEOUT | String |
The time after which a fresh login requires users to re-enter their password Example: |
| FEATURE_UI_V2 | Boolean | When set, allows users to try the v2 beta UI environment.
Default: |
| FEATURE_UI_V2_REPO_SETTINGS | Boolean |
When set to
Default: |
| FEATURE_DIRECT_LOGIN | Boolean | Whether users can directly login to the UI Default: True |
| FEATURE_PARTIAL_USER_AUTOCOMPLETE | Boolean | If set to true, autocompletion will apply to partial usernames+ Default: True |
| FEATURE_LIBRARY_SUPPORT | Boolean | Whether to allow for "namespace-less" repositories when pulling and pushing from Docker Default: True |
| FEATURE_PERMANENT_SESSIONS | Boolean | Whether sessions are permanent Default: True |
| FEATURE_PUBLIC_CATALOG | Boolean |
If set to true, the Default: False |
| DISABLE_ANGULAR_UI | Boolean | Disable legacy Angular UI pages and redirects. Default: False |
| DEFAULT_UI | String | Allows Red Hat Quay administrators the option to set the default UI to the angular theme (legacy) or react theme (v2 UI).
Options: |
Example YAML
# ...
AVATAR_KIND: local
FRESH_LOGIN_TIMEOUT: 5m
FEATURE_UI_V2: true
FEATURE_UI_V2_REPO_SETTINGS: false
FEATURE_DIRECT_LOGIN: true
FEATURE_PARTIAL_USER_AUTOCOMPLETE: true
FEATURE_LIBRARY_SUPPORT: true
FEATURE_PERMANENT_SESSIONS: true
FEATURE_PUBLIC_CATALOG: false
# ...
9.2.1.1. v2 user interface configuration Copy linkLink copied to clipboard!
With FEATURE_UI_V2 enabled, you can toggle between the current version of the user interface and the new version of the user interface.
- This UI is currently in beta and subject to change. In its current state, users can only create, view, and delete organizations, repositories, and image tags.
- When running Red Hat Quay in the old UI, timed-out sessions would require that the user input their password again in the pop-up window. With the new UI, users are returned to the main page and required to input their username and password credentials. This is a known issue and will be fixed in a future version of the new UI.
- There is a discrepancy in how image manifest sizes are reported between the legacy UI and the new UI. In the legacy UI, image manifests were reported in mebibytes. In the new UI, Red Hat Quay uses the standard definition of megabyte (MB) to report image manifest sizes.
9.2.2. Session timeout configuration field Copy linkLink copied to clipboard!
The following configuration field sets how long permanent user sessions remain active in Red Hat Quay before they expire.
This field relies on on the Flask API configuration field of the same name.
Altering session lifetime is not recommended. Administrators should be aware of the allotted time when setting a session timeout. If you set the time too early, it might interrupt your workflow.
| Field | Type | Description |
|---|---|---|
| PERMANENT_SESSION_LIFETIME | Integer |
A
Default: |
Session timeout example YAML
# ...
PERMANENT_SESSION_LIFETIME: 3000
# ...
9.3. User and Access Management Copy linkLink copied to clipboard!
Use the following fields to configure how users are created, authenticated, and managed. This includes settings for superusers, account recovery, app-specific tokens, login behavior, and external identity providers like LDAP, OAuth, and OIDC.
9.3.1. User configuration fields Copy linkLink copied to clipboard!
The user configuration fields define how user accounts behave in your Red Hat Quay deployment. These fields enable control over user creation, access levels, metadata tracking, recovery options, and namespace management. You can also enforce restrictions, such as invite-only creation or superuser privileges, to match your organization’s governance and security policies.
| Field | Type | Description |
|---|---|---|
| FEATURE_SUPER_USERS | Boolean | Whether superusers are supported
Default: |
| FEATURE_USER_CREATION | Boolean | Whether users can be created (by non-superusers)
Default: |
| FEATURE_USER_LAST_ACCESSED | Boolean | Whether to record the last time a user was accessed
Default: |
| FEATURE_USER_LOG_ACCESS | Boolean | If set to true, users will have access to audit logs for their namespace
Default: |
| FEATURE_USER_METADATA | Boolean | Whether to collect and support user metadata
Default: |
| FEATURE_USERNAME_CONFIRMATION | Boolean | If set to true, users can confirm and modify their initial usernames when logging in via OpenID Connect (OIDC) or a non-database internal authentication provider like LDAP.
Default: |
| FEATURE_USER_RENAME | Boolean | If set to true, users can rename their own namespace.
Default: |
| FEATURE_INVITE_ONLY_USER_CREATION | Boolean | Whether users being created must be invited by another user
Default: |
| FRESH_LOGIN_TIMEOUT | String | The time after which a fresh login requires users to re-enter their password
Example: |
| USERFILES_LOCATION | String | ID of the storage engine in which to place user-uploaded files
Example: |
| USERFILES_PATH | String | Path under storage in which to place user-uploaded files
Example: |
| USER_RECOVERY_TOKEN_LIFETIME | String |
The length of time a token for recovering a user accounts is valid Pattern:
Default: |
| FEATURE_SUPERUSERS_FULL_ACCESS | Boolean | Grants superusers the ability to read, write, and delete content from other repositories in namespaces that they do not own or have explicit permissions for.
Default: |
| FEATURE_SUPERUSERS_ORG_CREATION_ONLY | Boolean | Whether to only allow superusers to create organizations.
Default: |
| FEATURE_SUPERUSER_CONFIGDUMP | Boolean | Enables a full config dump of the running Framework, environment and schema for validation.
Default: |
| FEATURE_RESTRICTED_USERS | Boolean |
When set to
Default: |
| RESTRICTED_USERS_WHITELIST | String |
When set with |
| GLOBAL_READONLY_SUPER_USERS | String | When set, grants users of this list read access to all repositories, regardless of whether they are public repositories. |
User example YAML
# ...
FEATURE_SUPER_USERS: true
FEATURE_USER_CREATION: true
FEATURE_INVITE_ONLY_USER_CREATION: false
FEATURE_USER_RENAME: true
FEATURE_SUPERUSERS_FULL_ACCESS: true
FEATURE_SUPERUSERS_ORG_CREATION_ONLY: false
FEATURE_SUPERUSER_CONFIGDUMP: true
FEATURE_RESTRICTED_USERS: true
RESTRICTED_USERS_WHITELIST:
- user1
GLOBAL_READONLY_SUPER_USERS:
- quayadmin
FRESH_LOGIN_TIMEOUT: "5m"
USER_RECOVERY_TOKEN_LIFETIME: "30m"
USERFILES_LOCATION: "s3_us_east"
USERFILES_PATH: "userfiles"
# ...
When the RESTRICTED_USERS_WHITELIST field is set, allowlisted users can create organizations, or read or write content from the repository even if FEATURE_RESTRICTED_USERS is set to True. Other users, for example, user2, user3, and user4 are restricted from creating organizations, reading, or writing content.
9.3.2. Robot account configuration fields Copy linkLink copied to clipboard!
The following configuration fields control whether robot account creation and interaction is allowed globally in Red Hat Quay.
| Field | Type | Description |
|---|---|---|
| ROBOTS_DISALLOW | Boolean |
When set to |
Robot account disallow example YAML
# ...
ROBOTS_DISALLOW: true
# ...
9.3.3. LDAP configuration fields Copy linkLink copied to clipboard!
The following configuration fields allow administrators to integrate Red Hat Quay with an LDAP-based authentication system. When AUTHENTICATION_TYPE is set to LDAP, Red Hat Quay can authenticate users against an LDAP directory and support additional, optional features such as team synchronization, superuser access control, restricted user roles, and secure connection parameters.
This section provides YAML examples for the following LDAP scenarios:
- Basic LDAP configuration
- LDAP restricted user configuration
- LDAP superuser configuration
Additional resources
| Field | Type | Description |
|---|---|---|
| AUTHENTICATION_TYPE (Required) | String |
Must be set to |
| FEATURE_TEAM_SYNCING | Boolean |
Whether to allow for team membership to be synced from a backing group in the authentication engine (OIDC, LDAP, or Keystone). Default: |
| FEATURE_NONSUPERUSER_TEAM_SYNCING_SETUP | Boolean | If enabled, non-superusers can setup team syncrhonization.
Default: |
| LDAP_ADMIN_DN | String | The admin DN for LDAP authentication. |
| LDAP_ADMIN_PASSWD | String | The admin password for LDAP authentication. |
| LDAP_ALLOW_INSECURE_FALLBACK | Boolean | Whether or not to allow SSL insecure fallback for LDAP authentication. |
| LDAP_BASE_DN | Array of String | The base DN for LDAP authentication. |
| LDAP_EMAIL_ATTR | String | The email attribute for LDAP authentication. |
| LDAP_UID_ATTR | String | The uid attribute for LDAP authentication. |
| LDAP_URI | String | The LDAP URI. |
| LDAP_USER_FILTER | String | The user filter for LDAP authentication. |
| LDAP_USER_RDN | Array of String | The user RDN for LDAP authentication. |
| LDAP_SECONDARY_USER_RDNS | Array of String | Provide Secondary User Relative DNs if there are multiple Organizational Units where user objects are located. |
| TEAM_RESYNC_STALE_TIME | String |
If team syncing is enabled for a team, how often to check its membership and resync if necessary. Pattern:
Default: |
| LDAP_SUPERUSER_FILTER | String |
Subset of the With this field, administrators can add or remove superusers without having to update the Red Hat Quay configuration file and restart their deployment.
This field requires that your |
| LDAP_GLOBAL_READONLY_SUPERUSER_FILTER | String |
Subset of the |
| LDAP_RESTRICTED_USER_FILTER | String |
Subset of the
This field requires that your |
| FEATURE_RESTRICTED_USERS | Boolean |
When set to
Default: |
| LDAP_TIMEOUT | Integer |
Specifies the time limit, in seconds, for LDAP operations. This limits the amount of time an LDAP search, bind, or other operation can take. Similar to the
Default: |
| LDAP_NETWORK_TIMEOUT | Integer |
Specifies the time limit, in seconds, for establishing a connection to the LDAP server. This is the maximum time Red Hat Quay waits for a response during network operations, similar to the
Default: |
| FEATURE_LDAP_CACHING | Boolean | enable in-memory caching for LDAP permission check results (superuser, restricted user). Reduces LDAP server load.
Default: |
| LDAP_CACHE_TTL | Integer | Time-to-live, in seconds, for cached LDAP permission results.
Default: |
Basic LDAP configuration example YAML
# ...
AUTHENTICATION_TYPE: LDAP
# ...
LDAP_ADMIN_DN: uid=<name>,ou=Users,o=<organization_id>,dc=<example_domain_component>,dc=com
LDAP_ADMIN_PASSWD: ABC123
LDAP_ALLOW_INSECURE_FALLBACK: false
LDAP_BASE_DN:
- dc=example
- dc=com
LDAP_EMAIL_ATTR: mail
LDAP_UID_ATTR: uid
LDAP_URI: ldap://<example_url>.com
LDAP_USER_FILTER: (memberof=cn=developers,ou=Users,dc=<domain_name>,dc=com)
LDAP_USER_RDN:
- ou=people
LDAP_SECONDARY_USER_RDNS:
- ou=<example_organization_unit_one>
- ou=<example_organization_unit_two>
- ou=<example_organization_unit_three>
- ou=<example_organization_unit_four>
FEATURE_LDAP_CACHING: true
LDAP_CACHE_TTL: 10
where:
AUTHENTICATION_TYPE-
Specifies
LDAPfor LDAP authentication type. LDAP_ADMIN_DN- Specifies the admin DN for LDAP authentication. This field is required.
LDAP_ADMIN_PASSWD- Specifies the admin password for LDAP authentication. This field is required.
LDAP_ALLOW_INSECURE_FALLBACK- Specifies whether to allow SSL/TLS insecure fallback for LDAP authentication. This field is required.
LDAP_BASE_DN- Specifies the base DN for LDAP authentication. This field is required.
LDAP_EMAIL_ATTR- Specifies the email attribute for LDAP authentication. This field is required.
LDAP_UID_ATTR- Specifies the UID attribute for LDAP authentication. This field is required.
LDAP_URI- Specifies the LDAP URI. This field is required.
LDAP_USER_FILTER- Specifies the user filter for LDAP authentication. This field is required.
LDAP_USER_RDN- Specifies the user RDN for LDAP authentication. This field is required.
LDAP_SECONDARY_USER_RDNS- Specifies secondary User Relative DNs if there are multiple Organizational Units where user objects are located. This field is optional.
FEATURE_LDAP_CACHING-
Specifies whether to enable in-memory caching for LDAP permission check results (superuser, restricted user). Reduces LDAP server load. Defaults to
False. This field is optional. LDAP_CACHE_TTL-
Specifies the time-to-live, in seconds, for cached LDAP permission results. Defaults to
60.
LDAP restricted user configuration example YAML
# ...
AUTHENTICATION_TYPE: LDAP
# ...
FEATURE_RESTRICTED_USERS: true
# ...
LDAP_ADMIN_DN: uid=<name>,ou=Users,o=<organization_id>,dc=<example_domain_component>,dc=com
LDAP_ADMIN_PASSWD: ABC123
LDAP_ALLOW_INSECURE_FALLBACK: false
LDAP_BASE_DN:
- o=<organization_id>
- dc=<example_domain_component>
- dc=com
LDAP_EMAIL_ATTR: mail
LDAP_UID_ATTR: uid
LDAP_URI: ldap://<example_url>.com
LDAP_USER_FILTER: (memberof=cn=developers,ou=Users,o=<example_organization_unit>,dc=<example_domain_component>,dc=com)
LDAP_RESTRICTED_USER_FILTER: (<filterField>=<value>)
LDAP_USER_RDN:
- ou=<example_organization_unit>
- o=<organization_id>
- dc=<example_domain_component>
- dc=com
FEATURE_LDAP_CACHING: true
LDAP_CACHE_TTL: 10
# ...
where:
FEATURE_RESTRICTED_USERS-
Specify
Truewhen configuring an LDAP restricted user. LDAP_RESTRICTED_USER_FILTER- Specifies configured users as restricted users.
LDAP superuser configuration reference example YAML
# ...
AUTHENTICATION_TYPE: LDAP
# ...
LDAP_ADMIN_DN: uid=<name>,ou=Users,o=<organization_id>,dc=<example_domain_component>,dc=com
LDAP_ADMIN_PASSWD: ABC123
LDAP_ALLOW_INSECURE_FALLBACK: false
LDAP_BASE_DN:
- o=<organization_id>
- dc=<example_domain_component>
- dc=com
LDAP_EMAIL_ATTR: mail
LDAP_UID_ATTR: uid
LDAP_URI: ldap://<example_url>.com
LDAP_USER_FILTER: (memberof=cn=developers,ou=Users,o=<example_organization_unit>,dc=<example_domain_component>,dc=com)
LDAP_SUPERUSER_FILTER: (<filterField>=<value>)
LDAP_USER_RDN:
- ou=<example_organization_unit>
- o=<organization_id>
- dc=<example_domain_component>
- dc=com
FEATURE_LDAP_CACHING: true
LDAP_CACHE_TTL: 10
# ...
LDAP_SUPERUSER_FILTER- Specify configured users as superusers.
9.3.4. OAuth configuration fields Copy linkLink copied to clipboard!
The following configuration fields define the behavior of Red Hat Quay when handling authentication through external identity providers using OAuth. You can configure global OAuth options such as token assignment and whitelisted client IDs, as well as provider-specific settings for GitHub and Google.
| Field | Type | Description |
|---|---|---|
| DIRECT_OAUTH_CLIENTID_WHITELIST | Array of String | A list of client IDs for Quay-managed applications that are allowed to perform direct OAuth approval without user approval. |
| FEATURE_ASSIGN_OAUTH_TOKEN | Boolean | Allows organization administrators to assign OAuth tokens to other users. |
Global OAuth example YAML
# ...
DIRECT_OAUTH_CLIENTID_WHITELIST:
- <quay_robot_client>
- <quay_app_token_issuer>
FEATURE_ASSIGN_OAUTH_TOKEN: true
# ...
| Field | Type | Description |
|---|---|---|
| FEATURE_GITHUB_LOGIN | Boolean | Whether GitHub login is supported
Default: |
| GITHUB_LOGIN_CONFIG | Object | Configuration for using GitHub (Enterprise) as an external login provider. |
| .ALLOWED_ORGANIZATIONS | Array of String | The names of the GitHub (Enterprise) organizations whitelisted to work with the ORG_RESTRICT option. |
| .API_ENDPOINT | String |
The endpoint of the GitHub (Enterprise) API to use. Must be overridden for github.com Example: |
| .CLIENT_ID (Required) | String |
The registered client ID for this Red Hat Quay instance; cannot be shared with |
| .CLIENT_SECRET (Required) | String |
The registered client secret for this Red Hat Quay instance. Example: |
| .GITHUB_ENDPOINT (Required) | String | The endpoint for GitHub (Enterprise).
Example: |
| .ORG_RESTRICT | Boolean | If true, only users within the organization whitelist can login using this provider. |
Github OAth example YAML
# ...
FEATURE_GITHUB_LOGIN: true
GITHUB_LOGIN_CONFIG:
ALLOWED_ORGANIZATIONS:
- <myorg>
- <dev-team>
API_ENDPOINT: <https://api.github.com/>
CLIENT_ID: <client_id>
CLIENT_SECRET: <client_secret>
GITHUB_ENDPOINT: <https://github.com/>
ORG_RESTRICT: true
# ...
| Field | Type | Description |
|---|---|---|
| FEATURE_GOOGLE_LOGIN | Boolean | Whether Google login is supported.
Default: |
| GOOGLE_LOGIN_CONFIG | Object | Configuration for using Google for external authentication. |
| .CLIENT_ID (Required) | String | The registered client ID for this Red Hat Quay instance.
Example: |
| .CLIENT_SECRET (Required) | String | The registered client secret for this Red Hat Quay instance.
Example: |
Google OAuth example YAML
# ...
FEATURE_GOOGLE_LOGIN: true
GOOGLE_LOGIN_CONFIG:
CLIENT_ID: <client_id>
CLIENT_SECRET: <client_secret>
# ...
9.3.5. OIDC configuration fields Copy linkLink copied to clipboard!
Configure OpenID Connect client credentials, endpoints, and token behavior for Red Hat Quay login.
You can configure Red Hat Quay to authenticate users through any OpenID Connect (OIDC)-compatible identity provider, including Azure Entra ID (formerly Azure AD), Okta, Keycloak, and others. These fields define the necessary client credentials, endpoints, and token behavior used during the OIDC login flow.
| Field | Type | Description |
|---|---|---|
| <string>_LOGIN_CONFIG (Required) | String |
The parent key that holds the OIDC configuration settings. Typically the name of the OIDC provider, for example, |
| .CLIENT_ID (Required) | String |
The registered client ID for this Red Hat Quay instance. Example: |
| .CLIENT_SECRET (Required) | String |
The registered client secret for this Red Hat Quay instance. Example: |
| .LOGIN_BINDING_FIELD | String | Used when the internal authorization is set to LDAP. Red Hat Quay reads this parameter and tries to search through the LDAP tree for the user with this username. If it exists, it automatically creates a link to that LDAP account. |
| .LOGIN_SCOPES | Object |
Scopes Red Hat Quay requests during the OIDC login flow. Must include |
| .OIDC_ENDPOINT_CUSTOM_PARAMS | String |
Support for custom query parameters on OIDC endpoints. The following endpoints are supported: |
| .OIDC_ISSUER | String |
Allows the user to define the issuer to verify. For example, JWT tokens container a parameter known as |
| .OIDC_ISSUERS | Array of String |
Accepted issuer URLs for this provider. When set, Red Hat Quay accepts tokens whose |
| .OIDC_AUDIENCES | Array of String |
Accepted audience values for bearer token and On-Behalf-Of (OBO) flows. When set, Red Hat Quay validates the token |
| .OIDC_ALLOWED_CLIENTS | Array of String |
Optional whitelist of authorized party ( |
| .OIDC_SERVER (Required) | String |
The OIDC discovery base URL for authentication. Red Hat Quay uses path joining for OIDC discovery, so the URL must end with a trailing |
| .PREFERRED_USERNAME_CLAIM_NAME | String | Sets the preferred username to a parameter from the token. |
| .SERVICE_ICON | String | Changes the icon on the login screen. |
| .SERVICE_NAME (Required) | String |
The name of the service that is being authenticated. Example: |
| .VERIFIED_EMAIL_CLAIM_NAME | String | The name of the claim that is used to verify the email address of the user. |
| .PREFERRED_GROUP_CLAIM_NAME | String | The key name within the OIDC token payload that holds information about the user’s group memberships. |
| .OIDC_DISABLE_USER_ENDPOINT | Boolean |
Whether to allow or disable the
Default: |
| USE_PKCE | Boolean | Whether to enable support for Proof Key for Code Exchange.
Default: |
| PKCE_METHOD | Integer |
The code challenge method used to generate the
Default: |
| PUBLIC_CLIENT | Boolean |
Whether to omit
Default: |
OIDC example YAML
AUTHENTICATION_TYPE: OIDC
# ...
<oidc_provider>_LOGIN_CONFIG:
CLIENT_ID: <client_id>
CLIENT_SECRET: <client_secret>
LOGIN_BINDING_FIELD: <login_binding_field>
LOGIN_SCOPES:
- openid
- email
- profile
OIDC_ENDPOINT_CUSTOM_PARAMS:
authorization_endpoint:
some: "param"
token_endpoint:
some: "param"
user_endpoint:
some: "param"
OIDC_ISSUER: <oidc_issuer_url>
OIDC_ISSUERS:
- <issuer_url_1>
- <issuer_url_2>
OIDC_AUDIENCES:
- <client_id>
- <custom_api_audience>
OIDC_ALLOWED_CLIENTS:
- <client_id>
- <upstream_client_id>
OIDC_SERVER: <oidc_server_address>
PREFERRED_USERNAME_CLAIM_NAME: <preferred_username_claim>
SERVICE_ICON: <service_icon_url>
SERVICE_NAME: <service_name>
VERIFIED_EMAIL_CLAIM_NAME: <verified_email_claim>
PREFERRED_GROUP_CLAIM_NAME: <preferred_group_claim>
OIDC_DISABLE_USER_ENDPOINT: true
USE_PKCE: True
PKCE_METHOD: "S256"
PUBLIC_CLIENT: True
# ...
OIDC example YAML for Microsoft Entra ID v2 with dual-issuer support
AUTHENTICATION_TYPE: OIDC
# ...
AZURE_LOGIN_CONFIG:
CLIENT_ID: <quay_app_client_id>
CLIENT_SECRET: <quay_app_client_secret>
OIDC_SERVER: https://login.microsoftonline.com/<tenant-id>/v2.0/
SERVICE_NAME: Microsoft Entra ID
OIDC_DISABLE_USER_ENDPOINT: true
OIDC_ISSUERS:
- https://sts.windows.net/<tenant-id>/
- https://login.microsoftonline.com/<tenant-id>/v2.0
OIDC_AUDIENCES:
- <quay_app_client_id>
- api://quay-api
OIDC_ALLOWED_CLIENTS:
- <quay_app_client_id>
- <upstream_app_client_id>
USE_PKCE: true
PKCE_METHOD: "S256"
PUBLIC_CLIENT: true
# ...
9.3.6. Recaptcha configuration fields Copy linkLink copied to clipboard!
The following configuration fields enable Recaptcha protection for user login and account recovery forms in Red Hat Quay.
| Field | Type | Description |
|---|---|---|
| FEATURE_RECAPTCHA | Boolean | Whether Recaptcha is necessary for user login and recovery Default: False |
| RECAPTCHA_SECRET_KEY | String | If recaptcha is enabled, the secret key for the Recaptcha service |
| RECAPTCHA_SITE_KEY | String | If recaptcha is enabled, the site key for the Recaptcha service |
Recaptcha example YAML
# ...
FEATURE_RECAPTCHA: true
RECAPTCHA_SITE_KEY: "<site_key>"
RECAPTCHA_SECRET_KEY: "<secret_key>"
# ...
9.3.7. JWT configuration fields Copy linkLink copied to clipboard!
Red Hat Quay can be configured to support external authentication using JSON Web Tokens (JWT). This integration allows third-party identity providers or token issuers to authenticate and authorize users by calling specific endpoints that handle token verification, user lookup, and permission queries.
| Field | Type | Description |
|---|---|---|
| JWT_AUTH_ISSUER | String |
The endpoint for JWT users Pattern: |
| JWT_GETUSER_ENDPOINT | String |
The endpoint for JWT users Pattern: |
| JWT_QUERY_ENDPOINT | String |
The endpoint for JWT queries Pattern: |
| JWT_VERIFY_ENDPOINT | String |
The endpoint for JWT verification Pattern: |
JWT example YAML
# ...
JWT_AUTH_ISSUER: "http://192.168.99.101:6060"
JWT_GETUSER_ENDPOINT: "http://192.168.99.101:6060/getuser"
JWT_QUERY_ENDPOINT: "http://192.168.99.101:6060/query"
JWT_VERIFY_ENDPOINT: "http://192.168.99.101:6060/verify"
# ...
9.3.8. App tokens configuration fields Copy linkLink copied to clipboard!
App-specific tokens allow users to authenticate with Red Hat Quay using token-based credentials. These fields might be useful for CLI tools like Docker.
| Field | Type | Description |
|---|---|---|
| FEATURE_APP_SPECIFIC_TOKENS | Boolean | If enabled, users can create tokens for use by the Docker CLI Default: True |
| APP_SPECIFIC_TOKEN_EXPIRATION | String | The expiration for external app tokens. Default None
Pattern: |
| EXPIRED_APP_SPECIFIC_TOKEN_GC | String | Duration of time expired external app tokens will remain before being garbage collected
Default: |
App tokens example YAML
# ...
FEATURE_APP_SPECIFIC_TOKENS: true
APP_SPECIFIC_TOKEN_EXPIRATION: "30d"
EXPIRED_APP_SPECIFIC_TOKEN_GC: "1d"
# ...
9.3.9. Programmatic bootstrap configuration fields Copy linkLink copied to clipboard!
Use these configuration fields to control bootstrap OAuth token provisioning for automated Red Hat Quay deployments. The feature remains disabled until you enable it. Standalone deployments store the token in a local file. Red Hat Quay on OpenShift Container Platform Operator deployments store the token in a Kubernetes Secret that the Operator creates and mounts.
| Field | Type | Description |
|---|---|---|
| FEATURE_PROGRAMMATIC_BOOTSTRAP | Boolean |
Enables programmatic bootstrap token provisioning. When
Default: |
| BOOTSTRAP_TOKEN_OWNER | String |
Username that owns the bootstrap OAuth application and token. Required when |
| BOOTSTRAP_TOKEN_PATH | String |
Filesystem path where the bootstrap token JSON is written on standalone and virtual machine deployments. In containerized deployments, use a mounted path that the Red Hat Quay process can write, for example
Default: |
| BOOTSTRAP_TOKEN_EXPIRATION | Integer | Bootstrap token lifetime in seconds.
Default: |
| BOOTSTRAP_TOKEN_SCOPE | String | Space-separated OAuth scopes assigned to the bootstrap token.
Default: |
| PROGRAMMATIC_TOKEN_K8S_SECRET | String |
Kubernetes Secret name used to store the bootstrap token when Red Hat Quay runs in Kubernetes. When set, Red Hat Quay writes the token to this Secret instead of |
| PROGRAMMATIC_TOKEN_K8S_KEY | String |
Secret data key that stores the bootstrap token JSON. On Red Hat Quay on OpenShift Container Platform, the Operator sets this field to
Default: |
| PROGRAMMATIC_TOKEN_K8S_NAMESPACE | String |
Kubernetes namespace that contains the bootstrap token Secret. When unset, Red Hat Quay uses the pod service account namespace. On Red Hat Quay on OpenShift Container Platform, the Operator uses the |
| PROGRAMMATIC_TOKEN_PATH | String |
Operator-rendered mount path for configuration compatibility. On Red Hat Quay on OpenShift Container Platform, the Operator sets this field to |
Programmatic bootstrap example YAML (standalone)
FEATURE_PROGRAMMATIC_BOOTSTRAP: true
SUPER_USERS:
- quayadmin
BOOTSTRAP_TOKEN_OWNER: quayadmin
BOOTSTRAP_TOKEN_PATH: /var/lib/quay/quay-machine-token.json
BOOTSTRAP_TOKEN_EXPIRATION: 7776000
BOOTSTRAP_TOKEN_SCOPE: "org:admin repo:admin repo:create repo:read repo:write super:user user:admin user:read"
Programmatic bootstrap example YAML (Red Hat Quay on OpenShift Container Platform configBundleSecret)
FEATURE_PROGRAMMATIC_BOOTSTRAP: true
SUPER_USERS:
- quayadmin
BOOTSTRAP_TOKEN_OWNER: quayadmin
BOOTSTRAP_TOKEN_EXPIRATION: 7776000
BOOTSTRAP_TOKEN_SCOPE: "org:admin repo:admin repo:create repo:read repo:write super:user user:admin user:read"
For Operator deployments, omit BOOTSTRAP_TOKEN_PATH and the PROGRAMMATIC_TOKEN_K8S_* fields from the configBundleSecret. The Operator injects PROGRAMMATIC_TOKEN_K8S_SECRET, PROGRAMMATIC_TOKEN_K8S_KEY, and PROGRAMMATIC_TOKEN_PATH, and creates the <quayregistry_name>-bootstrap-token Secret, Role, and RoleBinding automatically.
Always quote BOOTSTRAP_TOKEN_SCOPE. Unquoted values that contain : can be misparsed by YAML.
The bootstrap token is a high-privilege credential. Use it only to provision organizations, applications, and narrower-scoped OAuth tokens for automation. Do not use the bootstrap token for routine API operations.
For regulated environments, set BOOTSTRAP_TOKEN_EXPIRATION according to your token rotation policy and renew the token by using POST /api/v1/bootstrap/renew.
9.4. Security and Permissions Copy linkLink copied to clipboard!
The following configuration fields govern core security behaviors and access policies in Red Hat Quay.
9.4.1. Namespace and repository management configuration fields Copy linkLink copied to clipboard!
The following configuration fields govern how Red Hat Quay manages namespaces and repositories, including behavior during automated image pushes, visibility defaults, and rate limiting exceptions.
| Field | Type | Description |
|---|---|---|
| DEFAULT_NAMESPACE_MAXIMUM_BUILD_COUNT | Number | The default maximum number of builds that can be queued in a namespace. Default: None |
| CREATE_PRIVATE_REPO_ON_PUSH | Boolean | Whether new repositories created by push are set to private visibility Default: True |
| CREATE_NAMESPACE_ON_PUSH | Boolean | Whether new push to a non-existent organization creates it Default: False |
| PUBLIC_NAMESPACES | Array of String | If a namespace is defined in the public namespace list, then it will appear on all users' repository list pages, regardless of whether the user is a member of the namespace. Typically, this is used by an enterprise customer in configuring a set of "well-known" namespaces. |
| NON_RATE_LIMITED_NAMESPACES | Array of String |
If rate limiting has been enabled using |
| DISABLE_PUSHES | Boolean |
Disables pushes of new content to the registry while retaining all other functionality. Differs from Default: False |
Namespace and repository management example YAML
# ...
DEFAULT_NAMESPACE_MAXIMUM_BUILD_COUNT: 10
CREATE_PRIVATE_REPO_ON_PUSH: true
CREATE_NAMESPACE_ON_PUSH: false
PUBLIC_NAMESPACES:
- redhat
- opensource
- infra-tools
NON_RATE_LIMITED_NAMESPACES:
- ci-pipeline
- trusted-partners
DISABLE_PUSHES: false
# ...
9.4.2. Nested repositories configuration fields Copy linkLink copied to clipboard!
Support for nested repository path names has been added by the FEATURE_EXTENDED_REPOSITORY_NAMES property. This optional configuration is added to the config.yaml by default. Enablement allows the use of / in repository names.
| Field | Type | Description |
|---|---|---|
| FEATURE_EXTENDED_REPOSITORY_NAMES | Boolean | Enable support for nested repositories Default: True |
Nested repositories example YAML
# ...
FEATURE_EXTENDED_REPOSITORY_NAMES: true
# ...
9.5. Additional security configuration fields Copy linkLink copied to clipboard!
The following configuration fields provide additional security controls for your Red Hat Quay deployment. These options allow administrators to enforce authentication practices, control anonymous access to content, require team invitations, and enable FIPS-compliant cryptographic functions for environments with enhanced security requirements.
| Feature | Type | Description |
|---|---|---|
| FEATURE_REQUIRE_TEAM_INVITE | Boolean | Whether to require invitations when adding a user to a team Default: True |
| FEATURE_REQUIRE_ENCRYPTED_BASIC_AUTH | Boolean | Whether non-encrypted passwords (as opposed to encrypted tokens) can be used for basic auth Default: False |
| FEATURE_ANONYMOUS_ACCESS | Boolean | Whether to allow anonymous users to browse and pull public repositories Default: True |
| FEATURE_FIPS | Boolean | If set to true, Red Hat Quay will run using FIPS-compliant hash functions Default: False |
Additional security example YAML
# ...
FEATURE_REQUIRE_TEAM_INVITE: true
FEATURE_REQUIRE_ENCRYPTED_BASIC_AUTH: false
FEATURE_ANONYMOUS_ACCESS: true
FEATURE_FIPS: false
# ...
9.6. Rate limiting and performance configuration fields Copy linkLink copied to clipboard!
The following configuration fields control rate limiting and performance-related behavior for your Red Hat Quay deployment.
| Field | Type | Description |
|---|---|---|
| FEATURE_RATE_LIMITS | Boolean |
Whether to enable rate limits on API and registry endpoints. Setting FEATURE_RATE_LIMITS to
Default: |
| PROMETHEUS_NAMESPACE | String | The prefix applied to all exposed Prometheus metrics
Default: |
Rate limiting and performance example YAML
# ...
FEATURE_RATE_LIMITS: false
PROMETHEUS_NAMESPACE: quay
# ...
9.7. Search configuration fields Copy linkLink copied to clipboard!
The following configuration fields define how search results are paginated in the Red Hat Quay user interface.
| Field | Type | Description |
|---|---|---|
| SEARCH_MAX_RESULT_PAGE_COUNT | Number | Maximum number of pages the user can paginate in search before they are limited Default: 10 |
| SEARCH_RESULTS_PER_PAGE | Number | Number of results returned per page by search page Default: 10 |
Search example YAML
# ...
SEARCH_MAX_RESULT_PAGE_COUNT: 10
SEARCH_RESULTS_PER_PAGE: 10
# ...
9.8. Storage and Data Management Copy linkLink copied to clipboard!
This section describes the configuration fields that govern how Red Hat Quay stores, manages, and audits data.
9.8.1. Image storage features Copy linkLink copied to clipboard!
The following configuration fields enable repository mirroring, storage proxying, and automatic storage replication features. These features allow you to enhance scalability, resilience, and flexibility when managing container image data.
| Field | Type | Description |
|---|---|---|
| FEATURE_REPO_MIRROR | Boolean | If set to true, enables repository mirroring.
Default: |
| FEATURE_PROXY_STORAGE | Boolean | Whether to proxy all direct download URLs in storage through NGINX.
Default: |
| FEATURE_STORAGE_REPLICATION | Boolean | Whether to automatically replicate between storage engines.
Default: |
Image storage example YAML
# ...
FEATURE_REPO_MIRROR: true
FEATURE_PROXY_STORAGE: false
FEATURE_STORAGE_REPLICATION: true
# ...
9.8.2. Action log storage configuration fields Copy linkLink copied to clipboard!
The following configuration fields control how Red Hat Quay stores, exports, rotates, and audits action logs for registry activity. You can use these fields to export or forward logs to external systems like Elasticsearch or Splunk for advanced analysis, auditing, or compliance.
| Field | Type | Description |
|---|---|---|
| FEATURE_LOG_EXPORT | Boolean | Whether to allow exporting of action logs.
Default: |
| LOGS_MODEL | String |
Specifies the preferred method for handling log data. Values: One of
Default: |
| LOGS_MODEL_CONFIG | Object | Logs model config for action logs. |
| ALLOW_WITHOUT_STRICT_LOGGING | Boolean |
When set to Default: False |
Action log storage example YAML
# ...
FEATURE_LOG_EXPORT: true
LOGS_MODEL: elasticsearch
LOGS_MODEL_CONFIG:
elasticsearch:
endpoint: http://elasticsearch.example.com:9200
index_prefix: quay-logs
username: elastic
password: changeme
ALLOW_WITHOUT_STRICT_LOGGING: true
# ...
9.8.2.1. Action log rotation and archiving configuration Copy linkLink copied to clipboard!
This section describes configuration fields related to action log rotation and archiving in Red Hat Quay. When enabled, older logs can be automatically rotated and archived to designated storage locations, helping to manage log retention and storage utilization efficiently.
| Field | Type | Description |
|---|---|---|
| FEATURE_ACTION_LOG_ROTATION | Boolean | Enabling log rotation and archival will move all logs older than 30 days to storage.
Default: |
| ACTION_LOG_ARCHIVE_LOCATION | String | If action log archiving is enabled, the storage engine in which to place the archived data.
Example:: |
| ACTION_LOG_ARCHIVE_PATH | String | If action log archiving is enabled, the path in storage in which to place the archived data.
Example: |
| ACTION_LOG_ROTATION_THRESHOLD | String | The time interval after which to rotate logs.
Example: |
Action log rotation and archiving example YAML
# ...
FEATURE_ACTION_LOG_ROTATION: true
ACTION_LOG_ARCHIVE_LOCATION: s3_us_east
ACTION_LOG_ARCHIVE_PATH: archives/actionlogs
ACTION_LOG_ROTATION_THRESHOLD: 30d
# ...
9.8.2.2. Action log audit configuration Copy linkLink copied to clipboard!
This section covers the configuration fields for audit logging within Red Hat Quay. When enabled, audit logging tracks detailed user activity such as UI logins, logouts, and Docker logins for regular users, robot accounts, and token-based accounts.
| Field | Type | Description |
|---|---|---|
| ACTION_LOG_AUDIT_LOGINS | Boolean |
When set to
Default: |
| ACTION_LOG_AUDIT_LOGIN_FAILURES | Boolean | Whether logging of failed logins attempts is enabled.
Default: |
| ACTION_LOG_AUDIT_PULL_FAILURES | Boolean | Whether logging of failed image pull attempts is enabled.
Default: |
| ACTION_LOG_AUDIT_PUSH_FAILURES | Boolean | Whether logging of failed image push attempts is enabled.
Default: |
| ACTION_LOG_AUDIT_DELETE_FAILURES | Boolean | Whether logging of failed image delete attempts is enabled.
Default: |
Audit logs configuration example YAML
# ...
ACTION_LOG_AUDIT_LOGINS: true
ACTION_LOG_AUDIT_LOGIN_FAILURES: false
ACTION_LOG_AUDIT_PULL_FAILURES: false
ACTION_LOG_AUDIT_PUSH_FAILURES: false
ACTION_LOG_AUDIT_DELETE_FAILURES: false
# ...
9.8.3. Elasticsearch configuration fields Copy linkLink copied to clipboard!
The following configuration fields integrate Red Hat Quay with an external Elasticsearch service. This enables storing and querying structured data such as action logs, repository events, and other operational records outside of the internal database.
| Field | Type | Description |
|---|---|---|
| LOGS_MODEL_CONFIG.elasticsearch_config.access_key | String | Elasticsearch user (or IAM key for AWS ES).
Example: |
| .elasticsearch_config.host | String | Elasticsearch cluster endpoint.
Example: |
| .elasticsearch_config.index_prefix | String | Prefix for Elasticsearch indexes.
Example: |
| .elasticsearch_config.index_settings | Object | Index settings for Elasticsearch. |
| LOGS_MODEL_CONFIG.elasticsearch_config.use_ssl | Boolean | Whether to use SSL for Elasticsearch.
Default:
Example: |
| .elasticsearch_config.secret_key | String | Elasticsearch password (or IAM secret for AWS ES).
Example: |
| .elasticsearch_config.aws_region | String |
AWS region. Example: |
| .elasticsearch_config.port | Number |
Port of the Elasticsearch cluster. Example: |
| .kinesis_stream_config.aws_secret_key | String |
AWS secret key. Example: |
| .kinesis_stream_config.stream_name | String |
AWS Kinesis stream to send action logs to. Example: |
| .kinesis_stream_config.aws_access_key | String |
AWS access key. Example: |
| .kinesis_stream_config.retries | Number |
Max number of retry attempts for a single request. Example: |
| .kinesis_stream_config.read_timeout | Number |
Read timeout in seconds. Example: |
| .kinesis_stream_config.max_pool_connections | Number |
Max number of connections in the pool. Example: |
| .kinesis_stream_config.aws_region | String |
AWS region. Example: |
| .kinesis_stream_config.connect_timeout | Number |
Connection timeout in seconds. Example: |
| .producer | String |
Logs producer type. Accepted values: |
| .kafka_config.topic | String |
Kafka topic used to publish log entries. Example: |
| .kafka_config.bootstrap_servers | Array | List of Kafka brokers used to bootstrap the client. |
| .kafka_config.max_block_seconds | Number |
Max seconds to block during a |
Elasticsearch example YAML
# ...
FEATURE_LOG_EXPORT: true
LOGS_MODEL: elasticsearch
LOGS_MODEL_CONFIG:
producer: elasticsearch
elasticsearch_config:
access_key: elastic_user
secret_key: elastic_password
host: es.example.com
port: 9200
use_ssl: true
aws_region: us-east-1
index_prefix: logentry_
index_settings:
number_of_shards: 3
number_of_replicas: 1
ALLOW_WITHOUT_STRICT_LOGGING: true
# ...
9.8.3.1. Splunk configuration fields Copy linkLink copied to clipboard!
The following configuration fields export Red Hat Quay action logs to a Splunk endpoint. This configuration allows audit and event logs to be sent to an external Splunk server for centralized analysis, search, and long-term storage.
| Field | Type | Description |
|---|---|---|
| producer | String |
Must be set to |
| splunk_config | Object | Logs model configuration for Splunk action logs or Splunk cluster configuration. |
| .host | String | The Splunk cluster endpoint. |
| .port | Integer | The port number for the Splunk management cluster endpoint. |
| .bearer_token | String | The bearer token used for authentication with Splunk. |
| .verify_ssl | Boolean |
Enable ( |
| .index_prefix | String | The index prefix used by Splunk. |
| .ssl_ca_path | String |
The relative container path to a |
| .search_timeout | Integer | The timeout for Splunk search queries in seconds. Increase for slow Splunk clusters or complex queries. |
| .max_results | Integer | The maximum number of results to return per search query. Larger values require more memory. |
| .export_batch_size | Integer | The batch size for log export operations. |
Splunk configuration example YAML
# ...
LOGS_MODEL: splunk
LOGS_MODEL_CONFIG:
producer: splunk
splunk_config:
host: http://<user_name>.remote.csb
port: 8089
bearer_token: <bearer_token>
url_scheme: <http/https>
verify_ssl: False
index_prefix: <splunk_log_index_name>
ssl_ca_path: <location_to_ssl-ca-cert.pem>
search_timeout: 60
max_results: 10000
export_batch_size: 5000
# ...
9.8.3.1.1. Splunk HEC configuration fields Copy linkLink copied to clipboard!
The following fields are available when configuring Splunk HTTP Event Collector (HEC) for Red Hat Quay.
| Field | Type | Description |
|---|---|---|
| producer | String |
Must be set to |
| splunk_hec_config | Object | Logs model configuration for Splunk HTTP Event Collector action logs. |
| .host | String | Splunk cluster endpoint. |
| .port | Integer | Splunk management cluster endpoint port. |
| .hec_token | String | HEC token used for authenticating with Splunk. |
| .url_scheme | String |
URL scheme to access the Splunk service. Use |
| .verify_ssl | Boolean |
Enable ( |
| .index | String | The Splunk index to use for log storage. |
| .splunk_host | String | The hostname to assign to the logged event. |
| .splunk_sourcetype | String |
The Splunk |
| .timeout | Integer | Timeout in seconds for HTTP requests to Splunk HEC endpoint. Prevents requests from hanging indefinitely when Splunk is unresponsive. |
| .search_timeout | Integer | The timeout for Splunk search queries in seconds. Increase for slow Splunk clusters or complex queries. |
| .max_results | Integer | The maximum number of results to return per search query. Larger values require more memory. |
| .export_batch_size | Integer | The batch size for log export operations. |
| .search_host | String | The Splunk management host for search API. Defaults to HEC host if not specified. |
| .search_port | Integer | The Splunk management port for search API. Defaults to 8089 if not specified. |
| .search_token (Optional) | String | The bearer token for Splunk search API. Required because HEC tokens are ingest-only and cannot search. |
Splunk HEC example YAML
# ...
LOGS_MODEL: splunk
LOGS_MODEL_CONFIG:
producer: splunk_hec
splunk_hec_config:
host: prd-p-aaaaaq.splunkcloud.com
port: 8088
hec_token: 12345678-1234-1234-1234-1234567890ab
url_scheme: https
verify_ssl: False
index: quay
splunk_host: quay-dev
splunk_sourcetype: quay_logs
timeout: 10
search_token: <bearer_token>
search_host: <splunk.example.com>
search_port: 8089
search_timeout: 60
max_results: 10000
export_batch_size: 5000
# ...
9.9. Builds and Automation Copy linkLink copied to clipboard!
The following configuration fields manage automated builds within Red Hat Quay. These settings control how Dockerfile builds are triggered, processed, and stored, and how build logs are managed and accessed.
You can use these fields to:
- Enable or disable automated builds from source repositories.
- Configure the behavior and resource management of the build manager.
- Control access to and retention of build logs for auditing or debugging purposes.
These options help you streamline your CI/CD pipeline, enforce build policies, and retain visibility into your build history across the registry.
9.9.1. Dockerfile build triggers fields Copy linkLink copied to clipboard!
The following configuration fields are used to enable and manage automated builds in Red Hat Quay from Dockerfiles and source code repositories. These fields allow you to define build behavior, enable or disable support for GitHub, GitLab, and Bitbucket triggers, and provide OAuth credentials and endpoints for each SCM provider.
| Field | Type | Description |
|---|---|---|
| FEATURE_BUILD_SUPPORT | Boolean | Whether to support Dockerfile build.
Default: |
| SUCCESSIVE_TRIGGER_FAILURE_DISABLE_THRESHOLD | Number |
If not set to
Default: |
| SUCCESSIVE_TRIGGER_INTERNAL_ERROR_DISABLE_THRESHOLD | Number |
If not set to
Default: |
Dockerfile build support example YAML
# ...
FEATURE_BUILD_SUPPORT: true
SUCCESSIVE_TRIGGER_FAILURE_DISABLE_THRESHOLD: 100
SUCCESSIVE_TRIGGER_INTERNAL_ERROR_DISABLE_THRESHOLD: 5
# ...
| Field | Type | Description |
|---|---|---|
| FEATURE_GITHUB_BUILD | Boolean | Whether to support GitHub build triggers.
Default: |
| GITHUB_TRIGGER_CONFIG | Object | Configuration for using GitHub Enterprise for build triggers. |
| .GITHUB_ENDPOINT (Required) | String |
The endpoint for GitHub Enterprise. Example: |
| .API_ENDPOINT | String |
The endpoint of the GitHub Enterprise API to use. Must be overridden for |
| .CLIENT_ID (Required) | String |
The registered client ID for this Red Hat Quay instance; this cannot be shared with |
| .CLIENT_SECRET (Required) | String | The registered client secret for this Red Hat Quay instance. |
Github build triggers example YAML
# ...
FEATURE_GITHUB_BUILD: true
GITHUB_TRIGGER_CONFIG:
GITHUB_ENDPOINT: https://github.com/
API_ENDPOINT: https://api.github.com/
CLIENT_ID: your-client-id
CLIENT_SECRET: your-client-secret
# ...
| Field | Type | Description |
|---|---|---|
| FEATURE_BITBUCKET_BUILD | Boolean | Whether to support Bitbucket build triggers. Default: False |
| BITBUCKET_TRIGGER_CONFIG | Object | Configuration for using BitBucket for build triggers. |
| .CONSUMER_KEY (Required) | String | The registered consumer key (client ID) for this Red Hat Quay instance. |
| .CONSUMER_SECRET (Required) | String | The registered consumer secret (client secret) for this Red Hat Quay instance. |
Bitbucket build triggers example YAML
# ...
FEATURE_BITBUCKET_BUILD: true
BITBUCKET_TRIGGER_CONFIG:
CONSUMER_KEY: <your_consumer_key>
CONSUMER_SECRET: <your-consumer-secret>
# ...
| Field | Type | Description |
|---|---|---|
| FEATURE_GITLAB_BUILD | Boolean | Whether to support GitLab build triggers. Default: False |
| GITLAB_TRIGGER_CONFIG | Object | Configuration for using Gitlab for build triggers. |
| .GITLAB_ENDPOINT (Required) | String | The endpoint at which Gitlab Enterprise is running. |
| .CLIENT_ID (Required) | String | The registered client ID for this Red Hat Quay instance. |
| .CLIENT_SECRET (Required) | String | The registered client secret for this Red Hat Quay instance. |
GitLab build triggers example YAML
# ...
FEATURE_GITLAB_BUILD: true
GITLAB_TRIGGER_CONFIG:
GITLAB_ENDPOINT: https://gitlab.example.com/
CLIENT_ID: <your_gitlab_client_id>
CLIENT_SECRET: <your_gitlab_client_secret>
# ...
9.9.2. Build manager configuration fields Copy linkLink copied to clipboard!
The following configuration fields control how the build manager component of Red Hat Quay orchestrates and manages container image builds. This includes settings for Redis coordination, executor backends such as Kubernetes or EC2, builder image configuration, and advanced scheduling and retry policies.
These fields must be configured to align with your infrastructure environment and workload requirements.
| Field | Type | Description |
|---|---|---|
| ALLOWED_WORKER_COUNT | String |
Defines how many Build Workers are instantiated per Red Hat Quay pod. Typically set to |
| ORCHESTRATOR_PREFIX | String | Defines a unique prefix to be added to all Redis keys. This is useful to isolate Orchestrator values from other Redis keys. |
| REDIS_HOST | Object | The hostname for your Redis service. |
| REDIS_PASSWORD | String | The password to authenticate into your Redis service. |
| REDIS_SSL | Boolean | Defines whether or not your Redis connection uses SSL/TLS. |
| REDIS_SKIP_KEYSPACE_EVENT_SETUP | Boolean |
By default, Red Hat Quay does not set up the keyspace events required for key events at runtime. To do so, set |
| EXECUTOR | String |
Starts a definition of an Executor of this type. Valid values are |
| BUILDER_NAMESPACE | String | Kubernetes namespace where Red Hat Quay Builds will take place. |
| K8S_API_SERVER | Object | Hostname for API Server of the OpenShift Container Platform cluster where Builds will take place. |
| K8S_API_TLS_CA | Object |
The filepath in the |
| KUBERNETES_DISTRIBUTION | String |
Indicates which type of Kubernetes is being used. Valid values are |
| CONTAINER_* | Object |
Define the resource requests and limits for each |
| NODE_SELECTOR_* | Object |
Defines the node selector label name-value pair where |
| CONTAINER_RUNTIME | Object |
Specifies whether the Builder should run |
| SERVICE_ACCOUNT_NAME/SERVICE_ACCOUNT_TOKEN | Object |
Defines the Service Account name or token that will be used by |
| QUAY_USERNAME/QUAY_PASSWORD | Object |
Defines the registry credentials needed to pull the Red Hat Quay build worker image that is specified in the |
| WORKER_IMAGE | Object | Image reference for the Red Hat Quay Builder image. registry.redhat.io/quay/quay-builder |
| WORKER_TAG | Object | Tag for the Builder image desired. The latest version is 3.18. |
| BUILDER_VM_CONTAINER_IMAGE | Object |
The full reference to the container image holding the internal VM needed to run each Red Hat Quay Build. ( |
| SETUP_TIME | String |
Specifies the number of seconds at which a Build times out if it has not yet registered itself with the Build Manager. Defaults at |
| MINIMUM_RETRY_THRESHOLD | String |
This setting is used with multiple Executors. It indicates how many retries are attempted to start a Build before a different Executor is chosen. Setting to |
| SSH_AUTHORIZED_KEYS | Object |
List of SSH keys to bootstrap in the |
Build manager configuration fields
# ...
ALLOWED_WORKER_COUNT: "1"
ORCHESTRATOR_PREFIX: "quaybuild:"
REDIS_HOST: redis.example.com
REDIS_PASSWORD: examplepassword
REDIS_SSL: true
REDIS_SKIP_KEYSPACE_EVENT_SETUP: false
EXECUTOR: kubernetes
BUILDER_NAMESPACE: quay-builder
K8S_API_SERVER: https://api.openshift.example.com:6443
K8S_API_TLS_CA: /etc/ssl/certs/ca.crt
KUBERNETES_DISTRIBUTION: openshift
CONTAINER_RUNTIME: podman
CONTAINER_MEMORY_LIMITS: 2Gi
NODE_SELECTOR_ROLE: quay-build-node
SERVICE_ACCOUNT_NAME: quay-builder-sa
QUAY_USERNAME: quayuser
QUAY_PASSWORD: quaypassword
WORKER_IMAGE: quay.io/quay/quay-builder
WORKER_TAG: latest
BUILDER_VM_CONTAINER_IMAGE: quay.io/quay/vm-builder:latest
SETUP_TIME: "500"
MINIMUM_RETRY_THRESHOLD: "1"
SSH_AUTHORIZED_KEYS:
- ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAsomekey user@example.com
- ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAnotherkey user2@example.com
# ...
9.9.3. Build logs configuration fields Copy linkLink copied to clipboard!
The following configuration fields are used for managing build logs in Red Hat Quay. These settings determine where build logs are archived, who can access them, and how they are stored.
| Field | Type | Description |
|---|---|---|
| FEATURE_READER_BUILD_LOGS | Boolean |
If set to true, build logs can be read by those with
Default: |
| LOG_ARCHIVE_LOCATION | String |
The storage location, defined in |
| LOG_ARCHIVE_PATH | String |
The path under the configured storage engine in which to place the archived build logs in |
Build logs example YAML
# ...
FEATURE_READER_BUILD_LOGS: true
LOG_ARCHIVE_LOCATION: s3_us_east
LOG_ARCHIVE_PATH: archives/buildlogs
# ...
9.10. Tag and image management Copy linkLink copied to clipboard!
The following configuration fields control how tags and images are managed within Red Hat Quay. These settings help automate image cleanup, manage repository mirrors, and enhance performance through caching.
You can use these fields to:
- Define expiration policies for untagged or outdated images.
- Enable and schedule mirroring of external repositories into your registry.
- Leverage model caching to optimize performance for tag and repository operations.
These options help maintain an up-to-date image registry environment.
9.10.1. Image activity tracking configuration fields Copy linkLink copied to clipboard!
The following configuration fields are available to track image activities. When enabled, clear visibility into how often and when image tags are pulled are provided in the UI.
| Field | Type | Description |
|---|---|---|
| FEATURE_IMAGE_PULL_STATS | Boolean | Whether to track and display image pull statistics. Default: False |
| REDIS_FLUSH_INTERVAL_SECONDS | Integer | Interval, in seconds, at which the Redis flush worker clears old data. Shorter intervals keep data fresher and help prevent Redis from bloating, while longer intervals reduce flush frequency. Default: 300 (5 minutes) |
| PULL_METRICS_REDIS | Object |
Connection settings for the Redis database used to store image pull metrics. The Default: {"host": "<redis_host>", "password": "<redis_password>", "port": "<port>", "db": 1} |
Image activity tracking example YAML
# ...
FEATURE_IMAGE_PULL_STATS: true
REDIS_FLUSH_INTERVAL_SECONDS: 30
PULL_METRICS_REDIS:
host: <redis_host>
password: <redis_password>
port: 6379
db: 1
# ...
9.10.2. Tag expiration configuration fields Copy linkLink copied to clipboard!
The following configuration fields are available to automate tag expiration and garbage collection. These features help manage storage usage by enabling cleanup of unused or expired tags based on defined policies.
| Field | Type | Description |
|---|---|---|
| FEATURE_GARBAGE_COLLECTION | Boolean | Whether garbage collection of repositories is enabled. Default: True |
| TAG_EXPIRATION_OPTIONS (Required) | Array of string |
If enabled, the options that users can select for expiration of tags in their namespace. Pattern: |
| DEFAULT_TAG_EXPIRATION (Required) | String |
The default, configurable tag expiration time for time machine. Pattern:
Default: |
| FEATURE_CHANGE_TAG_EXPIRATION | Boolean | Whether users and organizations are allowed to change the tag expiration for tags in their namespace. Default: True |
| FEATURE_AUTO_PRUNE | Boolean |
When set to
Default: |
| NOTIFICATION_TASK_RUN_MINIMUM_INTERVAL_MINUTES | Integer | The interval, in minutes, that defines the frequency to re-run notifications for expiring images.
Default: |
| DEFAULT_NAMESPACE_AUTOPRUNE_POLICY | Object | The default organization-wide auto-prune policy. |
| .method: number_of_tags | Object | The option specifying the number of tags to keep. |
| .value: <integer> | Integer |
When used with method: number_of_tags, denotes the number of tags to keep. For example, to keep two tags, specify |
| .creation_date | Object | The option specifying the duration of which to keep tags. |
| .value: <integer> | Integer |
When used with creation_date, denotes how long to keep tags. Can be set to seconds ( |
| AUTO_PRUNING_DEFAULT_POLICY_POLL_PERIOD | Integer | The period in which the auto-pruner worker runs at the registry level. By default, it is set to run one time per day (one time per 24 hours). Value must be in seconds. |
| FEATURE_IMAGE_EXPIRY_TRIGGER | Boolean | Allows users to set up notifications on image expiration. Notifications are only returned on the v2 UI. Default: False |
Example tag expiration example YAML
# ...
FEATURE_GARBAGE_COLLECTION: true
TAG_EXPIRATION_OPTIONS:
- 1w
- 2w
- 1m
- 90d
DEFAULT_TAG_EXPIRATION: 2w
FEATURE_CHANGE_TAG_EXPIRATION: true
FEATURE_AUTO_PRUNE: true
NOTIFICATION_TASK_RUN_MINIMUM_INTERVAL_MINUTES: 300
DEFAULT_NAMESPACE_AUTOPRUNE_POLICY:
method: number_of_tags
value: 10
AUTO_PRUNING_DEFAULT_POLICY_POLL_PERIOD: 86400
FEATURE_IMAGE_EXPIRY_TRIGGER: false
# ...
DEFAULT_NAMESPACE_AUTOPRUNE_POLICY.value- Specifies ten tags to remain.
Registry auto-prune policy by creation date example YAML
# ...
DEFAULT_NAMESPACE_AUTOPRUNE_POLICY:
method: creation_date
value: 1y
# ...
DEFAULT_NAMESPACE_AUTOPRUNE_POLICY.value- Specifies tags to be pruned one year after their creation date.
9.10.3. Immutable tags configuration fields Copy linkLink copied to clipboard!
The following configuration field is available to enable immutable tags. Immutable tag policies prevent tags from being overwritten in Red Hat Quay.
| Field | Type | Description |
|---|---|---|
| FEATURE_IMMUTABLE_TAGS | Boolean | Whether to enable immutability policies. Immutability can be set at the individual setting level and via a policy in the repository configuration by an administrator. Default: False |
Immutable tags example YAML
# ...
FEATURE_IMMUTABLE_TAGS: true
# ...
9.11. Mirroring configuration fields for repositories Copy linkLink copied to clipboard!
Mirroring in Red Hat Quay enables automatic synchronization of repositories with upstream sources. This feature is useful for maintaining local mirrors of remote container images, ensuring availability in disconnected environments or improving performance through caching.
| Field | Type | Description |
|---|---|---|
| FEATURE_REPO_MIRROR | Boolean | Enable or disable repository mirroring.
Default: |
| REPO_MIRROR_INTERVAL | Number | The number of seconds between checking for repository mirror candidates. Default: 30 |
| REPO_MIRROR_SERVER_HOSTNAME | String |
Replaces the Default: None
Example: |
| REPO_MIRROR_TLS_VERIFY | Boolean | Require HTTPS and verify certificates of Quay registry during mirror.
Default: |
| REPO_MIRROR_ROLLBACK | Boolean |
When set to
Default: |
| FEATURE_SPARSE_INDEX | Boolean | Whether to allow sparse manifest indexes where not all architectures are required to be present. Default: False |
| REPO_MIRROR_MAX_MANIFEST_LIST_SIZE | Integer | Maximum size in bytes of manifest list JSON to parse during mirroring. Prevents DoS via oversized manifests.
Default: |
| REPO_MIRROR_MAX_MANIFEST_ENTRIES | Integer |
Maximum number of manifest entries to process during architecture-filtered mirroring. Prevents DoS via manifest lists with excessive entries. Default: |
Mirroring configuration example YAML
# ...
FEATURE_REPO_MIRROR: true
REPO_MIRROR_INTERVAL: 30
REPO_MIRROR_SERVER_HOSTNAME: "openshift-quay-service"
REPO_MIRROR_TLS_VERIFY: true
REPO_MIRROR_ROLLBACK: false
FEATURE_SPARSE_INDEX: true
REPO_MIRROR_MAX_MANIFEST_LIST_SIZE: 10485760
REPO_MIRROR_MAX_MANIFEST_ENTRIES: 1000
# ...
9.12. Organization mirroring configuration fields Copy linkLink copied to clipboard!
The following configuration fields are used for organization-level mirroring intervals, batch sizes, and related proxy cache settings.
| Field | Type | Description |
|---|---|---|
| FEATURE_ORG_MIRROR | Boolean | Enable or disable organization-level mirroring.
Default: |
| ORG_MIRROR_INTERVAL | Integer | Worker processing interval in seconds. Default: 30 |
| ORG_MIRROR_BATCH_SIZE | Integer | Number of organization mirrors to process for each iteration. Default: 100 |
| ORG_MIRROR_MAX_SYNC_DURATION | Integer | Maximum sync duration in seconds. Default: 3600 |
| ORG_MIRROR_DEFAULT_SKOPEO_TIMEOUT | Integer | Default skopeo timeout in seconds. Default: 300 |
| ORG_MIRROR_DISCOVERY_TIMEOUT | Integer | Discovery timeout in seconds. Default: 600 |
| ORG_MIRROR_MAX_REPOS_PER_ORG | Integer | Maximum repositories to discover for each organization. Default: 10000 |
| ORG_MIRROR_MAX_RETRIES | Integer | Maximum sync retries for a failure operation. Default: 3 |
| SSRF_ALLOWED_HOSTS | List | Allowed hosts for the Server Side Request Forgery (SSRF) protection. Use optional field to allow specific hosts to be accessed by the registry. |
| FEATURE_PROXY_CACHE | Boolean | Enables Red Hat Quay to act as a pull through cache for upstream registries. |
| FEATURE_REPO_MIRROR | Boolean | Enable or disable repository mirroring. |
Organization mirroring configuration example YAML
# ...
FEATURE_ORG_MIRROR: true
ORG_MIRROR_INTERVAL: 60
ORG_MIRROR_BATCH_SIZE: 100
ORG_MIRROR_MAX_SYNC_DURATION: 3600
ORG_MIRROR_DEFAULT_SKOPEO_TIMEOUT: 600
ORG_MIRROR_DISCOVERY_TIMEOUT: 600
ORG_MIRROR_MAX_REPOS_PER_ORG: 5000
ORG_MIRROR_MAX_RETRIES: 3
SSRF_ALLOWED_HOSTS:
- harbor.example.lab
FEATURE_PROXY_CACHE: true
FEATURE_REPO_MIRROR: true
# ...
9.13. ModelCache configuration fields Copy linkLink copied to clipboard!
ModelCache is a caching mechanism used by Red Hat Quay to store accessed data and reduce database load. Quay supports multiple backends for caching, including the default Memcache, as well as Redis and Redis Cluster.
- Memcache (default): requires no additional configuration.
- Redis: can be configured as a single instance or with a read-only replica.
- Redis Cluster: provides high availability and sharding for larger deployments.
| Field | Type | Description |
|---|---|---|
| DATA_MODEL_CACHE_CONFIG.engine | String |
The cache backend engine. Values: |
| .redis_config.primary.host | String |
The hostname of the primary Redis instance when using the |
| .redis_config.primary.port | Number | The port used by the primary Redis instance. |
| .redis_config.primary.password | String |
The password for authenticating with the primary Redis instance. Only required if |
| .redis_config.primary.ssl | Boolean | Whether to use SSL/TLS for the primary Redis connection. |
| .redis_config.startup_nodes | Array of Map |
For |
| redis_config.password | String |
Password used for authentication with the Redis cluster. Required if |
| .redis_config.read_from_replicas | Boolean | Whether to allow read operations from Redis cluster replicas. |
| .redis_config.skip_full_coverage_check | Boolean | If set to true, skips the Redis cluster full coverage check. |
| .redis_config.ssl | Boolean | Whether to use SSL/TLS for Redis cluster communication. |
| .replica.host | String | The hostname of the Redis replica instance. Optional. |
| .replica.port | Number | The port used by the Redis replica instance. |
| .replica.password | String |
The password for the Redis replica. Required if |
| .replica.ssl | Boolean | Whether to use SSL/TLS for the Redis replica connection. |
Single Redis with optional replica example YAML
# ...
DATA_MODEL_CACHE_CONFIG:
engine: redis
redis_config:
primary:
host: <redis-primary.example.com>
port: 6379
password: <redis_password>>
ssl: true
replica:
host: <redis-replica.example.com>
port: 6379
password: <redis_password>
ssl: true
# ...
Clustered Redis example YAML
# ...
DATA_MODEL_CACHE_CONFIG:
engine: <rediscluster>
redis_config:
startup_nodes:
- host: <redis-node-1.example.com>
port: 6379
- host: <redis-node-2.example.com>
port: 6379
password: <cluster_password>
read_from_replicas: true
skip_full_coverage_check: true
ssl: true
# ...
9.14. Scanner and Metadata Copy linkLink copied to clipboard!
The following configuration fields connect vulnerability scanning, model card metadata, and OCI artifact referrers in Red Hat Quay.
These settings enable enhanced visibility and security by providing Red Hat Quay with the following options:
- Integrating with a vulnerability scanner to assess container images for known CVEs.
- Rendering AI/ML model metadata through model cards stored in the registry.
- Exposing relationships between container artifacts using the Referrers API, aligning with the OCI artifact specification.
Collectively, these features help improve software supply chain transparency, enforce security policies, and support emerging metadata-driven workflows.
9.14.1. Clair security scanner configuration fields Copy linkLink copied to clipboard!
The following configuration fields control how the Clair security scanner is enabled, how frequently it indexes new content, which endpoints are used, and how notifications are handled.
| Field | Type | Description |
|---|---|---|
| FEATURE_SECURITY_SCANNER | Boolean |
Enable or disable the security scanner Default: |
| FEATURE_SECURITY_NOTIFICATIONS | Boolean |
If the security scanner is enabled, turn on or turn off security notifications Default: |
| SECURITY_SCANNER_V4_REINDEX_THRESHOLD | String |
This parameter is used to determine the minimum time, in seconds, to wait before re-indexing a manifest that has either previously failed or has changed states since the last indexing. The data is calculated from the |
| SECURITY_SCANNER_V4_ENDPOINT | String |
The endpoint for the V4 security scanner Pattern: |
| SECURITY_SCANNER_V4_PSK | String | The generated pre-shared key (PSK) for Clair // TODO 36 Check that SECURITY_SCANNER_NOTIFICATIONS can be dropped // |
| SECURITY_SCANNER_NOTIFICATIONS | String | |
| SECURITY_SCANNER_ENDPOINT | String |
The endpoint for the V2 security scanner Pattern: |
| SECURITY_SCANNER_INDEXING_INTERVAL | Integer | This parameter is used to determine the number of seconds between indexing intervals in the security scanner. When indexing is triggered, Red Hat Quay will query its database for manifests that must be indexed by Clair. These include manifests that have not yet been indexed and manifests that previously failed indexing. Default: 30 |
| FEATURE_SECURITY_SCANNER_NOTIFY_ON_NEW_INDEX | Boolean | Whether to allow sending notifications about vulnerabilities for new pushes.
Default: |
| SECURITY_SCANNER_V4_MANIFEST_CLEANUP | Boolean | Whether the Red Hat Quay garbage collector removes manifests that are not referenced by other tags or manifests.
Default: |
| NOTIFICATION_MIN_SEVERITY_ON_NEW_INDEX | String |
Set minimal security level for new notifications on detected vulnerabilities. Avoids creation of large number of notifications after first index. If not defined, defaults to |
| SECURITY_SCANNER_V4_INDEX_MAX_LAYER_SIZE | String |
The maximum layer size allowed for indexing. If the layer size exceeds the configured size, the Red Hat Quay UI returns the following message:
Default: |
Security scanner YAML configuration
# ...
FEATURE_SECURITY_NOTIFICATIONS: true
FEATURE_SECURITY_SCANNER: true
FEATURE_SECURITY_SCANNER_NOTIFY_ON_NEW_INDEX: true
...
SECURITY_SCANNER_INDEXING_INTERVAL: 30
SECURITY_SCANNER_V4_MANIFEST_CLEANUP: true
SECURITY_SCANNER_V4_ENDPOINT: http://quay-server.example.com:8081
SECURITY_SCANNER_V4_PSK: MTU5YzA4Y2ZkNzJoMQ==
SERVER_HOSTNAME: quay-server.example.com
SECURITY_SCANNER_V4_INDEX_MAX_LAYER_SIZE: 8G
# ...
Recommended maximum is 10G.
9.14.1.1. Re-indexing with Clair v4 Copy linkLink copied to clipboard!
When Clair v4 indexes a manifest, the result should be deterministic. For example, the same manifest should produce the same index report. This is true until the scanners are changed, as using different scanners will produce different information relating to a specific manifest to be returned in the report. Because of this, Clair v4 exposes a state representation of the indexing engine (/indexer/api/v1/index_state) to determine whether the scanner configuration has been changed.
Red Hat Quay leverages this index state by saving it to the index report when parsing to Quay’s database. If this state has changed since the manifest was previously scanned, Red Hat Quay will attempt to re-index that manifest during the periodic indexing process.
By default this parameter is set to 30 seconds. Users might decrease the time if they want the indexing process to run more frequently, for example, if they did not want to wait 30 seconds to see security scan results in the UI after pushing a new tag. Users can also change the parameter if they want more control over the request pattern to Clair and the pattern of database operations being performed on the Red Hat Quay database.
9.14.2. Model card rendering configuration fields Copy linkLink copied to clipboard!
The following configuration fields enable Red Hat Quay to display Model Card metadata in the UI for OCI-compliant machine learning images. Model Cards are a form of metadata documentation commonly used in machine learning workflows to improve the visibility and management of model-related content within OCI-compliant images.
| Field | Type | Description |
|---|---|---|
| FEATURE_UI_MODELCARD | Boolean |
Enables Model Card image tab in UI. Defaults to |
| UI_MODELCARD_ARTIFACT_TYPE | String | Defines the model card artifact type. |
| UI_MODELCARD_ANNOTATION | Object | This optional field defines the layer annotation of the model card stored in an OCI image. |
| UI_MODELCARD_LAYER_ANNOTATION | Object | This optional field defines the layer annotation of the model card stored in an OCI image. |
Model card example YAML
FEATURE_UI_MODELCARD: true
UI_MODELCARD_ARTIFACT_TYPE: application/x-mlmodel
UI_MODELCARD_ANNOTATION:
org.opencontainers.image.description: "Model card metadata"
UI_MODELCARD_LAYER_ANNOTATION:
org.opencontainers.image.title: README.md
where:
FEATURE_UI_MODELCARD- Specifies enabling the Model Card image tab in the UI.
UI_MODELCARD_ARTIFACT_TYPE-
Specifies the model card artifact type. In this example, the artifact type is
application/x-mlmodel. UI_MODELCARD_ANNOTATION-
Specifies manifest-level annotation lookup when an image does not have an
artifactTypedefined. If a matching annotation is found, the system then searches for a layer with an annotation matchingUI_MODELCARD_LAYER_ANNOTATION. This field is optional. UI_MODELCARD_LAYER_ANNOTATION-
Specifies the layer annotation used to locate the specific layer containing the model card when an image has an
artifactTypedefined and multiple layers. This field is optional.
9.14.3. Open Container Initiative referrers API configuration field Copy linkLink copied to clipboard!
The following configuration field enables the OCI referrers API to retrieve and manage artifact referrers attached to container images. This configuration field can help improve container image management.
| Field | Type | Description |
|---|---|---|
| FEATURE_REFERRERS_API | Boolean | Enables OCI 1.1’s referrers API. |
OCI referrers enablement example YAML
# ...
FEATURE_REFERRERS_API: True
# ...
9.15. Quota management and proxy cache features Copy linkLink copied to clipboard!
The following configuration fields enforce storage quotas and enable proxy caching of upstream registry images in Red Hat Quay.
These features help registry administrators with the following:
- Controlling how much storage organizations and users consume with configurable quotas.
- Improving access to upstream images by caching remote content locally via proxy cache.
- Monitoring and managing resource consumption and availability across distributed environments.
Collectively, these capabilities ensure better performance, governance, and resiliency in managing container image workflows.
9.15.1. Quota management configuration fields Copy linkLink copied to clipboard!
The following configuration fields enable and customize quota management functionality in Red Hat Quay. Quota management helps administrators enforce storage usage policies at the organization level by allowing them to set usage limits, calculate blob sizes, and control tag deletion behavior.
| Field | Type | Description |
|---|---|---|
| FEATURE_QUOTA_MANAGEMENT | Boolean | Enables configuration, caching, and validation for quota management feature.
Default: |
| FEATURE_QUOTA_NOTIFICATIONS | Boolean | Enables external notification channels, such as email, for quota threshold alerts. When enabled, namespace owners receive proactive notifications when storage consumption crosses configured warning or critical thresholds.
Default: |
| FEATURE_MAILING | Boolean |
Enables email delivery features across Red Hat Quay. Must be
Default: |
| QUOTA_NOTIFICATION_COOLDOWN_SECONDS | Integer |
Cooldown period in seconds before re-sending a quota notification for the same threshold (default: 86400 / 24 hours). The system prevents repeated notifications for the same namespace and threshold combination within this window. If storage usage drops below a threshold and later crosses the threshold again, the notification state is cleared and the notification will re-fire upon the new crossing. Notification claims (
Default: |
| QUOTA_NOTIFICATION_WORKER_POLL_PERIOD | Integer |
How often, in seconds, the quota notification background worker polls for threshold crossings that occur between image pushes—for example, when an administrator lowers a quota limit. Default:
Default: |
| DEFAULT_SYSTEM_REJECT_QUOTA_BYTES | String | Enables system default quota reject byte allowance for all organizations. By default, no limit is set. |
| QUOTA_BACKFILL | Boolean | Enables the quota backfill worker to calculate the size of pre-existing blobs.
Default: |
| QUOTA_TOTAL_DELAY_SECONDS | String | The time delay for starting the quota backfill. Rolling deployments can cause incorrect totals. This field must be set to a time longer than it takes for the rolling deployment to complete.
Default: |
| PERMANENTLY_DELETE_TAGS | Boolean | Enables functionality related to the removal of tags from the time machine window.
Default: |
| RESET_CHILD_MANIFEST_EXPIRATION | Boolean |
Resets the expirations of temporary tags targeting the child manifests. With this feature set to
Default: |
Quota management example YAML
# ...
FEATURE_QUOTA_MANAGEMENT: true
FEATURE_QUOTA_NOTIFICATIONS: true
DEFAULT_SYSTEM_REJECT_QUOTA_BYTES: "100gb"
QUOTA_BACKFILL: true
QUOTA_TOTAL_DELAY_SECONDS: 3600
QUOTA_NOTIFICATION_COOLDOWN_SECONDS: 86400
QUOTA_NOTIFICATION_WORKER_POLL_PERIOD: 300
PERMANENTLY_DELETE_TAGS: true
RESET_CHILD_MANIFEST_EXPIRATION: true
# ...
9.15.2. Proxy cache configuration fields Copy linkLink copied to clipboard!
The following configuration field enables Red Hat Quay to act as a pull-through cache for upstream container registries. When FEATURE_PROXY_CACHE is enabled, Red Hat Quay can cache images that are pulled from external registries, reducing bandwidth consumption and improving image retrieval speed on subsequent requests.
| Field | Type | Description |
|---|---|---|
| FEATURE_PROXY_CACHE | Boolean | Enables Red Hat Quay to act as a pull through cache for upstream registries.
Default: |
Proxy cache example YAML
# ...
FEATURE_PROXY_CACHE: true
# ...
9.16. QuayIntegration configuration fields Copy linkLink copied to clipboard!
The QuayIntegration custom resource enables integration between your OpenShift Container Platform cluster and a Red Hat Quay registry instance.
Additional resources
| Name | Description | Schema |
|---|---|---|
| allowlistNamespaces (Optional) | A list of namespaces to include. | Array |
| clusterID (Required) | The ID associated with this cluster. | String |
| credentialsSecret.key (Required) | The secret containing credentials to communicate with the Quay registry. | Object |
| denylistNamespaces (Optional) | A list of namespaces to exclude. | Array |
| insecureRegistry (Optional) | Whether to skip TLS verification to the Quay registry | Boolean |
| quayHostname (Required) | The hostname of the Quay registry. | String |
| scheduledImageStreamImport (Optional) | Whether to enable image stream importing. | Boolean |
QuayIntegration example CR
apiVersion: quay.redhat.com/v1
kind: QuayIntegration
metadata:
name: example-quayintegration
spec:
clusterID: 1df512fc-bf70-11ee-bb31-001a4a160100
quayHostname: quay.example.com
credentialsSecret:
name: quay-creds-secret
key: token
allowlistNamespaces:
- dev-team
- prod-team
denylistNamespaces:
- test
insecureRegistry: false
scheduledImageStreamImport: true
9.17. Mail configuration fields Copy linkLink copied to clipboard!
The following configuration fields allow Red Hat Quay to connect to your SMTP server. With these fields, you can send account confirmation, password reset, and security alerts.
| Field | Type | Description |
|---|---|---|
| FEATURE_MAILING | Boolean | Whether emails are enabled
Default: |
| MAIL_DEFAULT_SENDER | String |
If specified, the e-mail address used as the
Example: |
| MAIL_PASSWORD | String | The SMTP password to use when sending e-mails |
| MAIL_PORT | Number | The SMTP port to use. If not specified, defaults to 587. |
| MAIL_SERVER | String | The SMTP server to use for sending e-mails. Only required if FEATURE_MAILING is set to true.
Example: |
| MAIL_USERNAME | String | The SMTP username to use when sending e-mails |
| MAIL_USE_TLS | Boolean | If specified, whether to use TLS for sending e-mails
Default: |
Mail example YAML
# ...
FEATURE_MAILING: true
MAIL_DEFAULT_SENDER: "support@example.com"
MAIL_SERVER: "smtp.example.com"
MAIL_PORT: 587
MAIL_USERNAME: "smtp-user@example.com"
MAIL_PASSWORD: "your-smtp-password"
MAIL_USE_TLS: true
# ...