Red Hat Quay 3.10 is generally available

As of today, Red Hat Quay 3.10 is generally available! This release brings improved security, convenience and efficiency to Quay’s workflow. We are also excited to announce that this is the first instance of a Red Hat Quay release that is aligned with the lifecycle of Red Hat OpenShift. This prolongs support for Quay and will help streamline updates and user functionality across Red Hat products. The lifecycle information and support phase dates can always be viewed on the Red Hat Quay Lifecycle Policy page.

Improved productivity with automated image lifecycles

Quay development is guided by your feedback. We have heard your requests and are introducing a new feature that has been a top request from our customers: Automated pruning of image tags.

Auto-pruning is a critical function that happens automatically in the background. Customers will be able to choose between two policies: automatically deleting tags that have been stored in the registry beyond a set amount of time, or automatically deleting tags if the number of tags in a repository exceeds a certain limit, starting with oldest tags first.

Here are some of the key benefits that auto-pruning brings to Quay 3.10:

• Optimized storage usage: Automatically removes old and unused images to save disk space and costs. Customers aren't paying to store stale artifacts.
• Enhanced security: Deletes old images that are accumulating vulnerabilities as they age, to improve system security posture. No more pulling images with known common vulnerabilities and exposures.
• Improved productivity: Less time wasted manually cleaning up old tags and images. Automation saves engineering hours.
• User-centric control: Custom policies allow pruning images on customers' terms. Align auto-pruning with your workflow, for instance, when integrating CI/CD pipelines with Quay.
• Reliability: In combination with storage quota, rules ensure repositories don't exceed size or tag limits over time. No more managing storage piecemeal.

See a demo of how it works here! This feature streamlines Quay’s storage use by automatically removing unused images and helping you maintain a leaner and more efficient repository. In Red Hat Quay 3.10, the pruning policies will be defined at the organization level, which means all repositories inside the organization are subject to them. For more nuanced control, in the next release we plan to introduce repository-level pruning policies that can be used instead of, or combined with, policies defined in the parent organization.

Increased flexibility on new platforms

With Red Hat Quay 3.10, deployment on Red Hat Enterprise Linux (RHEL) and OpenShift running on IBM Z mainframe and POWER is supported. Red Hat and IBM worked together to enable this exciting new option for customers that have standardized their critical infrastructure on either of those platforms.

An exception to this is the mirror registry for OpenShift, which enables every OpenShift cluster to bootstrap a registry to host the image mirror for the OpenShift core images and operator catalog contents. This component is expected to be available on IBM Z mainframe and POWER early next year.

Functionally, there will be no difference to Quay running on x86-based OpenShift or RHEL setups. This includes the various operators for Quay and Clair as the static vulnerability analysis engine.

See the IBM blogs for IBM Power and IBM Z mainframe for more information.

A new look for Red Hat Quay

Quay began rolling out a significant redesign of its user interface (UI) in the 3.9 release to provide a more modern, intuitive and visually-appealing experience. In 3.10, we are continuing to update the preview of the UI with new capabilities. Critical features like tag management, account settings, teams and permissions have been overhauled with a new PatternFly-based design.

Furthermore, the new user interface aims to simplify working with large sets of content at scale when performing operations in the UI. When administrators want to assign permissions for a large number of repositories to a user or robot account, they can now do that with a single click.

The new UI also makes team management easier with permission and membership assignment.   Step-by-step dialogues streamline the initial creation of new teams or robot accounts including initial permission assignments to repositories. Using specifically designed modals, all team and robot settings can be updated in-place later.

To automate permission assignment inside organizations, the new UI now covers the management of default permissions. This functionality automates permission management by giving certain users pre-defined permissions on any new repository created.

To try out the preview, Quay administrators can simply set the configuration flag FEATURE_UI_V2 to true.

Additional changes 

As with every Quay release, there are lots of bug fixes and smaller improvements that go into the product, but there are two other changes worth calling out specifically:

• You can now disable the usage of robot accounts registry-wide with the configuration directive “ROBOTS_DISALLOW” set to true. This will prevent anyone in the system from creating or using robot tokens except for organizations (to still use repository mirroring an additional config tunable will be made available in a future patch release of 3.10).
• The graphical configuration editor will no longer be rolled out for OpenShift-based Quay deployments via the operator in favor of GitOps-managed deployments. This also has been unmaintained for some time and lags behind the new set of feature toggles in the Quay configuration. It is still part of the Quay container image and can be used to pre-create a Quay configuration locally, but it is considered deprecated as of Quay 3.10.
• Users integrating Quay with a corporate LDAP directory can now customize the attribute used to determine group membership instead of the default memberOf.

A look ahead

In our planned future for Quay, we are looking to continue to evolve and adopt several new enterprise features:

• Functional parity in the new UI by adding support for pull-through caching, quota management and the superuser panel, at which point it will become the default
• Net-new functionality in the new UI for managing geo-replication
• More granular pruning policies at the repository level
• OpenID Connect (OIDC) group support for the team concept in Quay organizations
• Support for sparse manifest lists (multi-arch images filtered for certain compute types with stable digests)