Home
Products
Red Hat Quay
3.18
Configure Red Hat Quay
Chapter 7. Required configuration fields

Chapter 7. Required configuration fields

Red Hat Quay requires a minimal set of configuration fields to operate correctly. These fields define essential aspects of your deployment, such as how the registry is accessed, where image content is stored, how metadata is persisted, and how background services such as logs are managed.

The required configuration fields fall into five main categories:

General required configuration fields. Core fields such as the authentication type, URL scheme, server hostname, database secret key, and secret key are covered in this section.
Database configuration fields. Red Hat Quay requires a PostgreSQL relational database to store metadata about repositories, users, teams, and tags.
Object storage configuration fields. Object storage defines the backend where container image blobs and manifests are stored. Your storage backend must be supported by Red Hat Quay, such as Ceph/RadosGW, AWS S3 storage, Google Cloud Storage, and Nutanix.
Redis configuration fields. Redis is used as a backend for data such as push logs, user notifications, and other operations.

7.1. General required configuration fields
Copy link

General required fields must be present in every Red Hat Quay configuration to start the registry. Use this reference to confirm values for authentication, URL settings, and secret keys.

Table 7.1. General required fields
Field	Type	Description
AUTHENTICATION_TYPE (Required)	String	The authentication engine to use for credential authentication. Values: One of `Database`, `LDAP`, `JWT`, `Keystone`, `OIDC`. Default: `Database`.
PREFERRED_URL_SCHEME (Required)	String	The URL scheme to use when accessing Red Hat Quay. Values: One of `http`, `https`. Default: `http`.
SERVER_HOSTNAME (Required)	String	The URL at which Red Hat Quay is accessible, without the scheme. Example: `quay-server.example.com`.
DATABASE_SECRET_KEY (Required)	String	Key used to encrypt sensitive fields within the database. This value should never be changed once set, otherwise all reliant fields, for example, repository mirror username and password configurations, are invalidated. This value is set automatically by the Red Hat Quay Operator for Operator-based deployments. For standalone deployments, administrators can provide their own key using Open SSL or a similar tool. Key length should not exceed 63 characters.
SECRET_KEY (Required)	String	Key used to encrypt the session cookie and the CSRF token needed for correct interpretation of the user session. The value should not be changed when set. The value should be persistent across all Red Hat Quay instances. If the value is not persistent across all instances, login failures and other errors related to session persistence might occur.
SETUP_COMPLETE (Required)	Boolean	This is an artifact left over from earlier versions of the software and currently it must be specified with a value of `True`.

General required fields example

AUTHENTICATION_TYPE: Database
PREFERRED_URL_SCHEME: https
SERVER_HOSTNAME: <quay-server.example.com>
SECRET_KEY: <secret_key_value>
DATABASE_SECRET_KEY: <database_secret_key_value>
SETUP_COMPLETE: true
# ...

7.2. Database configuration fields
Copy link

You must configure database connectivity for Red Hat Quay by setting the DB_URI field. You can optionally define connection settings such as SSL/TLS behavior by using DB_CONNECTION_ARGS.

7.2.1. Database URI
Copy link

You configure the database connection for Red Hat Quay by setting the required DB_URI field.

The following table describes the DB_URI configuration field:

Table 7.2. Database URI
Field	Type	Description
DB_URI (Required)	String	The URI for accessing the database, including any credentials.

Example DB_URI field: postgresql://quayuser:quaypass@quay-server.example.com:5432/quay

Database URI example

# ...
DB_URI: postgresql://quayuser:quaypass@quay-server.example.com:5432/quay
# ...

7.2.2. Database connection arguments
Copy link

You can define optional connection arguments by using the DB_CONNECTION_ARGS parameter. Some of the key-value pairs under DB_CONNECTION_ARGS are generic, while others are database specific.

Table 7.3. Database connection arguments
Field	Type	Description
DB_CONNECTION_ARGS	Object	Optional connection arguments for the database, such as timeouts and SSL/TLS.
.autorollback	Boolean	Whether to use thread-local connections. Should always be `True`.
.threadlocals	Boolean	Whether to use auto-rollback connections. Should always be `True`.

Database connection arguments example

# ...
DB_URI: postgresql://quayuser:quaypass@quay-server.example.com:5432/quay
DB_CONNECTION_ARGS:
  autorollback: true
  threadlocals: true
# ...

7.2.3. SSL/TLS connection arguments
Copy link

With SSL/TLS, configuration depends on the database you are deploying.

The sslmode option determines whether Red Hat Quay negotiates a secure SSL/TLS TCP/IP connection with the server, and with what priority. The following modes are available:

Table 7.4. sslmode options
Mode	Description
sslmode	Determines whether, or with, what priority a secure SSL/TLS or TCP/IP connection is negotiated with the server.
*: disable	Your configuration only tries non-SSL/TLS connections.
*: allow	Your configuration first tries a non-SSL/TLS connection. Upon failure, tries an SSL/TLS connection.
*: prefer (Default)	Your configuration first tries an SSL/TLS connection. Upon failure, tries a non-SSL/TLS connection.
*: require	Your configuration only tries an SSL/TLS connection. If a root CA file is present, it verifies the certificate in the same way as if verify-ca was specified.
*: verify-ca	Your configuration only tries an SSL/TLS connection, and verifies that the server certificate is issued by a trusted certificate authority (CA).
*: verify-full	Only tries an SSL/TLS connection, and verifies that the server certificate is issued by a trusted CA and that the requested server hostname matches that in the certificate.

For more information on the valid arguments for PostgreSQL, see Database Connection Control Functions in Additional resources.

PostgreSQL SSL/TLS configuration

# ...
DB_CONNECTION_ARGS:
  sslmode: <value>
  sslrootcert: path/to/.postgresql/root.crt
# ...

7.3. Storage object configuration fields
Copy link

Storage fields define the backend where container image blobs and manifests are stored.

The following storage providers are supported by Red Hat Quay:

Amazon Web Services (AWS) S3
AWS STS S3 (Security Token Service)
AWS CloudFront (CloudFront S3Storage)
Google Cloud Storage
Microsoft Azure Blob Storage
Swift Storage
Nutanix Object Storage
IBM Cloud Object Storage
NetApp ONTAP S3 Object Storage
Hitachi Content Platform (HCP) Object Storage

Note

Many of the supported storage providers use the RadosGWStorage driver due to their S3-compatible APIs.

7.3.1. Storage configuration fields
Copy link

You configure backend storage for Red Hat Quay by setting distributed storage fields such as engine configuration, default locations, and preferences. Use this reference to review field types, defaults, and an example configuration.

Table 7.5. Storage configuration fields
Field	Type	Description
DISTRIBUTED_STORAGE_CONFIG (Required)	Object	Configuration for storage engine(s) to use in Red Hat Quay. Each key represents an unique identifier for a storage engine. The value consists of a tuple of (key, value) forming an object describing the storage engine parameters. Default: `[]`
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS (Required)	Array of string	The list of storage engine(s) (by ID in `DISTRIBUTED_STORAGE_CONFIG`) whose images should be fully replicated, by default, to all other storage engines.
DISTRIBUTED_STORAGE_PREFERENCE (Required)	Array of string	The preferred storage engine(s) (by ID in `DISTRIBUTED_STORAGE_CONFIG`) to use. A preferred engine means it is first checked for pulling and images are pushed to it. Default: `False`
MAXIMUM_LAYER_SIZE (Optional)	String	Maximum allowed size of an image layer. Pattern: `^[0-9]+(G\|M)$` Example: `100G` Default: `20G`

Storage configuration example

DISTRIBUTED_STORAGE_CONFIG:
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - default
MAXIMUM_LAYER_SIZE: 100G

7.3.2. Local storage
Copy link

You can configure Red Hat Quay to use local filesystem storage for proof-of-concept deployments. Use this example to map registry data to the datastorage path in the container.

Important

Only use local storage when deploying a registry for proof of concept purposes. It is not intended for production purposes. When using local storage, you must map the registry to a local directory to the datastorage path in the container when starting the registry. For more information, see Proof of Concept - Deploying Red Hat Quay in Additional resources.

Local storage example

DISTRIBUTED_STORAGE_CONFIG:
  default:
    - LocalStorage
    - storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - default

7.3.3. Red Hat OpenShift Data Foundation
Copy link

You can configure Red Hat Quay to use Red Hat OpenShift Data Foundation object storage by defining a DISTRIBUTED_STORAGE_CONFIG entry for the storage backend. Use this example as a starting point for required fields and optional tuning parameters.

The following YAML shows a sample configuration using an Red Hat OpenShift Data Foundation:

DISTRIBUTED_STORAGE_CONFIG:
  rhocsStorage:
    - RHOCSStorage
    - access_key: <access_key_here>
      secret_key: <secret_key_here>
      bucket_name: <bucket_name>
      hostname: <hostname>
      is_secure: 'true'
      port: '443'
      storage_path: /datastorage/registry
      maximum_chunk_size_mb: 100
      server_side_assembly: true

where:

DISTRIBUTED_STORAGE_CONFIG.rhocsStorage.maximum_chunk_size_mb: Specifies the maximum chunk size, in MB, for the final copy. Has no effect if server_side_assembly is set to False.
DISTRIBUTED_STORAGE_CONFIG.rhocsStorage.server_side_assembly: Specifies whether Red Hat Quay tries to use server-side assembly and the final chunked copy instead of client assembly. Defaults to True. This field is optional.

7.3.4. Ceph Object Gateway (RadosGW) storage example
Copy link

You can configure Red Hat Quay to use Ceph Object Gateway (RadosGW) as an S3-compatible storage backend. Use this example to set required authentication fields and optional assembly settings.

Note

RadosGW is an on-premises S3-compatible storage solution. It implements the S3 API and requires the same authentication fields, such as access_key, secret_key, and bucket_name.

The following YAML shows an example configuration using RadosGW.

RadosGW with general s3 access example

DISTRIBUTED_STORAGE_CONFIG:
  radosGWStorage:
    - RadosGWStorage
    - access_key: <access_key_here>
      bucket_name: <bucket_name_here>
      hostname: <hostname_here>
      is_secure: true
      port: '443'
      secret_key: <secret_key_here>
      storage_path: /datastorage/registry
      maximum_chunk_size_mb: 100
      server_side_assembly: true

where:

DISTRIBUTED_STORAGE_CONFIG.radosGWStorage: Specifies general S3 access. Note that general S3 access is not strictly limited to Amazon Web Services (AWS) S3, and can be used with RadosGW or other storage services. For an example of general S3 access using the AWS S3 driver, see "AWS S3 storage".
DISTRIBUTED_STORAGE_CONFIG.radosGWStorage.maximum_chunk_size_mb: Specifies the maximum chunk size in MB for the final copy. Has no effect if server_side_assembly is set to False. This field is optional.
DISTRIBUTED_STORAGE_CONFIG.radosGWStorage.server_side_assembly: Specifies whether Red Hat Quay tries to use server-side assembly and the final chunked copy instead of client assembly. Defaults to True. This field is optional.

7.3.5. Supported AWS storage backends
Copy link

You can configure Red Hat Quay to use AWS S3, STS, or CloudFront storage backends in DISTRIBUTED_STORAGE_CONFIG. Use these examples to set credentials, regions, and distribution settings for each backend.

Red Hat Quay supports multiple Amazon Web Services (AWS) storage backends:

S3 storage: Standard support for AWS S3 buckets that uses AWS’s native object storage service.
STS S3 storage: Support for AWS Security Token Service (STS) to assume IAM roles, allowing for more secure S3 operations.
CloudFront S3 storage: Integrates with AWS CloudFront to enable high-availability distribution of content while still using AWS S3 as the origin.

The following sections provide example YAML configurations and additional information about each AWS storage backend.

7.3.5.1. Amazon Web Services S3 storage
Copy link

Red Hat Quay supports using AWS S3 as an object storage backend. AWS S3 is an object storage service designed for data availability, scalability, security, and performance. The following YAML shows an example configuration using AWS S3.

AWS S3 example

# ...
DISTRIBUTED_STORAGE_CONFIG:
  default:
    - S3Storage
    - host: s3.us-east-2.amazonaws.com
      s3_access_key: ABCDEFGHIJKLMN
      s3_secret_key: OL3ABCDEFGHIJKLMN
      s3_bucket: quay_bucket
      s3_region: <region>
      storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - default
# ...

where:

DISTRIBUTED_STORAGE_CONFIG.default: Specifies the S3Storage storage driver for AWS S3 buckets. Note that this differs from general S3 access, where the RadosGW driver or other storage services can be used. For an example, see "Example B: Using RadosGW with general S3 access".
DISTRIBUTED_STORAGE_CONFIG.default.s3_region: Specifies the Amazon Web Services region. Defaults to us-east-1.

7.3.5.2. Amazon Web Services STS S3 storage
Copy link

AWS Security Token Service (STS) provides temporary, limited-privilege credentials for accessing AWS resources, improving security by avoiding the need to store long-term access keys. This is useful in environments such as OpenShift Container Platform where credentials can be rotated or managed through IAM roles.

The following YAML shows an example configuration for using AWS STS with Red Hat Quay on OpenShift Container Platform configurations.

AWS STS S3 storage example

# ...
DISTRIBUTED_STORAGE_CONFIG:
   default:
    - STSS3Storage
    - sts_role_arn: <role_arn>
      s3_bucket: <s3_bucket_name>
      storage_path: <storage_path>
      sts_user_access_key: <s3_user_access_key>
      sts_user_secret_key: <s3_user_secret_key>
      s3_region: <region>
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - default
# ...

where:

DISTRIBUTED_STORAGE_CONFIG.default.sts_role_arn: Specifies the unique Amazon Resource Name (ARN).
DISTRIBUTED_STORAGE_CONFIG.default.sts_user_access_key: Specifies the generated AWS S3 user access key.
DISTRIBUTED_STORAGE_CONFIG.default.sts_user_secret_key: Specifies the generated AWS S3 user secret key.
DISTRIBUTED_STORAGE_CONFIG.default.s3_region: Specifies the Amazon Web Services region. Defaults to us-east-1.

7.3.5.3. AWS CloudFront storage
Copy link

AWS CloudFront is a content delivery network (CDN) service that caches and distributes content closer to users for improved performance and lower latency. Red Hat Quay supports CloudFront through the CloudFrontedS3Storage driver, which enables secure, signed access to S3 buckets via CloudFront distributions.

Use the following example when configuring AWS CloudFront for your Red Hat Quay deployment.

Note

When configuring AWS CloudFront storage, the following conditions must be met for proper use with Red Hat Quay:
- You must set an Origin path that is consistent with Red Hat Quay’s storage path as defined in your config.yaml file. Failure to meet this requirement results in a 403 error when pulling an image.
- You must configure a Bucket policy and a Cross-origin resource sharing (CORS) policy.

Cloudfront S3 example YAML

DISTRIBUTED_STORAGE_CONFIG:
    default:
      - CloudFrontedS3Storage
      - cloudfront_distribution_domain: <CLOUDFRONT_DISTRIBUTION_DOMAIN>
        cloudfront_key_id: <CLOUDFRONT_KEY_ID>
        cloudfront_privatekey_filename: <CLOUDFRONT_PRIVATE_KEY_FILENAME>
        host: <S3_HOST>
        s3_access_key: <S3_ACCESS_KEY>
        s3_bucket: <S3_BUCKET_NAME>
        s3_secret_key: <S3_SECRET_KEY>
        storage_path: <STORAGE_PATH>
        s3_region: <S3_REGION>
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS:
  - default
DISTRIBUTED_STORAGE_PREFERENCE:
  - default

Bucket policy example

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<AWS_ACCOUNT_ID>:user/CloudFront Origin Access Identity <CLOUDFRONT_OAI_ID>"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<S3_BUCKET_NAME>/*"
        },
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<AWS_ACCOUNT_ID>:user/CloudFront Origin Access Identity <CLOUDFRONT_OAI_ID>"
            },
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::<S3_BUCKET_NAME>"
        }
    ]
}

<AWS_ACCOUNT_ID> is the identifier, or account ID, of the AWS account that owns the CloudFront OAI and S3 bucket.
<CLOUDFRONT_OAI_ID> is the CloudFront Origin Access Identity (OAI) that accesses the S3 bucket.
arn:aws:s3:::<S3_BUCKET_NAME> specifies that CloudFront can access the specified bucket in the S3 bucket.

7.3.6. Google Cloud Storage
Copy link

You can configure Red Hat Quay to use Google Cloud Storage (GCS) as an object storage backend. Use this example to set bucket credentials and optional connection timeout settings.

Google Cloud Storage example

DISTRIBUTED_STORAGE_CONFIG:
    googleCloudStorage:
        - GoogleCloudStorage
        - access_key: <access_key>
          bucket_name: <bucket_name>
          secret_key: <secret_key>
          storage_path: /datastorage/registry
          boto_timeout: 120
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - googleCloudStorage

DISTRIBUTED_STORAGE_CONFIG.googleCloudStorage.boto_timeout: Specifies the time, in seconds, until a timeout exception is thrown when attempting to read from a connection. The default is 60 seconds. Also encompasses the time, in seconds, until a timeout exception is thrown when attempting to make a connection. The default is 60 seconds. This field is optional.

7.3.7. Microsoft Azure Blob Storage
Copy link

You can configure Red Hat Quay to use Microsoft Azure Blob Storage as an object storage backend. Use this example to set account credentials, container details, and optional government cloud endpoints.

Microsoft Azure Blob Storage example

DISTRIBUTED_STORAGE_CONFIG:
  azureStorage:
    - AzureStorage
    - azure_account_name: <azure_account_name>
      azure_container: <azure_container_name>
      storage_path: /datastorage/registry
      azure_account_key: <azure_account_key>
      sas_token: some/path/
      endpoint_url: https://[account-name].blob.core.usgovcloudapi.net
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - azureStorage

DISTRIBUTED_STORAGE_CONFIG.azureStorage.endpoint_url: Specifies the endpoint URL for Azure storage. This parameter is optional and can be used with Microsoft Azure Government (MAG) endpoints. If left blank, the endpoint_url connects to the normal Azure region.

You must use the Primary endpoint of your MAG Blob service. Using the Secondary endpoint of your MAG Blob service results in the following error: AuthenticationErrorDetail:Cannot find the claimed account when trying to GetProperties for the account whusc8-secondary.

7.3.8. Swift object storage
Copy link

You can configure Red Hat Quay to use Red Hat OpenStack Platform (RHOSP) Swift object storage as a backend. Use this example to set authentication credentials, container details, and tenant options.

Swift object storage example

DISTRIBUTED_STORAGE_CONFIG:
  swiftStorage:
    - SwiftStorage
    - swift_user: <swift_username>
      swift_password: <swift_password>
      swift_container: <swift_container>
      auth_url: https://example.org/swift/v1/quay
      auth_version: 3
      os_options:
        tenant_id: <osp_tenant_id>
        user_domain_name: <osp_domain_name>
      ca_cert_path: /conf/stack/swift.cert
      storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - swiftStorage

7.3.9. Nutanix Objects Storage
Copy link

You can configure Red Hat Quay to use Nutanix Objects Storage as an object storage backend. Use this example to set credentials, bucket details, and connection options for private cloud infrastructure.

Nutanix Objects Storage example

DISTRIBUTED_STORAGE_CONFIG:
  nutanixStorage: # storage config name
    - RadosGWStorage # actual driver
    - access_key: <access_key>
      secret_key: <secret_key>
      bucket_name: <bucket_name>
      hostname: <hostname>
      is_secure: 'true'
      port: '443'
      storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE: # must contain name of the storage config
    - nutanixStorage

7.3.10. IBM Cloud Object Storage
Copy link

You can configure Red Hat Quay to use IBM Cloud Object Storage as an object storage backend. Use this example to set credentials, bucket details, and optional chunk size parameters.

IBM Cloud Object Storage

DISTRIBUTED_STORAGE_CONFIG:
  default:
  - IBMCloudStorage # actual driver
  - access_key: <access_key> # parameters
    secret_key: <secret_key>
    bucket_name: <bucket_name>
    hostname: <hostname>
    is_secure: 'true'
    port: '443'
    storage_path: /datastorage/registry
    maximum_chunk_size_mb: 100mb
    minimum_chunk_size_mb: 5mb
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS:
- default
DISTRIBUTED_STORAGE_PREFERENCE:
- default

where:

DISTRIBUTED_STORAGE_CONFIG.default.maximum_chunk_size_mb: Specifies the maximum chunk size. Recommended to be set to 100mb. This field is optional.
DISTRIBUTED_STORAGE_CONFIG.default.minimum_chunk_size_mb: Specifies defaults to 5mb. Do not adjust this field without consulting Red Hat Support in Additional resources, because it can have unintended consequences. This field is optional.

7.3.11. NetApp ONTAP S3 object storage
Copy link

You can configure Red Hat Quay to use NetApp ONTAP S3 as an object storage backend. Use this example to set credentials, bucket details, and connection options.

Netapp ONTAP S3 example

DISTRIBUTED_STORAGE_CONFIG:
  local_us:
  - RadosGWStorage
  - access_key: <access_key>
    bucket_name: <bucket_name>
    hostname: <host_url_address>
    is_secure: true
    port: <port>
    secret_key: <secret_key>
    storage_path: /datastorage/registry
    signature_version: v4
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS:
- local_us
DISTRIBUTED_STORAGE_PREFERENCE:
- local_us

7.3.12. Hitachi Content Platform object storage
Copy link

You can configure Red Hat Quay to use Hitachi Content Platform (HCP) as an object storage backend. Use this example to set credentials, bucket details, and connection options.

HCP storage configuration example

DISTRIBUTED_STORAGE_CONFIG:
  hcp_us:
  - RadosGWStorage
  - access_key: <access_key>
    bucket_name: <bucket_name>
    hostname: <hitachi_hostname_example>
    is_secure: true
    secret_key: <secret_key>
    storage_path: /datastorage/registry
    signature_version: v4
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS:
- hcp_us
DISTRIBUTED_STORAGE_PREFERENCE:
- hcp_us

7.4. Redis configuration fields
Copy link

Redis is used by Red Hat Quay to support backend tasks and services, such as build triggers and notifications. There are configuration types related to Redis: build logs and user events. The following sections detail the configuration fields available for each type.

7.4.1. Build logs
Copy link

Red Hat Quay uses Redis to temporarily store build logs before they are accessed through the user interface or API. Use this reference to configure Redis connection settings for build log caching.

Table 7.6. Build logs configuration fields
Field	Type	Description
BUILDLOGS_REDIS (Required)	Object	Redis connection details for build logs caching.
.host (Required)	String	The hostname at which Redis is accessible. Example: `quay-server.example.com`
.port (Required)	Number	The port at which Redis is accessible. Example: `6379`
.password	String	The password to connect to the Redis instance. Example: `strongpassword`
.ssl (Optional)	Boolean	Whether to enable TLS communication between Redis and Quay. Defaults to false.

Build logs configuration example

# ...
BUILDLOGS_REDIS:
  host: <quay-server.example.com>
  password: <example_password>
  port: 6379
  ssl: true
# ...

If your deployment uses Azure Cache for Redis and ssl is set to True, the port defaults to 6380.

7.4.2. User events
Copy link

User events record activity in Red Hat Quay and store it in Redis for access through the API or web interface. Use these fields to configure the Redis connection for user event handling.

Table 7.7. User events config
Field	Type	Description
USER_EVENTS_REDIS (Required)	Object	Redis connection details for user event handling.
.host (Required)	String	The hostname at which Redis is accessible. Example: `quay-server.example.com`.
.port (Required)	Number	The port at which Redis is accessible. Example: `6379`.
.password	String	The password to connect to the Redis instance. Example: `strongpassword`.
.ssl	Boolean	Whether to enable TLS communication between Redis and Quay. Defaults to false.
.ssl_keyfile (Optional)	String	The key database file that contains the client certificate key. Example: `ssl_keyfile: /path/to/server/privatekey.pem`.
.ssl_certfile (Optional)	String	The file path of the SSL certificate. Example: `ssl_certfile: /path/to/server/certificate.pem`.
.ssl_cert_reqs (Optional)	String	The certificate validation level to use during the SSL/TLS handshake. Example: `ssl_cert_reqs: CERT_REQUIRED`.
.ssl_ca_certs (Optional)	String	The path to a file containing trusted CA certificates. Example: `ssl_ca_certs: /path/to/ca_certs.pem`.
.ssl_ca_data (Optional)	String	A string that contains trusted CA certificates in PEM format. Example: `ssl_ca_data: <certificate>`.
.ssl_check_hostname (Optional)	Boolean	Whether the client checks that the hostname in the server SSL/TLS certificate matches the hostname of the server it connects to. Example: `ssl_check_hostname: true`.

Redis user events example

# ...
USER_EVENTS_REDIS:
  host: <quay-redis.example.com>
  port: 6379
  password: <example_password>
  ssl: true
  ssl_keyfile: /etc/ssl/private/redis-client.key
  ssl_certfile: /etc/ssl/certs/redis-client.crt
  ssl_cert_reqs: <required_certificate>
  ssl_ca_certs: /etc/ssl/certs/ca-bundle.crt
  ssl_check_hostname: true
# ...

Chapter 7. Required configuration fields

7.1. General required configuration fields
Copy link

7.2. Database configuration fields
Copy link

7.2.1. Database URI
Copy link

7.2.2. Database connection arguments
Copy link

7.2.3. SSL/TLS connection arguments
Copy link

7.3. Storage object configuration fields
Copy link

7.3.1. Storage configuration fields
Copy link

7.3.2. Local storage
Copy link

7.3.3. Red Hat OpenShift Data Foundation
Copy link

7.3.4. Ceph Object Gateway (RadosGW) storage example
Copy link

7.3.5. Supported AWS storage backends
Copy link

7.3.5.1. Amazon Web Services S3 storage
Copy link

7.3.5.2. Amazon Web Services STS S3 storage
Copy link

7.3.5.3. AWS CloudFront storage
Copy link

7.3.6. Google Cloud Storage
Copy link

7.3.7. Microsoft Azure Blob Storage
Copy link

7.3.8. Swift object storage
Copy link

7.3.9. Nutanix Objects Storage
Copy link

7.3.10. IBM Cloud Object Storage
Copy link

7.3.11. NetApp ONTAP S3 object storage
Copy link

7.3.12. Hitachi Content Platform object storage
Copy link

7.4. Redis configuration fields
Copy link

7.4.1. Build logs
Copy link

7.4.2. User events
Copy link

Learn

Try, buy, & sell

Communities

About Red Hat

Making open source more inclusive

About Red Hat Documentation

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

Chapter 7. Required configuration fields

7.1. General required configuration fieldsCopy linkLink copied to clipboard!

7.2. Database configuration fieldsCopy linkLink copied to clipboard!

7.2.1. Database URICopy linkLink copied to clipboard!

7.2.2. Database connection argumentsCopy linkLink copied to clipboard!

7.2.3. SSL/TLS connection argumentsCopy linkLink copied to clipboard!

7.3. Storage object configuration fieldsCopy linkLink copied to clipboard!

7.3.1. Storage configuration fieldsCopy linkLink copied to clipboard!

7.3.2. Local storageCopy linkLink copied to clipboard!

7.3.3. Red Hat OpenShift Data FoundationCopy linkLink copied to clipboard!

7.3.4. Ceph Object Gateway (RadosGW) storage exampleCopy linkLink copied to clipboard!

7.3.5. Supported AWS storage backendsCopy linkLink copied to clipboard!

7.3.5.1. Amazon Web Services S3 storageCopy linkLink copied to clipboard!

7.3.5.2. Amazon Web Services STS S3 storageCopy linkLink copied to clipboard!

7.3.5.3. AWS CloudFront storageCopy linkLink copied to clipboard!

7.3.6. Google Cloud StorageCopy linkLink copied to clipboard!

7.3.7. Microsoft Azure Blob StorageCopy linkLink copied to clipboard!

7.3.8. Swift object storageCopy linkLink copied to clipboard!

7.3.9. Nutanix Objects StorageCopy linkLink copied to clipboard!

7.3.10. IBM Cloud Object StorageCopy linkLink copied to clipboard!

7.3.11. NetApp ONTAP S3 object storageCopy linkLink copied to clipboard!

7.3.12. Hitachi Content Platform object storageCopy linkLink copied to clipboard!

7.4. Redis configuration fieldsCopy linkLink copied to clipboard!

7.4.1. Build logsCopy linkLink copied to clipboard!

7.4.2. User eventsCopy linkLink copied to clipboard!

Learn

Try, buy, & sell

Communities

About Red Hat

Making open source more inclusive

About Red Hat Documentation

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

7.1. General required configuration fields
Copy link

7.2. Database configuration fields
Copy link

7.2.1. Database URI
Copy link

7.2.2. Database connection arguments
Copy link

7.2.3. SSL/TLS connection arguments
Copy link

7.3. Storage object configuration fields
Copy link

7.3.1. Storage configuration fields
Copy link

7.3.2. Local storage
Copy link

7.3.3. Red Hat OpenShift Data Foundation
Copy link

7.3.4. Ceph Object Gateway (RadosGW) storage example
Copy link

7.3.5. Supported AWS storage backends
Copy link

7.3.5.1. Amazon Web Services S3 storage
Copy link

7.3.5.2. Amazon Web Services STS S3 storage
Copy link

7.3.5.3. AWS CloudFront storage
Copy link

7.3.6. Google Cloud Storage
Copy link

7.3.7. Microsoft Azure Blob Storage
Copy link

7.3.8. Swift object storage
Copy link

7.3.9. Nutanix Objects Storage
Copy link

7.3.10. IBM Cloud Object Storage
Copy link

7.3.11. NetApp ONTAP S3 object storage
Copy link

7.3.12. Hitachi Content Platform object storage
Copy link

7.4. Redis configuration fields
Copy link

7.4.1. Build logs
Copy link

7.4.2. User events
Copy link