Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 2. Red Hat Quay configuration disclaimer

With Red Hat Quay enterprise, certain features and configuration parameters are not actively used or implemented. As a result, feature flags, such as those that enable or disable certain features, and configuration parameters that are not explicitly documented or requested for documentation by Red Hat Support should only be modified with caution. Unused features or parameters might not be fully tested, supported, or compatible with Red Hat Quay, and modifying them could lead to unexpected issues or disruptions with your deployment.

2.1. Configuration updates for Red Hat Quay 3.9
Copy link

The following sections detail new configuration fields added in Red Hat Quay 3.9.

2.1.1. Action log audit configuration
Copy link

With Red Hat Quay 3.9, audit logins are tracked by default.

Expand
Table 2.1. 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

2.1.2. Addition of Splunk action logs
Copy link

With Red Hat Quay 3.9, Splunk can be configured under the LOGS_MODEL parameter.

Expand
Table 2.2. Splunk configuration fields
FieldTypeDescription

LOGS_MODEL

String

Specifies the preferred method for handling log data.

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

2.1.2.1. LOGS_MODEL_CONFIG additions
Copy link

The following LOGS_MODEL_CONFIG options are available when configuring Splunk.

  • LOGS_MODEL_CONFIG [object]: Logs model config for action logs

    • producer [string]: splunk

    • splunk_config [object]: Logs model configuration for Splunk action logs or the Splunk cluster configuration

      • host [string]: Splunk cluster endpoint.
      • port [integer]: Splunk management cluster endpoint port.
      • bearer_token [string]: The bearer token for Splunk.
      • verify_ssl [boolean]: Enable (True) or disable (False) TLS/SSL verification for HTTPS connections.
      • index_prefix [string]: Splunk’s index prefix.
      • ssl_ca_path [string]: The relative container path to a single .pem file containing a certificate authority (CA) for SSL validation.

2.1.2.2. Example configuration for Splunk
Copy link

The following YAML entry provides an example configuration for Splunk.

Splunk config.yaml example

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

2.1.3. Quota management configuration fields
Copy link

The following configuration fields have been added to enhance the Red Hat Quay quota management feature.

Expand
Table 2.3. Red Hat Quay 3.9 quota management configuration fields
FieldTypeDescription

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

The following table explains possible quota management configuration settings in Red Hat Quay 3.9.

Expand
Table 2.4. Quota management configuration options
FEATURE_QUOTA_MANAGEMENTQUOTA_BACKFILLOUTCOME

true

true

With these features configured as true, quota management is enabled and working for Red Hat Quay 3.9. For more information about configuring quota management for Red Hat Quay 3.9, see "Quota management for Red Hat Quay 3.9".

true

false

With FEATURE_QUOTA_MANAGEMENT set to true, and QUOTA_BACKFILL set to false, the quota management feature has been enabled. However, pre-existing images from a prior (N-1) y-stream version of Red Hat Quay (for example, 3.8), must be backfilled before quota calculation can continue. To backfill image sizes, set QUOTA_BACKFILL to true.

false

false

With these features configured as false, the quota management feature is disabled.

false

true

With FEATURE_QUOTA_MANAGEMENT set to false, and QUOTA_BACKFILL set to true, the quota management feature is disabled.

The following YAML is the suggested configuration when enabling quota management.

Suggested quota management configuration

FEATURE_QUOTA_MANAGEMENT: true
FEATURE_GARBAGE_COLLECTION: true
PERMANENTLY_DELETE_TAGS: true
QUOTA_TOTAL_DELAY_SECONDS: 1800
RESET_CHILD_MANIFEST_EXPIRATION: true
Copy to Clipboard Toggle word wrap

2.1.4. PostgreSQL PVC backup environment variable
Copy link

The following environment variable has been added to configure whether Red Hat Quay automatically removes old persistent volume claims (PVCs) when upgrading from version 3.8 3.9:

Expand
Table 2.5. Red Hat Quay 3.9 PostgreSQL backup environment variable
FieldTypeDescription

POSTGRES_UPGRADE_RETAIN_BACKUP

Boolean

When set to True, persistent volume claims from PostgreSQL 10 are backed up.

+ Default: False

The following Subscription object provides an example configuration for backing up PostgreSQL 10 PVCs.

Subscription object for PostgreSQL 10 PVCs

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: quay-operator
  namespace: quay-enterprise
spec:
  channel: stable-3.8
  name: quay-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  config:
    env:
    - name: POSTGRES_UPGRADE_RETAIN_BACKUP
      value: "true"
Copy to Clipboard Toggle word wrap

2.2. Editing the configuration file
Copy link

To deploy a standalone instance of Red Hat Quay, you must provide the minimal configuration information. The requirements for a minimal configuration can be found in "Red Hat Quay minimal configuration."

After supplying the required fields, you can validate your configuration. If there are any issues, they will be highlighted.

Note

It is possible to use the configuration API to validate the configuration, but this requires starting the Quay container in configuration mode. For more information, see "Using the configuration tool."

For changes to take effect, the registry must be restarted.

For standalone deployments of Red Hat Quay, the config.yaml file must be specified when starting the Red Hat Quay registry. This file is located in the configuration volume. For example, the configuration file is located at $QUAY/config/config.yaml when deploying Red Hat Quay by the following command: 

$ sudo podman run -d --rm -p 80:8080 -p 443:8443 \
   --name=quay \
   -v $QUAY/config:/conf/stack:Z \
   -v $QUAY/storage:/datastorage:Z \
   registry.redhat.io/quay/quay-rhel8:v3.9.10
Copy to Clipboard Toggle word wrap

2.4. Minimal configuration
Copy link

The following configuration options are required for a standalone deployment of Red Hat Quay:

  • Server hostname
  • HTTP or HTTPS
  • Authentication type, for example, Database or Lightweight Directory Access Protocol (LDAP)
  • Secret keys for encrypting data
  • Storage for images
  • Database for metadata
  • Redis for build logs and user events
  • Tag expiration options

2.4.1. Sample minimal configuration file
Copy link

The following example shows a sample minimal configuration file that uses local storage for images: 

AUTHENTICATION_TYPE: Database
BUILDLOGS_REDIS:
    host: quay-server.example.com
    password: strongpassword
    port: 6379
    ssl: false
DATABASE_SECRET_KEY: 0ce4f796-c295-415b-bf9d-b315114704b8
DB_URI: postgresql://quayuser:quaypass@quay-server.example.com:5432/quay
DEFAULT_TAG_EXPIRATION: 2w
DISTRIBUTED_STORAGE_CONFIG:
    default:
        - LocalStorage
        - storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - default
PREFERRED_URL_SCHEME: http
SECRET_KEY: e8f9fe68-1f84-48a8-a05f-02d72e6eccba
SERVER_HOSTNAME: quay-server.example.com
SETUP_COMPLETE: true
TAG_EXPIRATION_OPTIONS:
    - 0s
    - 1d
    - 1w
    - 2w
    - 4w
USER_EVENTS_REDIS:
    host: quay-server.example.com
    port: 6379
    ssl: false
Copy to Clipboard Toggle word wrap
Note

The SETUP_COMPLETE field indicates that the configuration has been validated. You should use the configuration editor tool to validate your configuration before starting the registry.

2.4.2. Local storage
Copy link

Using local storage for images is only recommended when deploying a registry for proof of concept purposes.

When configuring local storage, storage is specified on the command line when starting the registry. The following command maps a local directory, $QUAY/storage to the datastorage path in the container: 

$ sudo podman run -d --rm -p 80:8080 -p 443:8443 \
   --name=quay \
   -v $QUAY/config:/conf/stack:Z \
   -v $QUAY/storage:/datastorage:Z \
   registry.redhat.io/quay/quay-rhel8:v3.9.10
Copy to Clipboard Toggle word wrap

2.4.3. Cloud storage
Copy link

Storage configuration is detailed in the Image storage section. For some users, it might be useful to compare the difference between Google Cloud Platform and local storage configurations. For example, the following YAML presents a Google Cloud Platform storage configuration:

$QUAY/config/config.yaml

DISTRIBUTED_STORAGE_CONFIG:
    default:
        - GoogleCloudStorage
        - access_key: GOOGQIMFB3ABCDEFGHIJKLMN
          bucket_name: quay_bucket
          secret_key: FhDAYe2HeuAKfvZCAGyOioNaaRABCDEFGHIJKLMN
          storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - default
Copy to Clipboard Toggle word wrap

When starting the registry using cloud storage, no configuration is required on the command line. For example: 

$ sudo podman run -d --rm -p 80:8080 -p 443:8443 \
   --name=quay \
   -v $QUAY/config:/conf/stack:Z \
   registry.redhat.io/quay/quay-rhel8:v3.9.10
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