Chapter 9. Automation configuration options


Red Hat Quay supports various mechanisms for automating deployment and configuration, which allows the integration of Red Hat Quay into GitOps and CI/CD pipelines. By defining these options and leveraging the API, Red Hat Quay can be initialized and managed without using the UI.

Note

Because the Red Hat Quay Operator manages the config.yaml file through the configBundleSecret custom resource (CR), pre-configuring Red Hat Quay on OpenShift Container Platform requires an administrator to manually create a valid config.yaml file with the desired configuration. This file must then be bundled into a new Kubernetes Secret and used to replace the default configBundleSecret CR referenced by the QuayRegistry CR. This allows Red Hat Quay on OpenShift Container Platform to be deployed in a fully automated manner, bypassing the web-based configuration UI. For more information, see Modifying the QuayRegistry CR after deployment.

For on-premise Red Hat Quay deployments, pre-configuration is done by manually creating a valid config.yaml file and then deploying the registry.

Automation options are ideal for environments that require declarative Red Hat Quay deployments, such as disconnected or air-gapped clusters.

9.1. Pre-configuration options for automation

Red Hat Quay provides configuration options that enable registry administrators to automate early setup tasks and API accessibility. These options are useful for new deployments and controlling how API calls can be made. The following options support automation and administrative control.

Expand
Table 9.1. Automation configuration fields
FieldTypeDescription

FEATURE_USER_INITIALIZE

Boolean

Enables initial user bootstrapping in a newly deployed Red Hat Quay registry. When this field is set to True in the config.yaml file prior to deployment, it allows an administrator to create the first user by calling the api/v1/user/initialize endpoint.

Note

Unlike all other registry API calls that require an OAuth 2 access token generated by an OAuth application in an existing organization, the api/v1/user/initialize endpoint does not require authentication.

BROWSER_API_CALLS_XHR_ONLY

Boolean

Controls whether the registry API only accepts calls from browsers. To allow general browser-based access to the API, administrators must set this field to False. If set to True, API calls are blocked, preventing both administrators and users from interacting with the API.

SUPER_USERS

String

Defines a list of administrative users, or superusers, who have full privileges and unrestricted access to the registry. Red Hat Quay administrators should configure SUPER_USERS in the config.yaml before deployment to ensure immediate administrative access without requiring a redeploy. Setting this field post-deployment requires restarting the registry to take effect.

FEATURE_USER_CREATION

Boolean

Relegates the creation of new users to only superusers when this field is set to False. This setting is useful in controlled environments where user access must be provisioned manually by administrators.

The following YAML shows you the suggested configuration for automation:

Suggested configuration for automation

# ...
FEATURE_USER_INITIALIZE: true
BROWSER_API_CALLS_XHR_ONLY: false
SUPER_USERS:
- quayadmin
FEATURE_USER_CREATION: false
# ...
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