Project Quay navigation

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.

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.

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.

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.

PROJQUAY-10575. Previously, canceling repository mirroring produced incomplete or null log messages.

PROJQUAY-10798. Previously, canceling an organization mirror sync could generate an endless stream of Organization mirror sync failed - Sync cancelled log messages.

PROJQUAY-11382. Previously, deleting an organization mirror configuration left mirrored repositories stuck in the ORG_MIRROR state, which blocked pushes to those repositories.

PROJQUAY-11891. Previously, you could not delete an organization that was configured for organization mirroring because of a database error.

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.

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.

PROJQUAY-11478. Previously, the new UI blocked creating a proxy cache configuration even when organization mirroring was not enabled in config.yaml.

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.

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.

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.

PROJQUAY-11637. Previously, lazy loading of OCI indexes failed when the index included Docker v2 schema 2 images, which the OCI specification allows.

PROJQUAY-10934. Previously, repository cache entries were not invalidated when a repository was deleted, which could leave stale cache data.

PROJQUAY-11288. Previously, nginx returned HTTP 404 instead of 502 when the backend was unavailable because a custom 502 error page was missing.

PROJQUAY-11331. Previously, a malformed struct tag on DistributedStorageArgs.Signature in the config tool broke storage configuration serialization.

PROJQUAY-11486. Previously, the configuration validator did not properly validate S3 URLs.

PROJQUAY-11524. Previously, a race condition during initial database setup could cause intermittent startup failures.

PROJQUAY-11851. Previously, an RBAC denial on apiservers.config.openshift.io could block the entire Project Quay Operator deployment on OpenShift Container Platform.

PROJQUAY-11852. Previously, the Operator could panic when processing an invalid configuration.

PROJQUAY-11501. Previously, the Operator rejected PULL_METRICS_REDIS in the config bundle secret when Redis was Operator-managed after the config-tool migration.

PROJQUAY-11549. Previously, external TLS secretRef configuration did not validate that the certificate matched 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.

PROJQUAY-9157. Previously, pods could fail with MountVolume.SetUp failed for volume "config" in some configuration mount scenarios.

PROJQUAY-12230. Previously, quota warning and error notifications failed with TypeError: Decimal is not JSON serializable, so quota notifications were silently dropped.

PROJQUAY-12233. Previously, global readonly superusers were blocked from reading organization namespace notification GET endpoints when FEATURE_SUPERUSERS_FULL_ACCESS was enabled.

PROJQUAY-11678. Previously, the Superuser Build Logs page in the new UI returned HTTP 500 because of a logic error in BuildTrigger.to_dict().

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.

PROJQUAY-11158. Previously, the Auto-Prune Policies tab was missing for user namespace organizations in the UI.

PROJQUAY-9695. Previously, the log rotate worker stopped working after upgrading to Project Quay 3.15.

PROJQUAY-12197. Previously, Clair could fail to pull the upstream vulnerability database, which prevented vulnerability reports for scanned images.

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.

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.

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.

PROJQUAY-10605. Previously, the Repository field in usage logs duplicated namespace information.

PROJQUAY-10795. Previously, the Load More Logs button flashed repeatedly while usage logs were loading.

PROJQUAY-11079. Previously, the change_tag_immutability action was missing from the usage logs chart in the new UI.

PROJQUAY-11025. Previously, the organization mirror Schedule or Pending state in the UI did not stay consistent with the related dropdown controls.

PROJQUAY-11217. Previously, searching for a repository that did not exist left a circular loading spinner on the page indefinitely.

PROJQUAY-11218. Previously, selecting a permission in the permissions dropdown in Firefox navigated to a temporary site unavailable page.

PROJQUAY-11219. Previously, text entered in the repository filter could appear in unrelated places in the UI.

PROJQUAY-11257. Previously, the branding logo on the new UI login page could be invisible.

PROJQUAY-12151. Previously, wizard panels could overflow their modal windows when creating a robot account, team, or build trigger.

PROJQUAY-9246. Previously, the new UI did not allow selecting all OAuth applications in bulk.

PROJQUAY-9256. Previously, you could not clear the default Skopeo timeout interval value and enter a new value in the UI.

PROJQUAY-9883. Previously, the filter on the Superuser Service Keys panel did not work.

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.

PROJQUAY-5075. Previously, startup validation could fail when a non-preferred storage engine was unavailable, even if the preferred storage engine was healthy.

PROJQUAY-10845. Previously, Project Quay could send non-image artifacts for vulnerability scanning.

PROJQUAY-11433. Previously, repository UPDATE queries during namespace deletion could take many seconds and slow large deletions.

PROJQUAY-11691. Previously, needless permission checks slowed critical UI API paths. On LDAP-backed installations this could delay or prevent the UI from loading.

PROJQUAY-9668. Previously, excessive LDAP queries during login could cause timeouts and prevent users from signing in.

PROJQUAY-10426. Previously, Project Quay executed an excessive number of LDAP binds against an empty registry during initial login and username confirmation.

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.

PROJQUAY-10625. Previously, automatic redirects for repository and organization URLs worked in UI v1 but failed in UI v2.

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.

PROJQUAY-11235. Previously, the Generate Access Token page called external CDN resources and Google Fonts, which delayed the page in air-gapped environments.

PROJQUAY-11375. Previously, the Operator continuously recreated the calculated config secret about once per minute even when configuration had not changed.

PROJQUAY-1920. Previously, a config-tool OIDC validation bug could prevent the registry from starting when a custom OIDC provider was configured.

Automated deployment and management of Project Quay with customization options

Management of Project Quay and all of its dependencies

Automated scaling and updates

Integration with existing OpenShift Container Platform processes like GitOps, monitoring, alerting, logging

Provision of object storage with limited availability, backed by the multi-cloud object gateway (NooBaa), as part of the Red Hat OpenShift Data Foundation (ODF) Operator. This service does not require an additional subscription.

Scaled-out, high availability object storage provided by the ODF Operator. This service requires an additional subscription.

Simplified deployment: Simplified deployment of Project Quay and associated components means that you can start using the product immediately

Scalability: Use cluster compute capacity to manage demand through automated scaling, based on actual load

Simplified Networking: Automated provisioning of load balancers and traffic ingress secured through HTTPS using OpenShift Container Platform TLS certificates and Routes

Declarative configuration management: Configurations stored in CustomResource objects for GitOps-friendly lifecycle management

Repeatability: Consistency regardless of the number of replicas of Project Quay and Clair

OpenShift integration: Additional services to use OpenShift Container Platform Monitoring and Alerting facilities to manage multiple Project Quay deployments on a single cluster

QuotaRepositorySize

QuotaNameSpaceSize

QuotaRegistrySize

For a soft check, users are notified.

For a hard check, the push is stopped.

Continuous integration

Public repositories

Robot accounts

Teams

SSL/TLS encryption

Logging and auditing

Invoice history

You cannot have an organization embedded within another organization. To subdivide an organization, you use teams.

Organizations cannot contain users directly. You must first add a team, and then add one or more users to each team.

Teams can be set up in organizations as just members who use the repositories and associated images, or as administrators with special privileges for managing the Organization.

Credentials are generated for the Robot Account.

Repositories and images that the Robot Account can push and pull images from are identified.

Generated credentials can be copied and pasted to use with different container clients, such as Docker, Podman, Kubernetes, Mesos, and so on, to access each defined repository.

Data synchronization. Clair can periodically synchronize its vulnerability database with the NVD. This ensures that it has the latest vulnerability data.

Matching and enrichment. Clair compares the metadata and identifiers of vulnerabilities it discovers in container images with the data from the NVD. This process involves matching the unique identifiers, such as Common Vulnerabilities and Exposures (CVE) IDs, to the entries in the NVD. When a match is found, Clair can enrich its vulnerability information with additional details from NVD, such as severity scores, descriptions, and references.

Severity scores. The NVD assigns severity scores to vulnerabilities, such as the Common Vulnerability Scoring System (CVSS) score, to indicate the potential impact and risk associated with each vulnerability. By incorporating NVD severity scores, Clair can provide more context on the seriousness of the vulnerabilities it detects.

Vulnerability prioritization. By using CVSS scores, you can prioritize vulnerabilities based on their severity and address the most critical issues first.

Assess risk. CVSS scores can help you understand the potential risk a vulnerability poses to your containerized applications.

Communicate severity. CVSS scores provide a standardized way to communicate the severity of vulnerabilities across teams and organizations.

Inform remediation strategies. CVSS enrichment data can guide Quay.io users in developing appropriate remediation strategies.

Compliance and reporting. Integrating CVSS data into reports generated by Clair can help organizations demonstrate their commitment to addressing security vulnerabilities and complying with industry standards and regulations.

You have created a Quay.io account.

You have created a Red Hat account and a Quay.io account. For more information, see "Creating a Quay.io account".

Current Plan. This section denotes the current plan Quay.io plan that you are signed up for. It also shows the amount of private repositories you have.

Invoices. If you are on a paid plan, you can click View Invoices to view a list of invoices.

Receipts. If you are on a paid plan, you can select whether to have receipts for payment emailed to you, another user, or to opt out of receipts altogether.

You have logged in to Project Quay as an administrator.

You have created an organization.

You have access to the Project Quay API, which entails having already created an OAuth 2 access token.

Create a user application by entering the POST /api/v1/user/apptoken API call:

$ curl -X POST \
  -H "Authorization: Bearer <access_token>" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "MyAppToken"
  }' \
  "http://quay-server.example.com/api/v1/user/apptoken"

On the Project Quay UI, click your username in the navigation pane → Account Settings. The name of your application appears under the Docker CLI and other Application Tokens heading. For example:

Ceph/Rados RGW

OpenStack Swift

Red Hat OpenShift Data Foundation 4 (through NooBaa)

Amazon Web Services (AWS) S3

Google Cloud Storage

Azure Blob Storage

Hitachi Content Platform (HCP)

You can deploy any number of pods, such as Quay, Clair, Builder, and so on.

Project Quay pods can run in multiple data centers or availability zones.

Storage and database backends can be deployed across multiple data centers or availability zones, but only as a single, shared storage backend and single, shared database backend.

Project Quay can manage content for an unlimited number of clusters or standalone servers.

Clients can access the Project Quay deployment regardless of their physical location.

You can deploy Project Quay on OpenShift Container Platform infrastructure nodes to minimize subscription requirements.

You can run the Container Security Operator (CSO) and the Quay Bridge Operator (QBO) on your OpenShift Container Platform clusters at no additional cost.

configBundleSecret: The name of a Kubernetes Secret containing the config.yaml file which defines additional configuration parameters.

name: The name of your Project Quay registry.

namespace: The namespace, or project, in which the registry was created.

spec.components: A list of components that the Operator automatically manages. Each component entry includes the following fields:

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

Mirroring workers can run on nodes that already run Project Quay.

Mirroring runs in scheduled batches. More workers allow more repositories to sync at the same time. For example, 10 workers can run 10 mirroring operations in parallel.

Size workers based on how many repositories you need to mirror in parallel, how many images and tags those repositories contain, and how often content changes.

Multiple tags in the same repository cannot be mirrored in parallel.

When geo-replication is configured, container image pushes are written to the preferred storage engine for that Project Quay instance. This is typically the nearest storage backend within the region.

After the initial push, image data is replicated in the background to other storage engines.

The list of replication locations is configurable and those can be different storage backends.

An image pull always uses the closest available storage engine to maximize pull performance.

If replication has not been completed yet, the pull uses the source storage backend instead.

OpenShift ingress must support HTTP/2 for the gRPC protocol used by the build manager.

The build manager needs the build cluster CA certificate in the Project Quay configuration so workers can establish a secure connection.

Build jobs must resolve the build manager hostname. Custom subdomains require DNS that points to the OpenShift router.

Using a naming service. If you want your deployment to survive container restarts, which typically result in changed IP addresses, you can implement a naming service. For example, the dnsname plugin allows containers to resolve each other by name.

Using the host network. You can use the podman run command with the --net=host option and then use container ports on the host when specifying the addresses in the configuration. This option is susceptible to port conflicts when two containers want to use the same port. This method is not recommended.

Configuring port mapping. You can use port mappings to expose ports on the host and then use these ports in combination with the host IP address or host name.