Chapter 1. Red Hat Quay overview


Red Hat Quay is a distributed, highly available container image registry for the enterprise. You can use this guide to learn architectural patterns, sizing guidance, and best practices for deploying Red Hat Quay with high availability.

Red Hat Quay container registry platform provides secure storage, distribution, access controls, geo-replications, repository mirroring, and governance of containers and cloud-native artifacts on any infrastructure. It is available as a standalone component or as an Operator for OpenShift Container Platform, and is deployable on-prem or on a public cloud.

Quay features

1.1. Scalability and high availability (HA)

Red Hat Quay uses the same codebase as Quay.io, Red Hat’s highly available container image registry. You can deploy at scale with high availability on-prem or in the cloud, with multitenant operation supported.

The code base used for Red Hat Quay is the same as the code base used for Quay.io, which is the highly available container image registry hosted by Red Hat. Quay.io and Red Hat Quay offer a multitenant SaaS solution. As a result, users can be confident that their deployment can deliver at scale with high availability, whether their deployment is on-prem or on a public cloud.

1.2. Content distribution

Red Hat Quay content distribution covers repository mirroring, geo-replication, and disconnected or air-gapped deployment. You can sync images from other registries, present multiple geo-distributed deployments as one registry, or run in air-gapped environments.

Repository mirroring
Red Hat Quay repository mirroring lets you mirror images from Red Hat Quay and other container registries, like JFrog Artifactory, Harbor, or Sonatype Nexus Repository, into your Red Hat Quay cluster. Using repository mirroring, you can synchronize images to Red Hat Quay based on repository names and tags.
Geo-replication
Red Hat Quay geo-replication allows multiple, geographically distributed Red Hat Quay deployments to work as a single registry from the perspective of a client or user. It significantly improves push and pull performance in a globally-distributed Red Hat Quay setup. Image data is asynchronously replicated in the background with transparent failover and redirection for clients.
Deployment in disconnected or air-gapped environments

Red Hat Quay is deployable in a disconnected environment in one of two ways:

  • Red Hat Quay and Clair connected to the internet, with an air-gapped OpenShift Container Platform cluster accessing the Red Hat Quay registry through an explicit, allowlisted hole in the firewall.
  • Using two independent Red Hat Quay and Clair installations. One installation is connected to the internet and another within a disconnected, or firewalled, environment. Image and vulnerability data is manually transferred from the connected environment to the disconnected environment using offline media.

1.3. Build automation

Red Hat Quay build automation builds Dockerfiles on worker nodes on OpenShift Container Platform or Kubernetes. You can configure build triggers such as GitHub webhooks to build new image versions when code is committed.

1.4. Red Hat Quay enhanced build architecture

Red Hat Quay enhanced build architecture uses a build manager that creates Job objects and unprivileged pods running the quay-builder image. The build manager coordinates status and image builds through the quay-builder binary and Podman inside each pod.

The following image shows the expected design flow and architecture of the enhanced build features:

Enhanced Quay builds architecture

With this enhancement, the build manager first creates the Job Object. Then, the Job Object then creates a pod using the quay-builder-image. The quay-builder-image contains the quay-builder binary and the Podman service. The created pod runs as unprivileged. The quay-builder binary then builds the image while communicating status and retrieving build information from the Build Manager.

1.5. Integration

Red Hat Quay integrates with Git-compatible systems such as GitHub, GitLab, and Bitbucket and provides a full OAuth 2 REST API. You can configure continuous builds from your repositories and manage Red Hat Quay through the API.

1.5.1. REST API

Red Hat Quay provides a full OAuth 2, RESTful API. RESTful API offers the following benefits:

  • Availability from endpoints of each Red Hat Quay instance from the URL, for example, https://quay-server.example.com/api/v1
  • Allow users to connect to endpoints through a browser, to GET, DELETE, POST, and PUT Red Hat Quay settings provided by a discovery endpoint that is usable by Swagger.
  • The API can be invoked by the URL, for example, https://quay-server.example.com/api/v1, and uses JSON objects as payload.

1.6. Security

Red Hat Quay security includes vulnerability scanning with Clair, TLS configuration, isolated builds, and role-based access by organization and team. You can configure encryption, HTTPS, and fine-grained read, write, and administrative access.

1.6.1. TLS/SSL configuration

You can configure SSL/TLS for the Red Hat Quay registry in the configuration tool UI or in the configuration bundle. SSL/TLS connections to the database, to image storage, and to Redis can also be specified through the configuration tool.

Sensitive fields in the database and at run time are automatically encrypted. You can also require HTTPS and verify certificates for the Red Hat Quay registry during mirror operations.

1.6.2. Clair

Clair is an open source application that leverages static code analyses for parsing image content and reporting vulnerabilities affecting the content. Clair is packaged with Red Hat Quay and can be used in both standalone and Operator deployments. It can be run in highly scalable configurations, where components can be scaled separately as appropriate for enterprise environments.

1.6.3. Red Hat Quay Operator security

When Red Hat Quay is deployed using the Red Hat Quay Operator, the tls component is set to managed by default and the OpenShift Container Platform’s Certificate Authority is used to create HTTPS endpoints and to rotate TLS certificates.

If you set the tls component to unmanaged, you can provide custom certificates to the pass-through Routes, however you are responsible for certificate rotation.

1.6.4. Fully isolated builds

Red Hat Quay now supports building Dockerfiles that uses both bare metal and virtual builders.

By using bare-metal worker nodes, each build is done in an ephemeral virtual machine to ensure isolation and security while the build is running. This provides the best protection against rogue payloads.

Running builds directly in a container does not have the same isolation as when using virtual machines, but it still provides good protection.

1.6.5. Role-based access controls

Red Hat Quay provides full isolation of registry content by organization and team with fine-grained entitlements for read, write, and administrative access by users and automated tools.

1.7. Recently added features

Red Hat Quay release notes list the latest features, enhancements, deprecations, and known issues. You can use them to track current product capabilities and changes.

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat Documentation

Legal Notice

Theme

© 2026 Red Hat
Back to top