Project Quay Release Notes

You can review new features, bug fixes, known issues, and configuration changes for each Project Quay release. Use these notes to plan upgrades and understand changes that affect standalone and OpenShift Container Platform deployments.

About Project Quay

Project Quay is a container registry platform for secure storage, distribution, and governance of containers and cloud-native artifacts. You can deploy it as a standalone component or as an Operator on OpenShift Container Platform.

Project Quay includes the following features and benefits:

Granular security management
Fast and robust at any scale
High velocity CI/CD
Automated installation and updates
Enterprise authentication and team-based access control
OpenShift Container Platform integration

Project Quay is regularly released, containing new features, bug fixes, and software updates. You can upgrade Project Quay for both standalone and OpenShift Container Platform deployments.

Important

Project Quay only supports rolling back, or downgrading, to previous z-stream versions, for example, {producty-n1}.2 → {producty-n1}.1. Rolling back to previous y-stream versions (3.18 → {producty-n1}) is not supported. This is because Project Quay updates might contain database schema upgrades that are applied when upgrading to a new version of Project Quay. Database schema upgrades are not considered backwards compatible.

Downgrading to previous z-streams is neither recommended nor supported by either Operator based deployments or virtual machine based deployments. Downgrading should only be done in extreme circumstances. The decision to rollback your Project Quay deployment must be made in conjunction with the Project Quay support and development teams. For more information, contact Project Quay support.

Additional resources

Upgrade Project Quay

Project Quay release notes

You can review y-stream and z-stream release information for Project Quay, including new features, bug fixes, and known issues for each version.

RHSA-2026:48085 - Project Quay 3.18.0 release

Project Quay 3.18 is available with Clair 4.9. You can review the advisory, compatibility matrix, and life cycle policy for this release.

Issued 2026-07-29

Project Quay release 3.18 is now available with Clair 4.9. The bug fixes that are included in the update are listed in the RHSA-2026:48085 advisory. For the most recent compatibility matrix, see Quay Enterprise 3.x Tested Integrations. For information on the release cadence of Project Quay, see the Project Quay Life Cycle Policy.

Project Quay new features and enhancements

You can review new features and enhancements in Project Quay 3.18, including multi-issuer OIDC support, programmatic OAuth token provisioning, and OAuth API access tokens in the UI.

Microsoft Entra ID v2 token and multi-issuer OIDC support

With this release, Project Quay supports multiple OIDC issuers and audiences per identity provider in *_LOGIN_CONFIG blocks. You can configure Project Quay to accept Microsoft Entra ID v1.0 and v2.0 tokens from the same provider, validate custom token audiences for On-Behalf-Of (OBO) API flows, and optionally restrict which client applications can authenticate by using the authorized party (azp) claim.

This enhancement enables integrations with Red Hat Developer Hub (RHDH), Red Hat Dev Spaces, and other tools that use modern Entra ID v2.0 access tokens. Existing configurations that use a single OIDC_ISSUER continue to work without changes.

Project Quay now validates token audiences on API bearer-token requests. Audience verification is no longer disabled for SSO bearer tokens.

Federated robot authentication also supports an optional audiences array on each federation configuration entry. When configured, Project Quay validates the external OIDC token audience during robot token exchange. When absent, audience validation is skipped and a deprecation warning is logged. For more information, see Robot federation audiences field.

For configuration field descriptions, see OIDC multi-issuer configuration fields. For setup and migration procedures, see Configuring Microsoft Entra ID v2 and multi-issuer OIDC.

Programmatic OAuth token provisioning (Tech Preview)

Project Quay 3.18 introduces programmatic OAuth API token life cycle management for organization applications. You can create, list, and revoke OAuth API tokens by using the REST API instead of the UI.

When FEATURE_PROGRAMMATIC_BOOTSTRAP is enabled, Project Quay can also auto-generate a high-privilege bootstrap OAuth token on startup and write it to a local file or Kubernetes Secret. Use this bootstrap token for zero-touch automation workflows such as GitOps-based deployments, CI/CD bootstrap, and headless registry provisioning.

This feature is available as Tech Preview in Project Quay 3.18.

For configuration fields, see Programmatic bootstrap configuration fields. For setup and examples, see Programmatic OAuth token provisioning.

OAuth API Access Tokens management UI

With this release, organization OAuth applications include an API Access Tokens page in the Project Quay v2 UI. You can create named OAuth 2 access tokens, review token metadata such as scopes and last-used time, delete individual tokens, and rotate legacy long-lived (10 years) tokens without deleting the parent OAuth application.

Existing tokens continue to work for up to 10 years until you revoke them.

For more information, see Creating an OAuth 2 access token and Rotating a legacy OAuth 2 access token.

Repository mirror metrics and health monitoring

Project Quay 3.18 adds Prometheus metrics and a health API endpoint for repository mirroring. Operators can monitor synchronization status, pending tags, and failures per repository and set up alerts in Prometheus or Grafana.

Four new per-repository metrics are available from the mirror worker metrics endpoint:

quay_repository_mirror_pending_tags — tags awaiting synchronization
quay_repository_mirror_last_sync_status — last sync outcome (failed, success, or in progress)
quay_repository_mirror_sync_complete — whether all tags synchronized in the last run
quay_repository_mirror_sync_failures_total — cumulative failure count by namespace and reason

For more information, see Monitoring repository mirroring, getRepositoryMirrorHealth, and getSuperUserRepositoryMirrorHealth.

Red Hat Quay on OpenShift Container Platform new features and enhancements

You can review new features and enhancements for Red Hat Quay on OpenShift Container Platform in 3.18, including TLS security profile inheritance, Redis and Clair resource overrides, and Operator-managed PostgreSQL TLS.

OpenShift Container Platform cluster TLS security profile inheritance & Post-Quantum Cryptography (PQC) readiness

When the tls component is set to unmanaged, the Project Quay Operator inherits the cluster’s TLS security profile from the APIServer configuration when neither SSL_PROTOCOLS nor SSL_CIPHERS is configured in the configBundleSecret resource. This helps align Project Quay with the platform TLS policy and supports Post-Quantum Cryptography (PQC) readiness when the cluster profile requires TLS 1.3.

To fully override or preserve TLS behavior, set both SSL_PROTOCOLS and SSL_CIPHERS in the configBundleSecret resource. Setting either field disables cluster-profile inheritance for both fields; partial configuration is not supported. Supported profile types are Old, Intermediate, Modern, and Custom. If the cluster has no profile set, the Operator defaults to the Intermediate profile (TLS 1.2 and TLS 1.3).

Table 1. TLS security profile inheritance by TLS mode
TLS mode	Before this release	After this release
Managed TLS (Operator-managed route)	OpenShift Container Platform Route enforces the cluster TLS profile	No change
Unmanaged TLS (`tls` component set to `unmanaged`)	Project Quay used built-in TLS defaults	Project Quay inherits the cluster TLS security profile when neither `SSL_PROTOCOLS` nor `SSL_CIPHERS` is configured

Important

If you use unmanaged TLS and require specific TLS settings that differ from the cluster default, set both SSL_PROTOCOLS and SSL_CIPHERS in your configBundleSecret resource before upgrading. Setting only one field disables cluster-profile inheritance for both fields. For more information, see Preserving TLS settings before upgrading Red Hat Quay on OpenShift Container Platform.

On Kubernetes clusters without the config.openshift.io API, the Operator does not inject TLS settings and Project Quay uses its built-in defaults.

For more information about SSL/TLS configuration fields, see SSL/TLS configuration fields.

For information about custom certificates and the config bundle, see Configuring custom SSL/TLS certificates for Red Hat Quay on OpenShift Container Platform. For information about TLS protocol and cipher inheritance, see OpenShift Container Platform cluster TLS security profile inheritance.

For more information about NIST post-quantum cryptography standards, see Post-Quantum Cryptography.

For the latest compliance information for OpenShift Container Platform, RHEL, and Red Hat Enterprise Linux CoreOS (RHCOS), see Compliance Activities and Government Standards.

Redis component resource overrides

With this release, you can override CPU and memory requests and limits for the Operator-managed redis component in the QuayRegistry custom resource. This brings redis in line with other managed components, such as quay, clair, mirror, and postgres, that already support resource overrides through spec.components[].overrides.resources.

When you do not set resource overrides for redis, the Operator uses the following defaults:

Requests: 500m CPU and 1Gi memory
Limits: 4000m CPU and 16Gi memory

For example, to tune Redis resources for a smaller cluster, add an entry like the following under spec.components:

    - kind: redis
      managed: true
      overrides:
        resources:
          limits:
            cpu: 400m
            memory: 400Mi
          requests:
            cpu: 400m
            memory: 400Mi

For more information about configuring resource requests and limits, see Configuring QuayRegistry CR resources.

Clair ephemeral storage overrides

With this release, you can configure volumeSize and storageClassName overrides on the managed clair component in the QuayRegistry custom resource. These overrides customize the ephemeral volume that Clair uses for image layer extraction at /var/tmp.

When you do not set overrides, the Operator requests 20Gi of ephemeral storage with no explicit storage class. Large or unexpected images can exhaust this scratch space and disrupt vulnerability scanning.

For example:

    - kind: clair
      managed: true
      overrides:
        volumeSize: 50Gi
        storageClassName: fast-ssd

These overrides apply to Clair scratch storage only. They do not resize the managed Clair PostgreSQL database.

For more information, see Configuring ephemeral storage for managed Clair.

External TLS Secret reference for the QuayRegistry CR

The Project Quay Operator supports referencing an external kubernetes.io/tls Secret for registry HTTPS certificates through the QuayRegistry CR. This feature enables automated certificate rotation without embedding ssl.cert and ssl.key files in the configBundleSecret CR. Certificate sources can include cert-manager, HashiCorp Vault, or manually updated Secrets. When the referenced Secret changes, the Operator performs a rolling restart of Project Quay pods.

The QuayRegistry status includes a ComponentTLSReady condition that reports whether TLS from the external Secret is valid and applied.

For configuration steps, see Referencing an external TLS Secret for Red Hat Quay on OpenShift Container Platform. For a cert-manager example, see Example: Using cert-manager with an external TLS Secret.

TLS encryption for Operator-managed PostgreSQL

With this release, you can enable TLS encryption for Operator-managed PostgreSQL databases used by Project Quay and Clair. Set overrides.tls.enabled: true on the postgres and/or clairpostgres components in the QuayRegistry custom resource.

When TLS is enabled, the Operator configures PostgreSQL to accept encrypted connections and mounts the required TLS certificates. TLS is opt-in; existing deployments are unaffected until you enable it. After enablement, verify that PostgreSQL reports ssl = on. Optionally confirm client TLS sessions or an sslmode setting such as verify-full in the registry database configuration.

Certificate options include the following:

On OpenShift Container Platform, the Operator uses the cluster Service CA when no custom Secret is provided.
On other Kubernetes platforms, the Operator generates ECDSA P-256 self-signed certificates.
You can supply your own certificates by referencing a Secret with overrides.tls.secretRef.name. This format is compatible with cert-manager.

You can enable TLS independently for the postgres and clairpostgres components. This feature addresses encryption-in-transit requirements for Operator-managed databases without provisioning external PostgreSQL infrastructure.

Important

This feature configures transport encryption for Operator-managed PostgreSQL. Transport encryption is distinct from the managed tls component, which handles Project Quay’s external HTTPS endpoint.

For configuration examples, certificate options, and verification steps, see TLS encryption for Operator-managed PostgreSQL.

Project Quay configuration fields updates and changes

You can review configuration fields that are new or changed in Project Quay 3.18, including OIDC multi-issuer settings, QuayRegistry TLS fields, and programmatic bootstrap options.

SSL_PROTOCOLS and SSL_CIPHERS Operator inheritance on OpenShift Container Platform

When you deploy Red Hat Quay on OpenShift Container Platform, the Operator can populate the existing SSL_PROTOCOLS and SSL_CIPHERS fields from the cluster-wide OpenShift Container Platform tlsSecurityProfile when neither field is set in the configBundleSecret resource. To fully override or preserve TLS behavior, set both fields. Setting either field disables cluster-profile inheritance for both fields.

For more information, see OpenShift Container Platform cluster TLS security profile inheritance and Preserving TLS settings before upgrading Red Hat Quay on OpenShift Container Platform.

OIDC multi-issuer and multi-audience fields

The following optional fields were added to *_LOGIN_CONFIG blocks in Project Quay 3.18:

Table 2. OIDC multi-issuer fields
Field	Type	Description
.OIDC_ISSUERS	Array of String	Accepted issuer URLs for the provider. When set, Project Quay accepts tokens whose `iss` claim matches any entry. If not set, Project Quay uses the existing `OIDC_ISSUER` value.
.OIDC_AUDIENCES	Array of String	Accepted audience values for bearer token and On-Behalf-Of (OBO) flows. When set, Project Quay validates the token `aud` claim against this list. `CLIENT_ID` is always implicitly included. If not set, audience validation defaults to `CLIENT_ID`.
.OIDC_ALLOWED_CLIENTS	Array of String	Optional whitelist of authorized party (`azp`) client IDs. When set, only tokens from these client applications are accepted. If not set, all clients are accepted.

If both OIDC_ISSUER and OIDC_ISSUERS are set, OIDC_ISSUERS takes precedence and Project Quay logs a warning.

For field reference details, see OIDC configuration fields. For configuration examples, see Configuring Microsoft Entra ID v2 and multi-issuer OIDC. The following configuration fields have been added to Project Quay 3.18.

QuayRegistry TLS component fields

The following fields apply to the tls entry in spec.components of the QuayRegistry CR when deploying Red Hat Quay on OpenShift Container Platform.

Table 3. QuayRegistry TLS component fields
Field	Type	Description
`secretRef`	Object	References an external TLS Secret in the same namespace as the `QuayRegistry` CRD. Valid only when `managed` is `false`. The Secret must be of type `kubernetes.io/tls` and contain `tls.crt` and `tls.key` data keys. The Operator watches the Secret and triggers a rolling restart of Project Quay pods when certificate data changes. Do not use with `ssl.cert` and `ssl.key` files in the `configBundleSecret`.
`secretRef.name`	String	Name of the Kubernetes Secret that stores the TLS certificate and private key.

Table 4. QuayRegistry TLS status condition
Condition	Type	Description
`ComponentTLSReady`	Status	Reports whether TLS from the configured source (external Secret or config bundle) is valid and applied to the registry deployment.

For procedures and examples, see Referencing an external TLS Secret for Red Hat Quay on OpenShift Container Platform.

Programmatic bootstrap configuration fields

Project Quay 3.18 adds configuration fields for Tech Preview programmatic bootstrap OAuth token provisioning:

Field Type Description

Field	Type	Description
`FEATURE_PROGRAMMATIC_BOOTSTRAP`	Boolean	Enables bootstrap token auto-generation on startup. Default: `false`.
`BOOTSTRAP_TOKEN_OWNER`	String	Superuser that owns the bootstrap OAuth application and token. Required when the feature flag is enabled.
`BOOTSTRAP_TOKEN_PATH`	String	Local filesystem path for the bootstrap token JSON. Default: `/var/lib/quay/quay-machine-token.json`.
`BOOTSTRAP_TOKEN_EXPIRATION`	Integer	Bootstrap token lifetime in seconds. Default: `3600`.
`BOOTSTRAP_TOKEN_SCOPE`	String	Space-separated OAuth scopes for the bootstrap token.
`PROGRAMMATIC_TOKEN_K8S_SECRET`	String	Kubernetes Secret name for bootstrap token storage.
`PROGRAMMATIC_TOKEN_K8S_KEY`	String	Secret data key for the bootstrap token JSON. Default: `token.json`.
`PROGRAMMATIC_TOKEN_K8S_NAMESPACE`	String	Namespace for the bootstrap token Secret.

FEATURE_PROGRAMMATIC_BOOTSTRAP

Boolean

Enables bootstrap token auto-generation on startup. Default: false.

BOOTSTRAP_TOKEN_OWNER

String

Superuser that owns the bootstrap OAuth application and token. Required when the feature flag is enabled.

BOOTSTRAP_TOKEN_PATH

String

Local filesystem path for the bootstrap token JSON. Default: /var/lib/quay/quay-machine-token.json.

BOOTSTRAP_TOKEN_EXPIRATION

Integer

Bootstrap token lifetime in seconds. Default: 3600.

BOOTSTRAP_TOKEN_SCOPE

String

Space-separated OAuth scopes for the bootstrap token.

PROGRAMMATIC_TOKEN_K8S_SECRET

String

Kubernetes Secret name for bootstrap token storage.

PROGRAMMATIC_TOKEN_K8S_KEY

String

Secret data key for the bootstrap token JSON. Default: token.json.

PROGRAMMATIC_TOKEN_K8S_NAMESPACE

String

Namespace for the bootstrap token Secret.

For descriptions and YAML examples, see Programmatic bootstrap configuration fields.

API endpoint enhancements

You can review API enhancements in Project Quay 3.18, including robot federation audiences, organization application OAuth token life cycle endpoints, and bootstrap token renewal.

Robot federation audiences field

Robot federation configuration entries now support an optional audiences array in addition to issuer and subject. During federated robot token exchange (GET /oauth2/federation/robot/token), when audiences is present on the matching federation entry, Project Quay validates the external OIDC token audience against that list. When audiences is absent, audience validation is skipped and Project Quay logs a deprecation warning advising you to configure audiences.

A future release requires the audiences field for federated robot authentication.

Configure federation entries by using the Project Quay v2 UI or POST /api/v1/organization/{orgname}/robots/{robot_shortname}/federation. In Project Quay 3.18, create and update requests persist issuer and subject only; audience validation applies when audiences is present in the stored federation configuration. For field descriptions, examples, and current API limitations, see createOrgRobotFederation and Configuring federation audiences.

Organization application OAuth token life cycle

Project Quay 3.18 adds REST API endpoints to manage OAuth API tokens for organization applications:

Method Endpoint Description

Method	Endpoint	Description
`POST`	`/api/v1/organization/{orgname}/applications/{client_id}/tokens`	Create a token
`GET`	`/api/v1/organization/{orgname}/applications/{client_id}/tokens`	List token metadata
`DELETE`	`/api/v1/organization/{orgname}/applications/{client_id}/tokens/{token_uuid}`	Revoke a token

POST

/api/v1/organization/{orgname}/applications/{client_id}/tokens

Create a token

GET

/api/v1/organization/{orgname}/applications/{client_id}/tokens

List token metadata

DELETE

/api/v1/organization/{orgname}/applications/{client_id}/tokens/{token_uuid}

Revoke a token

Create requests accept name, scope, and optional expiration (seconds). The bearer token secret is returned only in the create response.

For API schemas and examples, see createOrganizationApplicationToken, listOrganizationApplicationTokens, and deleteOrganizationApplicationToken.

Bootstrap token renewal

When FEATURE_PROGRAMMATIC_BOOTSTRAP is enabled, POST /api/v1/bootstrap/renew rotates the bootstrap OAuth token. The new token is written to the configured filesystem path or Kubernetes Secret, and the previous token is invalidated immediately. The response is {"status": "rotated"}.

For more information, see renewBootstrapToken and Renewing the bootstrap token. The following API endpoints were added in Project Quay 3.18.

Repository mirror health API endpoints

New health endpoints report the status of repository mirroring operations, including worker availability, repository sync counts, and detected issues. Both require a fresh login. Global queries without a namespace require superuser access; namespace-scoped queries require organization membership or user-admin permission for that namespace.

Name Description Schema

Name	Description	Schema
getRepositoryMirrorHealth	Return health status for repository mirroring operations. Optional `namespace` and `detailed` query parameters. Returns HTTP `200` when healthy and HTTP `503` when unhealthy.	object
getSuperUserRepositoryMirrorHealth	Return a global mirror health summary for superusers without repository-identifying samples. Returns HTTP `200` when healthy and HTTP `503` when unhealthy.	object

getRepositoryMirrorHealth

Return health status for repository mirroring operations. Optional namespace and detailed query parameters. Returns HTTP 200 when healthy and HTTP 503 when unhealthy.

object

getSuperUserRepositoryMirrorHealth

Return a global mirror health summary for superusers without repository-identifying samples. Returns HTTP 200 when healthy and HTTP 503 when unhealthy.

object

See getRepositoryMirrorHealth and getSuperUserRepositoryMirrorHealth for more information, including example commands.

Project Quay bug fixes

You can review bug fixes included in Project Quay 3.18.

The following issues were fixed with Project Quay 3.18.

Note	Not all bug fixes included in the RHSA-2026:48085 advisory are documented here. Many of the bugs included in the advisory were found and resolved when testing new features included as part of this release.

PROJQUAY-10504. Previously, deleting a manifest by digest could silently skip immutable tags and remove the underlying manifest, bypassing tag immutability protections that correctly blocked deletion by tag name.

With this release, digest-based manifest deletion respects immutable tags and blocks the operation when immutability applies.
PROJQUAY-11952. Previously, session timeout and related settings such as SESSION_TIMEOUT, FEATURE_PERMANENT_SESSIONS, and FRESH_LOGIN_TIMEOUT were not applied correctly, so sessions could remain active longer than configured.

With this release, Project Quay honors the configured session timeout values.
PROJQUAY-8440. Previously, pulling an image that was already present in the organization proxy cache still required the upstream registry to be reachable. If the upstream registry was unavailable, cached pulls could fail.

With this release, cached images can be served from the proxy cache without requiring upstream registry availability.
PROJQUAY-11119. Previously, organization proxy cache configuration failed when FEATURE_IMMUTABLE_TAGS was not enabled, even though the default value of that feature is false.

With this release, organization proxy cache works when FEATURE_IMMUTABLE_TAGS is disabled.
PROJQUAY-10575. Previously, canceling repository mirroring produced incomplete or null log messages.

With this release, canceling a repository mirror logs a clear result.
PROJQUAY-10798. Previously, canceling an organization mirror sync could generate an endless stream of Organization mirror sync failed - Sync cancelled log messages.

With this release, canceling an organization mirror no longer floods logs with repeated cancellation messages.
PROJQUAY-11382. Previously, deleting an organization mirror configuration left mirrored repositories stuck in the ORG_MIRROR state, which blocked pushes to those repositories.

With this release, deleting the organization mirror configuration restores repositories so that users can push again.
PROJQUAY-11891. Previously, you could not delete an organization that was configured for organization mirroring because of a database error.

With this release, you can remove organizations that have organization mirror configurations.
PROJQUAY-11027. Previously, using Cancel Sync for an organization mirror cleared the Next Sync Date value and prevented updating the mirror configuration to sync again.

With this release, canceling a sync preserves the schedule so that you can update the configuration and resume mirroring.
PROJQUAY-11347. Previously, changing a repository mirror tag pattern required re-entering credentials for private upstream repositories. Saving without re-entering credentials could clear stored credentials and cause the next sync to fail with an authorization error.

With this release, updating the tag pattern retains existing credentials unless you explicitly change them.
PROJQUAY-11478. Previously, the new UI blocked creating a proxy cache configuration even when organization mirroring was not enabled in config.yaml.

With this release, you can create proxy cache configurations when organization mirroring is disabled.
PROJQUAY-11515. Previously, the API allowed creating a proxy cache configuration on an organization that was already managed by organization mirroring, even though the UI hid that option.

With this release, the API rejects proxy cache creation for organizations that are in the organization mirror state.
PROJQUAY-11077. Previously, OIDC login redirects failed when Project Quay was exposed on a non-standard HTTP or HTTPS port because nginx forwarded only the hostname without the port.

With this release, OIDC redirects include the configured port and complete successfully.
PROJQUAY-11319. Previously, OCI images with no history entries in the image config caused an AttributeError in layer processing, so the manifest API returned 404 and tag sizes were missing in the UI.

With this release, OCI images without history are handled correctly.
PROJQUAY-11637. Previously, lazy loading of OCI indexes failed when the index included Docker v2 schema 2 images, which the OCI specification allows.

With this release, OCI indexes that contain Docker v2 schema 2 manifests load successfully.
PROJQUAY-10934. Previously, repository cache entries were not invalidated when a repository was deleted, which could leave stale cache data.

With this release, deleting a repository invalidates the related cache entries.
PROJQUAY-11288. Previously, nginx returned HTTP 404 instead of 502 when the backend was unavailable because a custom 502 error page was missing.

With this release, unavailable backends return the expected 502 response.
PROJQUAY-11331. Previously, a malformed struct tag on DistributedStorageArgs.Signature in the config tool broke storage configuration serialization.

With this release, storage configuration that uses signature settings serializes correctly.
PROJQUAY-11486. Previously, the configuration validator did not properly validate S3 URLs.

With this release, invalid S3 URLs are rejected during configuration validation.
PROJQUAY-11524. Previously, a race condition during initial database setup could cause intermittent startup failures.

With this release, initial database setup completes reliably.
PROJQUAY-11851. Previously, an RBAC denial on apiservers.config.openshift.io could block the entire Project Quay Operator deployment on OpenShift Container Platform.

With this release, the Operator no longer requires that permission to complete deployment.
PROJQUAY-11852. Previously, the Operator could panic when processing an invalid configuration.

With this release, invalid configurations are handled without panicking.
PROJQUAY-11501. Previously, the Operator rejected PULL_METRICS_REDIS in the config bundle secret when Redis was Operator-managed after the config-tool migration.

With this release, PULL_METRICS_REDIS is accepted in that configuration.
PROJQUAY-11549. Previously, external TLS secretRef configuration did not validate that the certificate matched SERVER_HOSTNAME.

With this release, the Operator validates that the external TLS certificate covers SERVER_HOSTNAME.
PROJQUAY-12322. Previously, the Modern TLS profile could pass TLS 1.3 cipher suites to the nginx ssl_ciphers directive, which caused nginx to crash.

With this release, TLS 1.3 ciphers are not passed to ssl_ciphers, and nginx starts successfully with the Modern TLS profile.
PROJQUAY-9157. Previously, pods could fail with MountVolume.SetUp failed for volume "config" in some configuration mount scenarios.

With this release, the config volume mounts correctly.
PROJQUAY-12230. Previously, quota warning and error notifications failed with TypeError: Decimal is not JSON serializable, so quota notifications were silently dropped.

With this release, quota notification payloads serialize correctly and notifications are delivered.
PROJQUAY-12233. Previously, global readonly superusers were blocked from reading organization namespace notification GET endpoints when FEATURE_SUPERUSERS_FULL_ACCESS was enabled.

With this release, global readonly superusers can read namespace notifications.
PROJQUAY-11678. Previously, the Superuser Build Logs page in the new UI returned HTTP 500 because of a logic error in BuildTrigger.to_dict().

With this release, looking up build logs by UUID succeeds without a server error.
PROJQUAY-11930. Previously, the Superuser Build Logs page in the new UI showed No logs available for archived builds that still had valid logs in object storage.

With this release, archived build logs display correctly in the new UI.
PROJQUAY-11158. Previously, the Auto-Prune Policies tab was missing for user namespace organizations in the UI.

With this release, the Auto-Prune Policies tab is available for user organizations again.
PROJQUAY-9695. Previously, the log rotate worker stopped working after upgrading to Project Quay 3.15.

With this release, the log rotate worker runs correctly after upgrade.
PROJQUAY-12197. Previously, Clair could fail to pull the upstream vulnerability database, which prevented vulnerability reports for scanned images.

With this release, Clair can update its vulnerability database from upstream sources.
PROJQUAY-12221. Previously, the Superuser Change Log page in the new UI failed to load and returned HTTP 502 because CHANGELOG.md was missing from the container image.

With this release, the Change Log page loads successfully.
PROJQUAY-11931. Previously, the Superuser Change Log page in the new UI showed stale Project Quay 3.11.0 content instead of notes for the current release.

With this release, the Change Log page displays content for the current release.
PROJQUAY-11577. Previously, the usage logs chart legend in the new UI overlapped the chart area and made both the legend and chart hard to read.

With this release, the legend no longer overlaps the chart.
PROJQUAY-10605. Previously, the Repository field in usage logs duplicated namespace information.

With this release, the Repository field shows the repository path without duplicated namespace text.
PROJQUAY-10795. Previously, the Load More Logs button flashed repeatedly while usage logs were loading.

With this release, the Load More Logs control remains stable while logs load.
PROJQUAY-11079. Previously, the change_tag_immutability action was missing from the usage logs chart in the new UI.

With this release, tag immutability changes appear in the usage logs chart.
PROJQUAY-11025. Previously, the organization mirror Schedule or Pending state in the UI did not stay consistent with the related dropdown controls.

With this release, the organization mirror schedule state matches the dropdown selection.
PROJQUAY-11217. Previously, searching for a repository that did not exist left a circular loading spinner on the page indefinitely.

With this release, a search for a missing repository completes and no longer spins forever.
PROJQUAY-11218. Previously, selecting a permission in the permissions dropdown in Firefox navigated to a temporary site unavailable page.

With this release, selecting a permission in Firefox works without that navigation failure.
PROJQUAY-11219. Previously, text entered in the repository filter could appear in unrelated places in the UI.

With this release, repository filter text remains in the filter field.
PROJQUAY-11257. Previously, the branding logo on the new UI login page could be invisible.

With this release, the login page branding logo displays correctly.
PROJQUAY-12151. Previously, wizard panels could overflow their modal windows when creating a robot account, team, or build trigger.

With this release, those wizard panels fit within the modal.
PROJQUAY-9246. Previously, the new UI did not allow selecting all OAuth applications in bulk.

With this release, you can select all OAuth applications from the list.
PROJQUAY-9256. Previously, you could not clear the default Skopeo timeout interval value and enter a new value in the UI.

With this release, you can clear and replace the Skopeo timeout interval value.
PROJQUAY-9883. Previously, the filter on the Superuser Service Keys panel did not work.

With this release, filtering service keys works as expected.
PROJQUAY-11314. Previously, the Quay mirror registry installer did not fail when the configured hostname did not meet DNS requirements, which could lead to a broken installation.

With this release, installation fails early when the hostname is not DNS-compliant.
PROJQUAY-5075. Previously, startup validation could fail when a non-preferred storage engine was unavailable, even if the preferred storage engine was healthy.

With this release, startup continues when the preferred storage engine is available.
PROJQUAY-10845. Previously, Project Quay could send non-image artifacts for vulnerability scanning.

With this release, non-image artifacts are not submitted for scanning.
PROJQUAY-11433. Previously, repository UPDATE queries during namespace deletion could take many seconds and slow large deletions.

With this release, those database updates complete more efficiently during namespace deletion.
PROJQUAY-11691. Previously, needless permission checks slowed critical UI API paths. On LDAP-backed installations this could delay or prevent the UI from loading.

With this release, UI permission checks are optimized so the interface loads reliably, including on LDAP-backed deployments.
PROJQUAY-9668. Previously, excessive LDAP queries during login could cause timeouts and prevent users from signing in.

With this release, LDAP login query volume is reduced so users can authenticate reliably.
PROJQUAY-10426. Previously, Project Quay executed an excessive number of LDAP binds against an empty registry during initial login and username confirmation.

With this release, LDAP bind volume during login is reduced.
PROJQUAY-10315. Previously, pulling images from a proxy cache organization could fail with HTTP 404 even when the image should have been served from cache.

With this release, proxy cache pulls succeed when the cached image is available.
PROJQUAY-10625. Previously, automatic redirects for repository and organization URLs worked in UI v1 but failed in UI v2.

With this release, repository and organization URL redirects work in the new UI.
PROJQUAY-10844. Previously, teams with more than 20 members could not paginate beyond the first 20 members in UI v2 because the next-page control stayed disabled.

With this release, team member pagination works for teams larger than 20 members.
PROJQUAY-11235. Previously, the Generate Access Token page called external CDN resources and Google Fonts, which delayed the page in air-gapped environments.

With this release, generating an access token no longer depends on those external resources.
PROJQUAY-11375. Previously, the Operator continuously recreated the calculated config secret about once per minute even when configuration had not changed.

With this release, the Operator no longer recreates the config secret on every reconcile when nothing has changed.
PROJQUAY-1920. Previously, a config-tool OIDC validation bug could prevent the registry from starting when a custom OIDC provider was configured.

With this release, OIDC validation no longer blocks registry startup for valid custom OIDC configurations.

Project Quay feature tracker

You can track Project Quay feature availability across recent releases, including Technology Preview status, and review platform support for IBM Power, IBM Z, and IBM LinuxONE.

Some features available in previous releases have been deprecated or removed. Deprecated functionality is still included in Project Quay, but is planned for removal in a future release and is not recommended for new deployments. For the most recent list of deprecated and removed functionality in Project Quay, refer to Table 1.1. Additional details for more fine-grained functionality that has been deprecated and removed are listed after the table.

Table 5. Features tracker
Feature	Quay 3.18	Quay 3.17	Quay 3.16
Microsoft Entra ID v2 token and multi-issuer OIDC support	General Availability	-	-
Programmatic OAuth token provisioning	Technology Preview	-	-
OpenShift Container Platform cluster TLS security profile inheritance & Post-Quantum Cryptography (PQC) readiness	General Availability	-	-
Sparse manifest support for multi-architecture filtering	General Availability	General Availability	-
Immutable tags overview	General Availability	General Availability	-
Proof Key for Code Exchange support for OIDC	General Availability	General Availability	-
v1 UI	Deprecated	Deprecated	Deprecated

IBM Power, IBM Z, and IBM® LinuxONE support matrix

Table 6. list of supported and unsupported features
Feature	IBM Power	IBM Z and IBM® LinuxONE
Allow team synchronization via OIDC on Azure	Not Supported	Not Supported
Backing up and restoring on a standalone deployment	Supported	Supported
Clair Disconnected	Supported	Supported
Geo-Replication (Standalone)	Supported	Supported
Geo-Replication (Operator)	Supported	Supported
IPv6	Not Supported	Not Supported
Migrating a standalone to operator deployment	Supported	Supported
Mirror registry	Supported	Supported
Quay config editor - mirror, OIDC	Supported	Supported
Quay config editor - MAG, Kinesis, Keystone, GitHub Enterprise	Not Supported	Not Supported
Quay config editor - Red Hat Quay V2 User Interface	Supported	Supported
Quay Disconnected	Supported	Supported
Repo Mirroring	Supported	Supported