Red Hat Quay Release Notes

Red Hat Quay 3.17

Red Hat Quay

Red Hat OpenShift Documentation Team

Preface

Red Hat Quay container registry platform provides secure storage, distribution, and governance of containers and cloud-native artifacts on any infrastructure. It is available as a standalone component or as an Operator on OpenShift Container Platform. Red Hat 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

Red Hat Quay is regularly released, containing new features, bug fixes, and software updates. To upgrade Red Hat Quay for both standalone and OpenShift Container Platform deployments, see Upgrade Red Hat Quay.

Important

Red Hat Quay only supports rolling back, or downgrading, to previous z-stream versions, for example, 3.16.2 → 3.16.1. Rolling back to previous y-stream versions (3.17 → 3.16) is not supported. This is because Red Hat Quay updates might contain database schema upgrades that are applied when upgrading to a new version of Red Hat 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 Red Hat Quay deployment must be made in conjunction with the Red Hat Quay support and development teams. For more information, contact Red Hat Quay support.

Documentation for Red Hat Quay is versioned with each release. The latest Red Hat Quay documentation is available from the This content is not included.Red Hat Quay Documentation page. Currently, version 3 is the latest major version.

Note

Prior to version 2.9.2, Red Hat Quay was called Quay Enterprise. Documentation for 2.9.2 and prior versions are archived on the Product Documentation for Red Hat Quay 2.9 page.

Chapter 1. Red Hat Quay release notes

The following sections detail y and z stream release information.

1.1. RHSA-2026:24833 - Red Hat Quay 3.17.3 release

Issued 2026-6-15

Red Hat Quay release 3.17.3 is now available with Clair 4.9. The bug fixes that are included in the update are listed in the RHSA-2026:24833 advisory.

1.1.1. Red Hat Quay 3.17.3 bug fixes

This content is not included.PROJQUAY-11586. Previously, when Red Hat Quay ran behind an OpenShift Container Platform HAProxy ingress controller, usage logs recorded the ingress or load balancer IP address instead of the client source IP for push and pull operations.
With this release, Red Hat Quay records the client IP address in action logs when deployed behind HAProxy ingress. As a result, administrators can audit registry activity by end-user source address.

1.2. RHSA-2026:22465 - Red Hat Quay 3.17.2 release

Issued 2026-06-02

Red Hat Quay release 3.17.2 is now available with Clair 4.9. The bug fixes that are included in the update are listed in the RHSA-2026:22465 advisory.

1.2.1. Red Hat Quay 3.17.2 bug fixes

This content is not included.PROJQUAY-11543. Previously, the Red Hat Quay UI prompted OIDC users for a local password during user verification even though they signed in through an identity provider. Users without a password in the database could not complete verification.
With this release, the UI verifies OIDC users through the identity provider instead of requiring a local password. As a result, OIDC users can complete verification and continue using the registry.
This content is not included.PROJQUAY-11532. Previously, when Red Hat Quay returned a bad gateway response, nginx served HTTP 404 because the 502.html error page was missing from the container image.
With this release, the correct error page is included and nginx returns HTTP 502 for upstream failures. As a result, clients receive the expected status code when the registry is unavailable.
This content is not included.PROJQUAY-11523. Previously, changing a repository mirror tag pattern in the UI required re-entering credentials for private upstream repositories even when credentials were already stored.
With this release, stored mirror credentials persist when you update tag patterns. As a result, you can adjust mirroring filters without repeating credential entry.
This content is not included.PROJQUAY-11504. Previously, canceling an in-progress repository mirror produced a log message that included null Not applicable Not applicable instead of a clear cancellation status.
With this release, canceled mirror operations write a readable log entry. As a result, administrators can interpret mirror cancellation events in usage logs.
This content is not included.PROJQUAY-11502. Previously, searching for a repository that does not exist left a circular loading spinner on the page indefinitely.
With this release, the UI stops loading and reports that no matching repository was found. As a result, search results display correctly for invalid repository names.
This content is not included.PROJQUAY-11485. Previously, the UI blocked creation of a proxy cache configuration when organization-level mirroring was disabled, even when proxy caching was allowed for the organization.
With this release, you can configure proxy caching independently of organization mirroring settings. As a result, organizations can use proxy caches without enabling organization mirrors.
This content is not included.PROJQUAY-11442. Previously, the manifest history view displayed a vertical tracking line on pages where no tags shared the same digest.
With this release, the UI shows the digest relationship line only when multiple tags reference the same manifest. As a result, the manifest history view is easier to read.
This content is not included.PROJQUAY-11414. Previously, canceling an organization mirror sync cleared the configured next sync date.
With this release, canceling a sync retains the scheduled next sync time. As a result, organization mirrors resume on the expected schedule after cancellation.
This content is not included.PROJQUAY-11392. Previously, deleting an organization mirror configuration left affected repositories in the ORG_MIRROR state.
With this release, repositories return to a normal state when organization mirror configuration is removed. As a result, repositories remain usable after mirror cleanup.
This content is not included.PROJQUAY-11374. Previously, you could not select the None permission option in the repository permissions dropdown when creating a robot account in the new UI.
With this release, the None option is selectable in the create robot account dialog. As a result, you can assign repository permissions as intended.
This content is not included.PROJQUAY-11333. Previously, Red Hat Quay could submit non-image artifacts to Clair for vulnerability scanning.
With this release, only supported image content is sent for scanning. As a result, Clair processes relevant container images without errors from unsupported artifact types.
This content is not included.PROJQUAY-11332. Previously, a malformed struct tag on DistributedStorageArgs.Signature caused storage configuration to serialize as Signature instead of signature_version. Operator-managed object storage deployments could fail during upgrade with TypeError: RadosGWStorage.init() got an unexpected keyword argument 'Signature'.
With this release, the signature version field serializes correctly and omits empty values. As a result, Operator-managed storage configurations load without upgrade failures.
This content is not included.PROJQUAY-11330. Previously, the usage logs chart in the new UI did not include change_tag_immutability actions.
With this release, tag immutability changes appear in usage logs. As a result, administrators can audit immutability policy updates from the UI.
This content is not included.PROJQUAY-11297. Previously, the branding logo on the Red Hat Quay login page was nearly invisible in dark mode on self-hosted deployments. The logo used dark text against a dark background, so the product name was unreadable.
With this release, the login page displays a logo that remains visible in both light and dark mode. As a result, branding is readable regardless of browser or OS theme settings.
This content is not included.PROJQUAY-11236. Previously, text entered in the repository filter field appeared in unrelated UI locations on the page.
With this release, filter input is scoped to the repository list. As a result, repository filtering behaves predictably in the new UI.
This content is not included.PROJQUAY-11205. Previously, Red Hat Quay rejected RFC 9068 access tokens that use the at+jwt token type because is_jwt() did not recognize that typ value. As a result, authentication failed for clients that send standards-compliant access tokens.
With this release, Red Hat Quay accepts RFC 9068 access tokens with at+jwt token type. As a result, OIDC and OAuth clients that use these tokens can authenticate successfully.
This content is not included.PROJQUAY-11175. Previously, canceling an organization mirror sync generated a continuous stream of Organization mirror sync failed - Sync cancelled log messages.
With this release, canceled organization mirror jobs stop logging repeated failure messages. As a result, usage logs remain readable after mirror cancellation.
This content is not included.PROJQUAY-11162. Previously, Clair’s indexer could not clean up temporary files on filesystems that require O_TMPFILE support.
With this release, Clair indexing uses O_TMPFILE for temporary file cleanup where supported. As a result, vulnerability indexing runs reliably on supported storage backends.
This content is not included.PROJQUAY-10873. Previously, if a rejected securityContext override was applied to the mirror component on a QuayRegistry CR, mirror pods terminated and could not be recreated while the invalid override remained in the spec.
With this release, mirror deployments recover when unsupported securityContext overrides are removed or corrected. As a result, repository mirroring resumes after invalid security context changes.
This content is not included.PROJQUAY-7340. Previously, skopeo commands generated by Red Hat Quay included passwords in plain text in command output or logs.
With this release, credentials are handled without exposing passwords in skopeo command strings. As a result, mirror and copy operations do not leak secrets in logs.

1.3. RHBA-2026:0518 - Red Hat Quay 3.17.1 release

Issued 2026-04-08

Red Hat Quay release 3.17.1 is now available with Clair 4.9. The bug fixes that are included in the update are listed in the RHBA-2026:7096 advisory.

1.3.1. Red Hat Quay 3.17.1 bug fixes

There were no bug fixes for this release.

1.4. RHBA-2026:5684 - Red Hat Quay 3.17.0 release

Issued 2026-03-25

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

1.4.1. Red Hat Quay new features and enhancements

The following updates have been made to Red Hat Quay.

1.4.1.1. Splunk audit logs available in the Red Hat Quay UI

Previously, audit logs sent to Splunk could only be viewed on the Splunk UI. Now, when Splunk is configured as the log backend, you can view and query audit logs in the Red Hat Quay UI from Organizations, Repositories, and Superuser pages.

For more information, see Configuring action log storage for Splunk

1.4.1.2. Quay container image size optimization

The Red Hat Quay container image now uses Red Hat Universal Base Image (UBI) minimal 9.7 as the base layer, with build-time dependencies and caches removed from the final image. This change reduces image size by approximately 30%, shortens download and deployment times, and narrows the attack surface. The image remains a drop-in replacement for previous versions, and no configuration changes are required for upgrades to 3.17.3.

1.4.1.3. Container security hardening

Red Hat Quay 3.17 introduces enhanced security hardening that is enabled by default for all deployment types. To follow the principle of least privilege, Quay container images now operate with a minimal set of Linux capabilities, using a DROP ALL strategy and adding back only essential permissions, such as NET_BIND_SERVICE.

Additionally, this release provides a hardened seccomp profile for standalone Podman deployments, aligning their security posture with the RuntimeDefault protections found in OpenShift Container Platform. These changes significantly reduce the container attack surface without requiring manual configuration by the user.

1.4.1.4. Sparse manifest support for multi-architecture filtering

Red Hat Quay now accepts and serves sparse manifest lists where only a subset of referenced architectures such as x86_64 or arm64 are stored locally while the original manifest list digest is preserved. This is useful for disconnected OpenShift Container Platform environments where digest-based image references must remain valid. It also benefits high-availability and standalone Red Hat Quay deployments that mirror multi-arch images but need only a subset of architectures.

You can mirror only the architectures you need, like x86_64, via repository mirroring with an architecture filter, reducing storage and transfer by 50% or more for multi-arch images. A global configuration option enables sparse manifest acceptance and the UI shows which architectures are present for each tag.

For more information, see Mirroring images with Red Hat Quay.

1.4.1.5. Support for immutable tags

Red Hat Quay now supports immutable tags for organizations and organization-owned repositories. This feature allows users to protect specific image tags from being overwritten, deleted, or auto-pruned, ensuring stable references for builds and deployments. Immutability can be applied manually per tag, automated through regex-based policies, or triggered during the build process using the quay.immutable=true manifest label. For more information, see Immutable tags overview.

1.4.1.6. Support for ARM Architecture

Red Hat Quay 3.17 now supports the ARM architecture for both standalone deployments and Operator-based installations. This includes native ARM builds for all core components and the Quay Operator, enabling end-to-end management on ARM64 infrastructure.

1.4.2. Red Hat Quay configuration fields updates and changes

The following configuration fields have been added to Red Hat Quay 3.17.

1.4.2.1. Additional configuration fields for action log storage using Splunk

The following configuration options have been added when using Splunk to store Red Hat Quay usage logs.

Table 1.1. Additional Splunk configuration fields

Field	Type	Description
.search_timeout	Integer	Timeout, in seconds, for Splunk search queries. Increase for slow Splunk clusters or complex queries. Default: `60` Minimum: `5` Maximum: `300`
.max_results	Integer	Maximum number of results to return per search query. Larger values require more memory. Default: `10000` Minimum: `100` Maximum: `50000`
.export_batch_size	Integer	Batch size for log export operations. Default: `5000` Minimum: `100` Maximum: `10000`

Table 1.2. Additional Splunk HEC configuration fields

Field	Type	Description
.search_timeout	Integer	Timeout, in seconds, for Splunk search queries. Increase for slow Splunk clusters or complex queries. Default: `60` Minimum: `5` Maximum: `300`
.max_results	Integer	Maximum number of results to return per search query. Larger values require more memory. Default: `10000` Minimum: `100` Maximum: `50000`
.export_batch_size	Integer	Batch size for log export operations. Default: `5000` Minimum: `100` Maximum: `10000`
.search_host	String	Splunk management host for search API. Defaults to HEC host if not specified. Example: `splunk-mgmt.example.com`
.search_port	Integer	Splunk management port for search API. Default: `8089`
.search_token (Optional)	String	Bearer token for Splunk search API. Required because HEC tokens are ingest-only and cannot search. See Content from docs.splunk.com is not included.Manage HEC tokens for more information. Example: `splunk-mgmt.example.com`

1.4.2.2. LDAP caching configuration fields

The following configuration options have been added for deployments that use LDAP authentication. They control in-memory caching of LDAP permission checks for superuser and restricted user lookups, which can reduce load on the LDAP server.

Table 1.3. LDAP caching configuration fields

Field	Type	Description
FEATURE_LDAP_CACHING	Boolean	Whether to enable in-memory caching for LDAP permission check results (superuser, restricted user). Reduces LDAP server load. Default: `False`
LDAP_CACHE_TTL	Integer	Time-to-live, in seconds, for cached LDAP permission results. Default: `60`

LDAP caching example YAML

# ...
FEATURE_LDAP_CACHING: true
LDAP_CACHE_TTL: 10
# ...

1.4.2.3. Sparse manifest index configuration field

The following configuration options have been added to enable multi-architecture filtering.

Table 1.4. Multi-architecture filtering configuration fields

Field	Type	Description
FEATURE_SPARSE_INDEX	Boolean	Whether to allow sparse manifest indexes where not all architectures are required to be present. Default: False
REPO_MIRROR_MAX_MANIFEST_LIST_SIZE	Integer	Maximum size in bytes of manifest list JSON to parse during mirroring. Prevents DoS via oversized manifests. Default: `10485760` (10MB)
REPO_MIRROR_MAX_MANIFEST_ENTRIES	Integer	Maximum number of manifest entries to process during architecture-filtered mirroring. Prevents DoS via manifest lists with excessive entries. Default: `1000`

Multi-architecture filtering example YAML

# ...
FEATURE_SPARSE_INDEX: true
REPO_MIRROR_MAX_MANIFEST_LIST_SIZE: 10485760
REPO_MIRROR_MAX_MANIFEST_ENTRIES: 1000
# ...

1.4.2.4. Immutable tags configuration field

The following configuration option has been added to enable immutable tags.

Table 1.5. Immutable tags configuration field

Field	Type	Description
FEATURE_IMMUTABLE_TAGS	Boolean	Whether to enable immutability policies. Immutability can be set at the individual setting level and via a policy in the repository configuration by an administrator. Default: False

Immutable tags example YAML

# ...
FEATURE_IMMUTABLE_TAGS: true
# ...

1.4.2.5. Mirroring configuration fields for organizations

Mirroring in Red Hat Quay enables automatic synchronization of organizations 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.

Table 1.6. Mirroring configuration for an organization mirror

Field	Type	Description
FEATURE_ORG_MIRROR	Boolean	Enable or disable organization-level mirroring. Default: `False`
ORG_MIRROR_INTERVAL	Integer	Worker processing interval in seconds. Default: 30
ORG_MIRROR_BATCH_SIZE	Integer	Number of organization mirrors to process for each iteration. Default: 100
ORG_MIRROR_MAX_SYNC_DURATION	Integer	Maximum sync duration in seconds. Default: 3600
ORG_MIRROR_DEFAULT_SKOPEO_TIMEOUT	Integer	Default skopeo timeout in seconds. Default: 300
ORG_MIRROR_DISCOVERY_TIMEOUT	Integer	Discovery timeout in seconds. Default: 600
ORG_MIRROR_MAX_REPOS_PER_ORG	Integer	Maximum repositories to discover for each organization. Default: 10000
ORG_MIRROR_MAX_RETRIES	Integer	Maximum sync retries for a failure operation. Default: 3
SSRF_ALLOWED_HOSTS	List	Allowed hosts for the Server Side Request Forgery (SSRF) protection. Use optional field to allow specific hosts to be accessed by the registry.

Mirroring configuration example YAML

# ...
FEATURE_ORG_MIRROR: true
ORG_MIRROR_INTERVAL: 60
ORG_MIRROR_BATCH_SIZE: 100
ORG_MIRROR_MAX_SYNC_DURATION: 3600
ORG_MIRROR_DEFAULT_SKOPEO_TIMEOUT: 600
ORG_MIRROR_DISCOVERY_TIMEOUT: 600
ORG_MIRROR_MAX_REPOS_PER_ORG: 5000
ORG_MIRROR_MAX_RETRIES: 3
SSRF_ALLOWED_HOSTS:
    - harbor.example.lab
# ...

1.4.3. API endpoint enhancements

The following API endpoints were added in Red Hat Quay 3.17.

1.4.3.1. Manifest support API endpoint

New tag API parameters, getRegistryCapabilities and getManifestPullStatistics, has been added to the Red Hat Quay API. With this field, users can return information about supported registry features including sparse manifest support and required architectures.

Name	Description	Schema
getRegistryCapabilities	Returns information about supported registry features including sparse manifest support and required architectures.	object

See capabilities for more information, including example commands.

1.4.3.2. Organization mirroring API endpoints

New organization mirroring API endpoints have been added to the Red Hat Quay API. These endpoints allow users to manage organization-level mirroring configurations.

Name	Description	Schema
createOrgMirrorConfig	Create a new organization-level mirroring configuration.	object
getOrgMirrorConfig	Retrieve the organization-level mirroring configuration.	object
listOrgMirrorRepositories	List all repositories that are being mirrored in an organization.	object
syncOrgMirrorNow	Trigger an immediate sync of all repositories in an organization.	object
updateOrgMirrorConfig	Update the organization-level mirroring configuration.	object
verifyOrgMirrorConnection	Verify the connection to the external registry for an organization-level mirroring configuration.	object
cancelOrgMirrorSync	Cancel a pending sync of all repositories in an organization.	object
deleteOrgMirrorConfig	Delete an organization-level mirroring configuration.	object

See Chapter 23. org_mirror for more information, including example commands.

1.4.3.3. Immutability policy API endpoints

The following API endpoints were added in Red Hat Quay 3.17.

Name	Description	Schema
createOrgImmutabilityPolicy	Create an immutability policy for an organization.	object
createRepositoryImmutabilityPolicy	Create an immutability policy for a repository.	object
deleteOrgImmutabilityPolicy	Delete an immutability policy for an organization.	object
deleteRepositoryImmutabilityPolicy	Delete an immutability policy for a repository.	object
getOrgImmutabilityPolicy	Get an immutability policy for an organization.	object
getRepositoryImmutabilityPolicy	Get an immutability policy for a repository.	object
listOrgImmutabilityPolicies	List immutability policies for an organization.	object
listRepositoryImmutabilityPolicies	List immutability policies for a repository.	object
updateOrgImmutabilityPolicy	Update an immutability policy for an organization.	object
updateRepositoryImmutabilityPolicy	Update an immutability policy for a repository.	object

See Chapter 23. immutability_policy for more information, including example commands.

1.4.4. Known issues and limitations

The following sections note known issues and limitations for Red Hat Quay 3.17.

1.4.4.1. Repositories persist after filter changes

When an Organization-level mirror is configured, repositories that were previously discovered and mirrored are not automatically deleted if the repository_filters pattern is updated to exclude them.

While the excluded repositories stop syncing new data, they remain in the database as stale entries. This behavior differs from Repository-level mirroring, which automatically prunes obsolete tags when filters change. This may lead to repository accumulation and increased database overhead in large environments.

As a temporary workaround, users can delete the entire mirror configuration by using the DELETE /api/v1/organization/{orgname}/mirror API endpoint. Note that this can be disruptive and loses sync history and other metadata.

1.4.4.2. Status inconsistency between summary and dropdown in organization mirroring

When an organization mirror is initiated or canceled, the dashboard displays conflicting counts for task states. The Scheduled state in the header shoes a count, for example, 53 items, however when selecting Scheduled from the dropdown list it reports 0 items. This is a known issue and will be fixed in a future version of Red Hat Quay.

1.4.4.3. Tag pruning not supported in Organization-level mirroring

In the current implementation of Organization-level repository mirroring, Red Hat Quay does not replicate deletions from the source registry. If any of the following entities are removed or absent in the upstream source, they persist in the local Quay mirror:

Source namespaces or organizations and their repositories. If the entire upstream source namespace (for example, a Harbor project or Quay organization) is removed, all previously mirrored repositories and their content remain in the local mirror.
Individual repositories. Repositories previously discovered and synced continue to be tracked and served even if removed from the upstream source.
Image tags. Tags that existed at the time of the last sync persist in the mirror even if deleted upstream.
Referrers. OCI Referrers API artifacts, such as Cosign signatures and SBOMs are not currently mirrored. When present locally, they are not cleaned up automatically

The downstream mirror acts as a cumulative archive. If an upstream namespace is emptied or its repositories and tags are removed, the mirror continues to serve the last successfully synchronized versions of those objects. This might lead to higher storage consumption in the mirror than in the source.

Note

Note: This behavior differs from repository-level mirroring, which automatically removes local tags that are no longer present in the source registry.

Manual deletion via the Red Hat Quay UI or API is required to remove these entities from the mirror. A future release will introduce a configurable option to automatically delete absent items, including organizations, repositories, tags, referrers, and manifest list children from the local mirror.

1.4.5. Red Hat Quay bug fixes

The following issues were fixed with Red Hat Quay 3.17.

Note

Not all bug fixes included in the RHBA-2026:5684 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.

This content is not included.PROJQUAY-10609. Previously, the RHEL-9 image migration caused SHA-1 signing errors due to the deprecated RSA-SHA1 algorithm. Consequently, image pulls failed because of a cryptography policy change.
With this release, the system actively enables the SHA-1 algorithm in its crypto policy, resolving the issue with RHEL-9 image pulls.
This content is not included.PROJQUAY-10588. Previously, emails from users with lengths exceeding 64 characters were not migrated due to a length filter in the data migration. This led to end users receiving duplicate emails for organizations during migration, causing confusion and potential data inconsistencies.
This release adds an OrganizationContactEmail table and allows end users to manage multiple organization email contacts easily.
This content is not included.PROJQUAY-10575. Previously, there was an issue causing log failure when canceling repository mirroring. This issue has been resolved, and the mirroring operation no longer fails.
This content is not included.PROJQUAY-10609. Previously, image pulls were failing due to the deprecated RSA-SHA1 algorithm in the RHEL-9 image. With this release, the RHEL-9 cryptography policy has been updated, enabling SHA-1 for RSA signing. As a result, the SHA-1 algorithm is now supported, allowing image pulls without issues.
This content is not included.PROJQUAY-10273. Previously, users were unable to download the auth.json file, affecting the management of Robot Accounts. With this release, the option to download the auth.json file has been reintroduced to the new UI, enabling users to now view and download auth.json files for Robot Accounts.
This content is not included.PROJQUAY-9750. In previous versions, browser incompatibility led to inconsistencies in the design of the calendar pop-up, specifically for service key and repository mirror configuration. This inconsistency was noticeable across browsers, with hour and minute options missing in Mozilla Firefox and Safari.
In this release, the calendar pop-up in the Quay UI has been standardized, ensuring consistency across browsers, including hour and minute options. As a result, the calendar pop-up is now uniform across browsers.
This content is not included.PROJQUAY-9729. Previously, attempting to run automated tests after merging downstream builds without updating downstream documentation used UBI (Universal Base Image) minimal adoption, resulted in an image size increase due to failed Continuous Integration (CI).
This update resolves the issue, leading to a smaller image size and reduced Common Vulnerabilities and Exposures (CVE) surface, thereby enhancing overall system security and performance.
This content is not included.PROJQUAY-7025. Previously, the web UI update led to incomplete link display for foreign organizations and repositories for superusers, resulting in incomplete superuser access. This caused missing links and log retrieval errors.
This issue has been resolved, enabling superusers to access all links in foreign organizations and repositories.
This content is not included.PROJQUAY-6934. Previously, the user interface previously displayed inappropriate error messages when configured with the Splunk LOGS_MODEL parameter. These messages caused confusion for users when working with Splunk.
With this release, the user interface shows accurate error messages for Splunk logs. This improvement results in the correct display of the Method not implemented, Splunk does not support log searches` message.

1.4.6. Red Hat Quay feature tracker

New features have been added to Red Hat Quay, some of which are currently in Technology Preview. Technology Preview features are experimental features and are not intended for production use.

Some features available in previous releases have been deprecated or removed. Deprecated functionality is still included in Red Hat 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 Red Hat 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 1.7. Features tracker

Feature	Quay 3.17	Quay 3.16	Quay 3.15
Sparse manifest support for multi-architecture filtering	General Availability	-	-
Immutable tags overview	General Availability	-	-
Proof Key for Code Exchange support for OIDC	General Availability	General Availability	-
v1 UI	Deprecated	Deprecated	Deprecated
FEATURE_UI_V2	General Availability	General Availability	Technology Preview

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

Table 1.8. 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

Legal Notice

Except as otherwise noted below, the text of and illustrations in this documentation are licensed by Red Hat under the Creative Commons Attribution–Share Alike 3.0 Unported license . If you distribute this document or an adaptation of it, you must provide the URL for the original version.

Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, the Red Hat logo, JBoss, Hibernate, and RHCE are trademarks or registered trademarks of Red Hat, LLC. or its subsidiaries in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

XFS is a trademark or registered trademark of Hewlett Packard Enterprise Development LP or its subsidiaries in the United States and other countries.

The OpenStack® Word Mark and OpenStack logo are trademarks or registered trademarks of the Linux Foundation, used under license.

All other trademarks are the property of their respective owners.