Chapter 10. 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.

10.1. Core configuration overview

Use these core fields to configure the registry’s basic behavior, including hostname, protocol, authentication settings, and more.

10.1.1. Registry branding and identity fields

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.

Note

Some of the following fields are not available on the Red Hat Quay v2 UI.

Expand
Table 10.1. Registry branding and identity configuration fields
FieldTypeDescription

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:
Red Hat Quay

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:
Red Hat Quay

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:
^mailto:(.)+$
Example:
mailto:support@quay.io

[1]

String

Adds a link to visit an IRC chat room.

Pattern:
^irc://(.)+$
Example:
irc://chat.freenode.net:6665/quay

[2]

String

Adds a link to call a phone number.

Pattern:
^tel:(.)+$
Example:
tel:+1-888-930-3475

[3]

String

Adds a link to a defined URL.

Pattern:
^http(s)?://(.)+$
Example:
https://twitter.com/quayio

Expand
Table 10.2. Branding configuration fields
FieldTypeDescription

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:
/static/img/quay-horizontal-color.svg

.footer_img

String

Logo for UI footer. Defaults to 144x34 PX.

Example:
/static/img/RedHat.svg

.footer_url

String

Link for footer image.

Example:
https://redhat.com

Expand
Table 10.3. Footer links configuration fields
FieldTypeDescription

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:
https://index.hr

.PRIVACY_POLICY_URL

String

Custom privacy policy for on-prem installations.

Example:
https://example.hr

.SECURITY_URL

String

Custom security page for on-prem installations.

Example:
https://example.hr

.ABOUT_URL

String

Custom about page for on-prem installations.

Example:
https://example.hr

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"
# ...
Copy to Clipboard Toggle word wrap

10.1.2. SSL/TLS configuration fields

This section describes the available configuration fields for enabling and managing SSL/TLS encryption in your Red Hat Quay deployment.

Additional resources

Expand
Table 10.4. SSL configuration fields
FieldTypeDescription

PREFERRED_URL_SCHEME

String

One of http or https. Note that users only set their PREFERRED_URL_SCHEME to http when there is no TLS encryption in the communication path from the client to Quay.
Users must set their PREFERRED_URL_SCHEME`to `https when using a TLS-terminating load balancer, a reverse proxy (for example, Nginx), or when using Quay with custom SSL certificates directly. In most cases, the PREFERRED_URL_SCHEME should be https.
Default: http

SERVER_HOSTNAME
(Required)

String

The URL at which Red Hat Quay is accessible, without the scheme

Example:
quay-server.example.com

SSL_CIPHERS

Array of String

If specified, the nginx-defined list of SSL ciphers to enabled and disabled

Example:
[ECDHE-RSA-AES128-GCM-SHA256, ECDHE-ECDSA-AES128-GCM-SHA256, ECDHE-RSA-AES256-GCM-SHA384, ECDHE-ECDSA-AES256-GCM-SHA384, DHE-RSA-AES128-GCM-SHA256, DHE-DSS-AES128-GCM-SHA256, kEDH+AESGCM, ECDHE-RSA-AES128-SHA256, ECDHE-ECDSA-AES128-SHA256, ECDHE-RSA-AES128-SHA, ECDHE-ECDSA-AES128-SHA, ECDHE-RSA-AES256-SHA384, ECDHE-ECDSA-AES256-SHA384, ECDHE-RSA-AES256-SHA, ECDHE-ECDSA-AES256-SHA, DHE-RSA-AES128-SHA256, DHE-RSA-AES128-SHA, DHE-DSS-AES128-SHA256, DHE-RSA-AES256-SHA256, DHE-DSS-AES256-SHA, DHE-DSS-AES256-SHA, AES128-GCM-SHA256, AES256-GCM-SHA384, AES128-SHA256, AES256-SHA256, AES128-SHA, AES256-SHA, AES, !3DES", !aNULL, !eNULL, !EXPORT, DES, !RC4, MD5, !PSK, !aECDH, !EDH-DSS-DES-CBC3-SHA, !EDH-RSA-DES-CBC3-SHA, !KRB5-DES-CBC3-SHA]

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:
['TLSv1','TLSv1.1','TLSv1.2', `TLSv1.3]`

SESSION_COOKIE_SECURE

Boolean

Whether the secure property should be set on session cookies

Default:
False

Recommendation:
Set to True for all installations using SSL

EXTERNAL_TLS_TERMINATION

Boolean

Set to True if TLS is supported, but terminated at a layer before Quay. Set to False when Quay is running with its own SSL certificates and receiving TLS traffic directly.

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
# ...
Copy to Clipboard Toggle word wrap

10.1.3. IPv6 configuration field

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.

Expand
Table 10.5. IPv6 configuration field
FieldTypeDescription

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: IPv4Additional configurations: IPv6, dual-stack

IPv6 example YAML

# ...
FEATURE_LISTEN_IP_VERSION: dual-stack
# ...
Copy to Clipboard Toggle word wrap

10.1.4. Logging and debugging variables

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

Expand
Table 10.6. Logging and debug configuration variables
VariableTypeDescription

DEBUGLOG

Boolean

Whether to enable or disable debug logs.

USERS_DEBUG

Integer. Either 0 or 1.

Used to debug LDAP operations in clear text, including passwords. Must be used with DEBUGLOG=TRUE.

Important

Setting USERS_DEBUG=1 exposes credentials in clear text. This variable should be removed from the Red Hat Quay deployment after debugging. The log file that is generated with this environment variable should be scrutinized, and passwords should be removed before sending to other users. Use with caution.

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: ('RDSAwareHealthCheck', {'access_key': 'foo', 'secret_key': 'bar'})

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
# ...
Copy to Clipboard Toggle word wrap

Additional resources

The following configuration fields control the operational state of the Red Hat Quay registry and how it interacts with external systems. These settings allow administrators to place the registry into a restricted read-only mode for maintenance purposes, and to enforce additional security by blocking specific hostnames from being targeted by webhooks.

Expand
Table 10.7. Registry state and system behavior configuration fields
FieldTypeDescription

REGISTRY_STATE

String

The state of the registry

Values: normal or read-only

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"
# ...
Copy to Clipboard Toggle word wrap

10.2. User Experience and Interface

These 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.

These 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.

Expand
Table 10.8. Web UI and UX configuration fields
FieldTypeDescription

AVATAR_KIND

String

The types of avatars to display, either generated inline (local) or Gravatar (gravatar)

Values: local, gravatar

FRESH_LOGIN_TIMEOUT

String

The time after which a fresh login requires users to re-enter their password

Example: 5m

FEATURE_UI_V2

Boolean

When set, allows users to try the v2 beta UI environment.

Default: True

FEATURE_UI_V2_REPO_SETTINGS

Boolean

When set to True, enables repository settings in the Red Hat Quay v2 UI.

+ Default: False

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 _catalog endpoint returns public repositories. Otherwise, only private repositories can be returned.

Default: False

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
# ...
Copy to Clipboard Toggle word wrap

10.2.1.1. v2 user interface configuration

With FEATURE_UI_V2 enabled, you can toggle between the current version of the user interface and the new version of the user interface.

Important
  • 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.

10.2.2. Session timeout configuration field

The following configuration field relies on on the Flask API configuration field of the same name.

Important

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.

Expand
Table 10.9. Session logout configuration field
FieldTypeDescription

PERMANENT_SESSION_LIFETIME

Integer

A timedelta which is used to set the expiration date of a permanent session. The default is 31 days, which makes a permanent session survive for roughly one month.

Default: 2678400

Session timeout example YAML

# ...
PERMANENT_SESSION_LIFETIME: 3000
# ...
Copy to Clipboard Toggle word wrap

10.3. User and Access Management

Use these 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.

10.3.1. User configuration fields

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.

Expand
Table 10.10. User configuration fields
FieldTypeDescription

FEATURE_SUPER_USERS

Boolean

Whether superusers are supported

Default: True

FEATURE_USER_CREATION

Boolean

Whether users can be created (by non-superusers)

Default: True

FEATURE_USER_LAST_ACCESSED

Boolean

Whether to record the last time a user was accessed

Default: True

FEATURE_USER_LOG_ACCESS

Boolean

If set to true, users will have access to audit logs for their namespace

Default: False

FEATURE_USER_METADATA

Boolean

Whether to collect and support user metadata

Default: False

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: True

FEATURE_USER_RENAME

Boolean

If set to true, users can rename their own namespace

Default: False

FEATURE_INVITE_ONLY_USER_CREATION

Boolean

Whether users being created must be invited by another user

Default: False

FRESH_LOGIN_TIMEOUT

String

The time after which a fresh login requires users to re-enter their password

Example: 5m

USERFILES_LOCATION

String

ID of the storage engine in which to place user-uploaded files

Example: s3_us_east

USERFILES_PATH

String

Path under storage in which to place user-uploaded files

Example: userfiles

USER_RECOVERY_TOKEN_LIFETIME

String

The length of time a token for recovering a user accounts is valid

Pattern: ^[0-9]+(w|m|d|h|s)$
Default: 30m

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: False

FEATURE_SUPERUSERS_ORG_CREATION_ONLY

Boolean

Whether to only allow superusers to create organizations.

Default: False

FEATURE_SUPERUSER_CONFIGDUMP

Boolean

Enables a full config dump of the running Framework, environment and schema for validation.

Default: False

FEATURE_RESTRICTED_USERS

Boolean

When set to True with RESTRICTED_USERS_WHITELIST:

  • All normal users and superusers are restricted from creating organizations or content in their own namespace unless they are allowlisted via RESTRICTED_USERS_WHITELIST.
  • Restricted users retain their normal permissions within organizations based on team memberships.

Default: False

RESTRICTED_USERS_WHITELIST

String

When set with FEATURE_RESTRICTED_USERS: true, specific users are excluded from the FEATURE_RESTRICTED_USERS setting.

GLOBAL_READONLY_SUPER_USERS

String

When set, grants users of this list read access to all repositories, regardless of whether they are public repositories. Only works for those superusers defined with the SUPER_USERS configuration field.

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: 
1

      - user1
GLOBAL_READONLY_SUPER_USERS:
      - quayadmin
FRESH_LOGIN_TIMEOUT: "5m"
USER_RECOVERY_TOKEN_LIFETIME: "30m"
USERFILES_LOCATION: "s3_us_east"
USERFILES_PATH: "userfiles"
# ...
Copy to Clipboard Toggle word wrap

1
When the RESTRICTED_USERS_WHITELIST field is set, whitelisted 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.

10.3.2. Robot account configuration fields

The following configuration field allows for globally disallowing robot account creation and interaction.

Additional resources

Expand
Table 10.11. Robot account configuration fields
FieldTypeDescription

ROBOTS_DISALLOW

Boolean

When set to True, robot accounts are prevented from all interactions, as well as from being created
Default: False

Robot account disallow example YAML

# ...
ROBOTS_DISALLOW: true
# ...
Copy to Clipboard Toggle word wrap

10.3.3. LDAP configuration fields

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
Expand
Table 10.12. LDAP configuration
FieldTypeDescription

AUTHENTICATION_TYPE
(Required)

String

Must be set to LDAP.

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: True

FEATURE_NONSUPERUSER_TEAM_SYNCING_SETUP

Boolean

If enabled, non-superusers can setup team syncrhonization.

Default: False

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:
^[0-9]+(w|m|d|h|s)$
Example:
2h
Default:
30m

LDAP_SUPERUSER_FILTER

String

Subset of the LDAP_USER_FILTER configuration field. When configured, allows Red Hat Quay administrators the ability to configure Lightweight Directory Access Protocol (LDAP) users as superusers when Red Hat Quay uses LDAP as its authentication provider.

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 AUTHENTICATION_TYPE is set to LDAP.

LDAP_GLOBAL_READONLY_SUPERUSER_FILTER

String

When set, grants users of this list read access to all repositories, regardless of whether they are public repositories. Only works for those superusers defined with the LDAP_SUPERUSER_FILTER configuration field.

LDAP_RESTRICTED_USER_FILTER

String

Subset of the LDAP_USER_FILTER configuration field. When configured, allows Red Hat Quay administrators the ability to configure Lightweight Directory Access Protocol (LDAP) users as restricted users when Red Hat Quay uses LDAP as its authentication provider.

This field requires that your AUTHENTICATION_TYPE is set to LDAP.

FEATURE_RESTRICTED_USERS

Boolean

When set to True with LDAP_RESTRICTED_USER_FILTER active, only the listed users in the defined LDAP group are restricted.

Default: False

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 -l option in ldapsearch, it sets a client-side operation timeout.

Default: 10

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 -o nettimeout option in ldapsearch.

Default: 10

Basic LDAP configuration example YAML

# ...
AUTHENTICATION_TYPE: LDAP 
1

# ...
LDAP_ADMIN_DN: uid=<name>,ou=Users,o=<organization_id>,dc=<example_domain_component>,dc=com 
2

LDAP_ADMIN_PASSWD: ABC123 
3

LDAP_ALLOW_INSECURE_FALLBACK: false 
4

LDAP_BASE_DN: 
5

  - dc=example
  - dc=com
LDAP_EMAIL_ATTR: mail 
6

LDAP_UID_ATTR: uid 
7

LDAP_URI: ldap://<example_url>.com 
8

LDAP_USER_FILTER: (memberof=cn=developers,ou=Users,dc=<domain_name>,dc=com) 
9

LDAP_USER_RDN: 
10

  - ou=people
LDAP_SECONDARY_USER_RDNS: 
11

    - ou=<example_organization_unit_one>
    - ou=<example_organization_unit_two>
    - ou=<example_organization_unit_three>
    - ou=<example_organization_unit_four>
Copy to Clipboard Toggle word wrap

1
Required. Must be set to LDAP.
2
Required. The admin DN for LDAP authentication.
3
Required. The admin password for LDAP authentication.
4
Required. Whether to allow SSL/TLS insecure fallback for LDAP authentication.
5
Required. The base DN for LDAP authentication.
6
Required. The email attribute for LDAP authentication.
7
Required. The UID attribute for LDAP authentication.
8
Required. The LDAP URI.
9
Required. The user filter for LDAP authentication.
10
Required. The user RDN for LDAP authentication.
11
Optional. Secondary User Relative DNs if there are multiple Organizational Units where user objects are located.

LDAP restricted user configuration example YAML

# ...
AUTHENTICATION_TYPE: LDAP
# ...
FEATURE_RESTRICTED_USERS: true 
1

# ...
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>) 
2

LDAP_USER_RDN:
    - ou=<example_organization_unit>
    - o=<organization_id>
    - dc=<example_domain_component>
    - dc=com
# ...
Copy to Clipboard Toggle word wrap

1
Must be set to True when configuring an LDAP restricted user.
2
Configures specified 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>) 
1

LDAP_USER_RDN:
    - ou=<example_organization_unit>
    - o=<organization_id>
    - dc=<example_domain_component>
    - dc=com
# ...
Copy to Clipboard Toggle word wrap

1
Configures specified users as superusers.

10.3.4. OAuth configuration fields

The following 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.

Expand
Table 10.13. OAuth fields
FieldTypeDescription

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
# ...
Copy to Clipboard Toggle word wrap

Additional resources

Expand
Table 10.14. GitHub OAuth configuration fields
FieldTypeDescription

FEATURE_GITHUB_LOGIN

Boolean

Whether GitHub login is supported

**Default: False

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: https://api.github.com/

   .CLIENT_ID
   (Required)

String

The registered client ID for this Red Hat Quay instance; cannot be shared with GITHUB_TRIGGER_CONFIG.

Example: <client_id>

   .CLIENT_SECRET
   (Required)

String

The registered client secret for this Red Hat Quay instance.

Example: <client_secret>

   .GITHUB_ENDPOINT
   (Required)

String

The endpoint for GitHub (Enterprise).

Example: https://github.com/

   .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
# ...
Copy to Clipboard Toggle word wrap

Expand
Table 10.15. Google OAuth configuration fields
FieldTypeDescription

FEATURE_GOOGLE_LOGIN

Boolean

Whether Google login is supported.

**Default: False

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_id>

   .CLIENT_SECRET
   (Required)

String

The registered client secret for this Red Hat Quay instance.

Example: <client_secret>

Google OAuth example YAML

# ...
FEATURE_GOOGLE_LOGIN: true
GOOGLE_LOGIN_CONFIG:
  CLIENT_ID: <client_id>
  CLIENT_SECRET: <client_secret>
# ...
Copy to Clipboard Toggle word wrap

10.3.5. OIDC configuration fields

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.

Additional resources

Expand
Table 10.16. OIDC fields
FieldTypeDescription

<string>_LOGIN_CONFIG
(Required)

String

The parent key that holds the OIDC configuration settings. Typically the name of the OIDC provider, for example, AZURE_LOGIN_CONFIG, however any arbitrary string is accepted.

   .CLIENT_ID
(Required)

String

The registered client ID for this Red Hat Quay instance.

Example: 0e8dbe15c4c7630b6780

   .CLIENT_SECRET
(Required)

String

The registered client secret for this Red Hat Quay instance.

Example: e4a58ddd3d7408b7aec109e85564a0d153d3e846

   .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

Adds additional scopes that Red Hat Quay uses to communicate with the OIDC provider.

   .OIDC_ENDPOINT_CUSTOM_PARAMS

String

Support for custom query parameters on OIDC endpoints. The following endpoints are supported: authorization_endpoint, token_endpoint, and user_endpoint.

   .OIDC_ISSUER

String

Allows the user to define the issuer to verify. For example, JWT tokens container a parameter known as iss which defines who issued the token. By default, this is read from the .well-know/openid/configuration endpoint, which is exposed by every OIDC provider. If this verification fails, there is no login.

   .OIDC_SERVER
(Required)

String

The address of the OIDC server that is being used for authentication.

Example: https://sts.windows.net/6c878…​/

   .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: Microsoft Entra ID

   .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 /userinfo endpoint. If using Azure Entra ID, this field must be set to True because Azure obtains the user’s information from the token instead of calling the /userinfo endpoint.

Default: False

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_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
# ...
Copy to Clipboard Toggle word wrap

10.3.6. Recaptcha configuration fields

You can enable Recaptcha support in your Red Hat Quay instance to help protect user login and account recovery forms from abuse by automated systems.

Expand
Table 10.17. Recaptcha configuration fields
FieldTypeDescription

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>"
# ...
Copy to Clipboard Toggle word wrap

10.3.7. JWT configuration fields

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.

Expand
Table 10.18. JWT configuration fields
FieldTypeDescription

JWT_AUTH_ISSUER

String

The endpoint for JWT users

Pattern: ^http(s)?://(.)+$
Example: http://192.168.99.101:6060

JWT_GETUSER_ENDPOINT

String

The endpoint for JWT users
Pattern: ^http(s)?://(.)+$
Example: http://192.168.99.101:6060

JWT_QUERY_ENDPOINT

String

The endpoint for JWT queries

Pattern: ^http(s)?://(.)+$
Example: http://192.168.99.101:6060

JWT_VERIFY_ENDPOINT

String

The endpoint for JWT verification

Pattern: ^http(s)?://(.)+$
Example: http://192.168.99.101:6060

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"
# ...
Copy to Clipboard Toggle word wrap

10.3.8. App tokens configuration fields

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.

Expand
Table 10.19. App tokens configuration fields
FieldTypeDescription

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: ^[0-9]+(w|m|d|h|s)$

EXPIRED_APP_SPECIFIC_TOKEN_GC

String

Duration of time expired external app tokens will remain before being garbage collected

Default: 1d

App tokens example YAML

# ...
FEATURE_APP_SPECIFIC_TOKENS: true
APP_SPECIFIC_TOKEN_EXPIRATION: "30d"
EXPIRED_APP_SPECIFIC_TOKEN_GC: "1d"
# ...
Copy to Clipboard Toggle word wrap

10.4. Security and Permissions

This section describes configuration fields that govern core security behaviors and access policies within Red Hat Quay.

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.

Expand
Table 10.20. Namespace and repository management configuration fields
FieldTypeDescription

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 FEATURE_RATE_LIMITS, you can override it for specific namespace that require unlimited access.

DISABLE_PUSHES

Boolean

Disables pushes of new content to the registry while retaining all other functionality. Differs from read-only mode because database is not set as read-only. When DISABLE_PUSHES is set to True, the Red Hat Quay garbage collector is disabled. As a result, when PERMANENTLY_DELETE_TAGS is enabled, using the Red Hat Quay UI to permanently delete a tag does not result in the immediate deletion of a tag. Instead, the image stays in the backend storage until DISABLE_PUSHES is set to False, which re-enables the garbage collector. Red Hat Quay administrators should be aware of this caveat when using DISABLE_PUSHES and PERMANENTLY_DELETE_TAGS together.

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
# ...
Copy to Clipboard Toggle word wrap

10.4.2. Nested repositories configuration fields

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.

Expand
Table 10.21. Nested repositories configuration fields
FieldTypeDescription

FEATURE_EXTENDED_REPOSITORY_NAMES

Boolean

Enable support for nested repositories

Default: True

Nested repositories example YAML

# ...
FEATURE_EXTENDED_REPOSITORY_NAMES: true
# ...
Copy to Clipboard Toggle word wrap

10.5. Additional security configuration fields

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.

Expand
Table 10.22. Additional security configuration fields
FeatureTypeDescription

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
# ...
Copy to Clipboard Toggle word wrap

The following fields control rate limiting and performance-related behavior for your Red Hat Quay deployment.

Expand
Table 10.23. Rate limiting and performance configuration fields
FieldTypeDescription

FEATURE_RATE_LIMITS

Boolean

Whether to enable rate limits on API and registry endpoints. Setting FEATURE_RATE_LIMITS to True causes nginx to limit certain API calls to 30 per second. If that feature is not set, API calls are limited to 300 per second (effectively unlimited).

Default: False

PROMETHEUS_NAMESPACE

String

The prefix applied to all exposed Prometheus metrics

Default: quay

Rate limiting and performance example YAML

# ...
FEATURE_RATE_LIMITS: false
PROMETHEUS_NAMESPACE: quay
# ...
Copy to Clipboard Toggle word wrap

10.8. Storage and Data Management

This section describes the configuration fields that govern how Red Hat Quay stores, manages, and audits data.

10.8.1. Image storage features

Red Hat Quay supports image storage features that enhance scalability, resilience, and flexibility in managing container image data. These features allow Red Hat Quay to mirror repositories, proxy storage access through NGINX, and replicate data across multiple storage engines.

Expand
Table 10.25. Storage configuration features
FieldTypeDescription

FEATURE_REPO_MIRROR

Boolean

If set to true, enables repository mirroring.

Default: False

FEATURE_PROXY_STORAGE

Boolean

Whether to proxy all direct download URLs in storage through NGINX.

Default: False

FEATURE_STORAGE_REPLICATION

Boolean

Whether to automatically replicate between storage engines.

Default: False

Image storage example YAML

# ...
FEATURE_REPO_MIRROR: true
FEATURE_PROXY_STORAGE: false
FEATURE_STORAGE_REPLICATION: true
# ...
Copy to Clipboard Toggle word wrap

10.8.2. Action log storage configuration fields

Red Hat Quay maintains a detailed action log to track user and system activity, including repository events, authentication actions, and image operations. By default, this log data is stored in the database, but administrators can configure their deployment to export or forward logs to external systems like Elasticsearch or Splunk for advanced analysis, auditing, or compliance.

Expand
Table 10.26. Action log storage configuration fields
FieldTypeDescription

FEATURE_LOG_EXPORT

Boolean

Whether to allow exporting of action logs.

Default: True

LOGS_MODEL

String

Specifies the preferred method for handling log data.

Values: One of database, transition_reads_both_writes_es, elasticsearch, splunk
Default: database

LOGS_MODEL_CONFIG

Object

Logs model config for action logs.

ALLOW_WITHOUT_STRICT_LOGGING

Boolean

When set to True, if the external log system like Splunk or ElasticSearch is intermittently unavailable, allows users to push images normally. Events are logged to the stdout instead. Overrides ALLOW_PULLS_WITHOUT_STRICT_LOGGING if set.

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
# ...
Copy to Clipboard Toggle word wrap

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.

Expand
Table 10.27. Action log rotation and archiving configuration
FieldTypeDescription

FEATURE_ACTION_LOG_ROTATION

Boolean

Enabling log rotation and archival will move all logs older than 30 days to storage.

Default: False

ACTION_LOG_ARCHIVE_LOCATION

String

If action log archiving is enabled, the storage engine in which to place the archived data.

Example:: s3_us_east

ACTION_LOG_ARCHIVE_PATH

String

If action log archiving is enabled, the path in storage in which to place the archived data.

Example: archives/actionlogs

ACTION_LOG_ROTATION_THRESHOLD

String

The time interval after which to rotate logs.

Example: 30d

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
# ...
Copy to Clipboard Toggle word wrap

10.8.2.2. Action log audit configuration

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.

Expand
Table 10.28. Audit logs configuration field
FieldTypeDescription

ACTION_LOG_AUDIT_LOGINS

Boolean

When set to True, tracks advanced events such as logging into, and out of, the UI, and logging in using Docker for regular users, robot accounts, and for application-specific token accounts.

Default: True

Audit logs configuration example YAML

# ...
ACTION_LOG_AUDIT_LOGINS: true
# ...
Copy to Clipboard Toggle word wrap

10.8.3. Elasticsearch configuration fields

Use the following configuration fields to 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.

Expand
Table 10.29. Logs model configuration (LOGS_MODEL_CONFIG) fields
FieldTypeDescription

LOGS_MODEL_CONFIG.elasticsearch_config.access_key

String

Elasticsearch user (or IAM key for AWS ES).
Example: some_string

.elasticsearch_config.host

String

Elasticsearch cluster endpoint.
Example: host.elasticsearch.example

.elasticsearch_config.index_prefix

String

Prefix for Elasticsearch indexes.
Example: logentry_

.elasticsearch_config.index_settings

Object

Index settings for Elasticsearch.

LOGS_MODEL_CONFIG.elasticsearch_config.use_ssl

Boolean

Whether to use SSL for Elasticsearch.
Default: True
Example: True

.elasticsearch_config.secret_key

String

Elasticsearch password (or IAM secret for AWS ES).
Example: some_secret_string

.elasticsearch_config.aws_region

String

AWS region.
Example: us-east-1

.elasticsearch_config.port

Number

Port of the Elasticsearch cluster.
Example: 1234

.kinesis_stream_config.aws_secret_key

String

AWS secret key.
Example: some_secret_key

.kinesis_stream_config.stream_name

String

AWS Kinesis stream to send action logs to.
Example: logentry-kinesis-stream

.kinesis_stream_config.aws_access_key

String

AWS access key.
Example: some_access_key

.kinesis_stream_config.retries

Number

Max number of retry attempts for a single request.
Example: 5

.kinesis_stream_config.read_timeout

Number

Read timeout in seconds.
Example: 5

.kinesis_stream_config.max_pool_connections

Number

Max number of connections in the pool.
Example: 10

.kinesis_stream_config.aws_region

String

AWS region.
Example: us-east-1

.kinesis_stream_config.connect_timeout

Number

Connection timeout in seconds.
Example: 5

.producer

String

Logs producer type.
Accepted values: kafka, elasticsearch, kinesis_stream
Example: kafka

.kafka_config.topic

String

Kafka topic used to publish log entries.
Example: logentry

.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 send() operation.
Example: 10

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
# ...
Copy to Clipboard Toggle word wrap

10.8.3.1. Splunk configuration fields

Use the following fields to configure Red Hat Quay to export 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.

Expand
Table 10.30. Splunk configuration fields
FieldTypeDescription

producer

String

Must be set to splunk when configuring Splunk as the log exporter.

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 (True) or disable (False) TLS/SSL verification for HTTPS connections.

.index_prefix

String

The index prefix used by Splunk.

.ssl_ca_path

String

The relative container path to a .pem file containing the certificate authority (CA) for SSL validation.

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>
# ...
Copy to Clipboard Toggle word wrap

10.8.3.1.1. Splunk HEC configuration fields

The following fields are available when configuring Splunk HTTP Event Collector (HEC) for Red Hat Quay.

Expand
Table 10.31. Splunk HEC configuration fields
FieldTypeDescription

producer

String

Must be set to splunk_hec when configuring Splunk HTTP Event Collector (HEC).

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 https if Splunk is behind SSL/TLS.

.verify_ssl

Boolean

Enable (True) or disable (False) SSL/TLS verification for HTTPS connections.

.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 sourcetype to associate with the event.

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
# ...
Copy to Clipboard Toggle word wrap

10.9. Builds and Automation

This section outlines the configuration options available for managing 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.

Additional resources

10.9.1. Dockerfile build triggers fields

This section describes the configuration fields 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.

Expand
Table 10.32. Dockerfile build support
FieldTypeDescription

FEATURE_BUILD_SUPPORT

Boolean

Whether to support Dockerfile build.

Default: False

SUCCESSIVE_TRIGGER_FAILURE_DISABLE_THRESHOLD

Number

If not set to None, the number of successive failures that can occur before a build trigger is automatically disabled.

Default: 100

SUCCESSIVE_TRIGGER_INTERNAL_ERROR_DISABLE_THRESHOLD

Number

If not set to None, the number of successive internal errors that can occur before a build trigger is automatically disabled

Default: 5

Dockerfile build support example YAML

# ...
FEATURE_BUILD_SUPPORT: true
SUCCESSIVE_TRIGGER_FAILURE_DISABLE_THRESHOLD: 100
SUCCESSIVE_TRIGGER_INTERNAL_ERROR_DISABLE_THRESHOLD: 5
# ...
Copy to Clipboard Toggle word wrap

Expand
Table 10.33. GitHub build triggers
FieldTypeDescription

FEATURE_GITHUB_BUILD

Boolean

Whether to support GitHub build triggers.

Default: False

GITHUB_TRIGGER_CONFIG

Object

Configuration for using GitHub Enterprise for build triggers.

   .GITHUB_ENDPOINT
   (Required)

String

The endpoint for GitHub Enterprise.

Example: https://github.com/

   .API_ENDPOINT

String

The endpoint of the GitHub Enterprise API to use. Must be overridden for github.com.

Example: https://api.github.com/

   .CLIENT_ID
   (Required)

String

The registered client ID for this Red Hat Quay instance; this cannot be shared with GITHUB_LOGIN_CONFIG.

   .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
# ...
Copy to Clipboard Toggle word wrap

Expand
Table 10.34. BitBucket build triggers
FieldTypeDescription

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>
# ...
Copy to Clipboard Toggle word wrap

Expand
Table 10.35. GitLab build triggers
FieldTypeDescription

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>
# ...
Copy to Clipboard Toggle word wrap

10.9.2. Build manager configuration fields

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.

Expand
Table 10.36. Build manager configuration fields
FieldTypeDescription

ALLOWED_WORKER_COUNT

String

Defines how many Build Workers are instantiated per Red Hat Quay pod. Typically set to 1.

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 REDIS_SKIP_KEYSPACE_EVENT_SETUP to False.

EXECUTOR

String

Starts a definition of an Executor of this type. Valid values are kubernetes and ec2.

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 Quay container of the Build cluster’s CA certificate for the Quay application to trust when making API calls.

KUBERNETES_DISTRIBUTION

String

Indicates which type of Kubernetes is being used. Valid values are openshift and k8s.

CONTAINER_*

Object

Define the resource requests and limits for each build pod.

NODE_SELECTOR_*

Object

Defines the node selector label name-value pair where build Pods should be scheduled.

CONTAINER_RUNTIME

Object

Specifies whether the Builder should run docker or podman. Customers using Red Hat’s quay-builder image should set this to podman.

SERVICE_ACCOUNT_NAME/SERVICE_ACCOUNT_TOKEN

Object

Defines the Service Account name or token that will be used by build pods.

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 field. Customers should provide a Red Hat Service Account credential as defined in the section "Creating Registry Service Accounts" against registry.redhat.io in the article at https://access.redhat.com/RegistryAuthentication.

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.

BUILDER_VM_CONTAINER_IMAGE

Object

The full reference to the container image holding the internal VM needed to run each Red Hat Quay Build. (registry.redhat.io/quay/quay-builder-qemu-rhcos:3).

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 500 seconds. Builds that time out are attempted to be restarted three times. If the Build does not register itself after three attempts it is considered failed.

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 0 means there are no restrictions on how many tries the build job needs to have. This value should be kept intentionally small (three or less) to ensure failovers happen quickly during infrastructure failures. You must specify a value for this setting. For example, Kubernetes is set as the first executor and EC2 as the second executor. If you want the last attempt to run a job to always be executed on EC2 and not Kubernetes, you can set the Kubernetes executor’s MINIMUM_RETRY_THRESHOLD to 1 and EC2’s MINIMUM_RETRY_THRESHOLD to 0 (defaults to 0 if not set). In this case, the Kubernetes' MINIMUM_RETRY_THRESHOLD retries_remaining(1) would evaluate to False, therefore falling back to the second executor configured.

SSH_AUTHORIZED_KEYS

Object

List of SSH keys to bootstrap in the ignition config. This allows other keys to be used to SSH into the EC2 instance or QEMU virtual machine (VM).

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
# ...
Copy to Clipboard Toggle word wrap

10.9.3. Build logs configuration fields

This section describes the available configuration fields 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.

Expand
Table 10.37. Build logs configuration fields
FieldTypeDescription

FEATURE_READER_BUILD_LOGS

Boolean

If set to true, build logs can be read by those with read access to the repository, rather than only write access or admin access.

Default: False

LOG_ARCHIVE_LOCATION

String

The storage location, defined in DISTRIBUTED_STORAGE_CONFIG, in which to place the archived build logs.

Example: s3_us_east

LOG_ARCHIVE_PATH

String

The path under the configured storage engine in which to place the archived build logs in .JSON format.

Example: archives/buildlogs

Build logs example YAML

# ...
FEATURE_READER_BUILD_LOGS: true
LOG_ARCHIVE_LOCATION: s3_us_east
LOG_ARCHIVE_PATH: archives/buildlogs
# ...
Copy to Clipboard Toggle word wrap

10.10. Tag and image management

This section describes the configuration fields that 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.

10.10.1. Tag expiration configuration fields

The following configuration options 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.

Expand
Table 10.38. Tag expiration configuration fields
FieldTypeDescription

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:
^[0-9]+(y|w|m|d|h|s)$

DEFAULT_TAG_EXPIRATION
(Required)

String

The default, configurable tag expiration time for time machine.

Pattern:
^[0-9]+(y\w|m|d|h|s)$
Default: 2w

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 True, enables functionality related to the auto-pruning of tags.
Default: False

NOTIFICATION_TASK_RUN_MINIMUM_INTERVAL_MINUTES

Integer

The interval, in minutes, that defines the frequency to re-run notifications for expiring images.

Default: 300

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 2.

    .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 (s), days (d), months (m), weeks (w), or years (y). Must include a valid integer. For example, to keep tags for one year, specify 1y.

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 
1

AUTO_PRUNING_DEFAULT_POLICY_POLL_PERIOD: 86400
FEATURE_IMAGE_EXPIRY_TRIGGER: false
# ...
Copy to Clipboard Toggle word wrap

1
Specifies ten tags to remain.

Registry auto-prune policy by creation date example YAML

# ...
DEFAULT_NAMESPACE_AUTOPRUNE_POLICY:
  method: creation_date
  value: 1y 
1

# ...
Copy to Clipboard Toggle word wrap

1
Specifies tags to be pruned one year after their creation date.

10.10.2. Mirroring configuration fields

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.

Additional information

Expand
Table 10.39. Mirroring configuration
FieldTypeDescription

FEATURE_REPO_MIRROR

Boolean

Enable or disable repository mirroring

Default: False

REPO_MIRROR_INTERVAL

Number

The number of seconds between checking for repository mirror candidates

Default: 30

REPO_MIRROR_SERVER_HOSTNAME

String

Replaces the SERVER_HOSTNAME as the destination for mirroring.

Default: None

Example:
openshift-quay-service

REPO_MIRROR_TLS_VERIFY

Boolean

Require HTTPS and verify certificates of Quay registry during mirror.

Default: True

REPO_MIRROR_ROLLBACK

Boolean

When set to True, the repository rolls back after a failed mirror attempt.

Default: False

SKOPEO_TIMEOUT_INTERVAL

Integer

Number of seconds mirroring job will run before timing out.

Default: 300

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
SKOPEO_TIMEOUT_INTERVAL: 300
# ...
Copy to Clipboard Toggle word wrap

10.10.3. ModelCache configuration fields

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.
Expand
Table 10.40. ModelCache configuration fields
FieldTypeDescription

DATA_MODEL_CACHE_CONFIG.engine

String

The cache backend engine.
Values: memcache, redis, rediscluster
Default: memcache

.redis_config.primary.host

String

The hostname of the primary Redis instance when using the redis engine.

.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 ssl is set to True.

.redis_config.primary.ssl

Boolean

Whether to use SSL/TLS for the primary Redis connection.

.redis_config.startup_nodes

Array of Map

For rediscluster engine. The list of initial Redis cluster nodes with host and port.

redis_config.password

String

Password used for authentication with the Redis cluster. Required if ssl is True.

.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 ssl is True.

.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
# ...
Copy to Clipboard Toggle word wrap

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
# ...
Copy to Clipboard Toggle word wrap

10.11. Scanner and Metadata

This section describes configuration fields related to security scanning, metadata presentation, and artifact relationships within Red Hat Quay.

These settings enable enhanced visibility and security by allowing Red Hat Quay to:

  • Integrate with a vulnerability scanner to assess container images for known CVEs.
  • Render AI/ML model metadata through model cards stored in the registry.
  • Expose relationships between container artifacts using the Referrers API, aligning with the OCI artifact specification.

Together, these features help improve software supply chain transparency, enforce security policies, and support emerging metadata-driven workflows.

Red Hat Quay can leverage Clair security scanner to detect vulnerabilities in container images. These configuration fields control how the scanner is enabled, how frequently it indexes new content, which endpoints are used, and how notifications are handled.

Expand
Table 10.41. Security scanner configuration
FieldTypeDescription

FEATURE_SECURITY_SCANNER

Boolean

Enable or disable the security scanner

Default: False

FEATURE_SECURITY_NOTIFICATIONS

Boolean

If the security scanner is enabled, turn on or turn off security notifications

Default: False

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 last_indexed datetime in the manifestsecuritystatus table. This parameter is used to avoid trying to re-index every failed manifest on every indexing run. The default time to re-index is 300 seconds.

SECURITY_SCANNER_V4_ENDPOINT

String

The endpoint for the V4 security scanner

Pattern:
^http(s)?://(.)+$

Example:
http://192.168.99.101:6060

SECURITY_SCANNER_V4_PSK

String

The generated pre-shared key (PSK) for Clair

SECURITY_SCANNER_ENDPOINT

String

The endpoint for the V2 security scanner

Pattern:
^http(s)?://(.)+$

Example:
http://192.168.99.100:6060

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: True

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: True

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 High. Available options include Critical, High, Medium, Low, Negligible, and Unknown.

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: The manifest for this tag has layer(s) that are too large to index by the Quay Security Scanner. The default is 8G, and the maximum recommended is 10G. Accepted values are B, K, M, T, and G.
Default: 8G

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 
1

# ...
Copy to Clipboard Toggle word wrap

1
Recommended maximum is 10G.

10.11.1.1. Re-indexing with Clair v4

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.

10.11.2. Model card rendering configuration fields

Red Hat Quay supports the rendering of Model Cards—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.

Expand
Table 10.42. Model card rendering configuration fields
FieldTypeDescription

FEATURE_UI_MODELCARD

Boolean

Enables Model Card image tab in UI. Defaults to True.

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 
1

UI_MODELCARD_ARTIFACT_TYPE: application/x-mlmodel 
2

UI_MODELCARD_ANNOTATION: 
3

  org.opencontainers.image.description: "Model card metadata"
UI_MODELCARD_LAYER_ANNOTATION: 
4

  org.opencontainers.image.title: README.md
Copy to Clipboard Toggle word wrap

1
Enables the Model Card image tab in the UI.
2
Defines the model card artifact type. In this example, the artifact type is application/x-mlmodel.
3
Optional. If an image does not have an artifactType defined, this field is checked at the manifest level. If a matching annotation is found, the system then searches for a layer with an annotation matching UI_MODELCARD_LAYER_ANNOTATION.
4
Optional. If an image has an artifactType defined and multiple layers, this field is used to locate the specific layer containing the model card.

The Open Container Initiative (OCI) referrers API aids in the retrieval and management of referrers helps improve container image management.

Additional information

Expand
Table 10.43. Referrers API configuration field
FieldTypeDescription

FEATURE_REFERRERS_API

Boolean

Enables OCI 1.1’s referrers API.

OCI referrers enablement example YAML

# ...
FEATURE_REFERRERS_API: True
# ...
Copy to Clipboard Toggle word wrap

10.12. Quota management and proxy cache features

This section outlines configuration fields related to enforcing storage limits and improving image availability through proxy caching.

These features help registry administrators:

  • Control how much storage organizations and users consume with configurable quotas.
  • Improve access to upstream images by caching remote content locally via proxy cache.
  • Monitor and manage resource consumption and availability across distributed environments.

Collectively, these capabilities ensure better performance, governance, and resiliency in managing container image workflows.

10.12.1. Quota management configuration fields

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.

Expand
Table 10.44. Quota management configuration
FieldTypeDescription

FEATURE_QUOTA_MANAGEMENT

Boolean

Enables configuration, caching, and validation for quota management feature.

Default: False

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: True

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: 1800

PERMANENTLY_DELETE_TAGS

Boolean

Enables functionality related to the removal of tags from the time machine window.

Default: False

RESET_CHILD_MANIFEST_EXPIRATION

Boolean

Resets the expirations of temporary tags targeting the child manifests. With this feature set to True, child manifests are immediately garbage collected.

Default: False

Quota management example YAML

# ...
FEATURE_QUOTA_MANAGEMENT: true
DEFAULT_SYSTEM_REJECT_QUOTA_BYTES: "100gb"
QUOTA_BACKFILL: true
QUOTA_TOTAL_DELAY_SECONDS: "3600"
PERMANENTLY_DELETE_TAGS: true
RESET_CHILD_MANIFEST_EXPIRATION: true
# ...
Copy to Clipboard Toggle word wrap

10.12.2. Proxy cache configuration fields

The proxy cache configuration in Red Hat Quay 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.

Expand
Table 10.45. Proxy cache configuration fields
FieldTypeDescription

FEATURE_PROXY_CACHE

Boolean

Enables Red Hat Quay to act as a pull through cache for upstream registries.

Default: False

Proxy cache example YAML

# ...
FEATURE_PROXY_CACHE: true
# ...
Copy to Clipboard Toggle word wrap

10.13. QuayIntegration configuration fields

The QuayIntegration custom resource enables integration between your OpenShift Container Platform cluster and a Red Hat Quay registry instance.

Expand
Table 10.46. QuayIntegration configuration fields
NameDescriptionSchema

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
Copy to Clipboard Toggle word wrap

10.14. Mail configuration fields

To enable email notifications from your Red Hat Quay instance, such as account confirmation, password reset, and security alerts. These settings allow Red Hat Quay to connect to your SMTP server and send outbound messages on behalf of your registry.

Expand
Table 10.47. Mail configuration fields
FieldTypeDescription

FEATURE_MAILING

Boolean

Whether emails are enabled

Default: False

MAIL_DEFAULT_SENDER

String

If specified, the e-mail address used as the from when Red Hat Quay sends e-mails. If none, defaults to support@quay.io

Example: support@example.com

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: smtp.example.com

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: True

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
# ...
Copy to Clipboard Toggle word wrap

Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat