Red Hat Quay is an enterprise-grade, highly scalable container image registry.
While OpenShift comes with a built-in internal registry designed specifically for basic, local image management, Red Hat Quay is built for production-scale, multi-cluster, and secure image workflows across the entire enterprise.
1. Internal OpenShift Registry vs. Red Hat Quay
It is common to wonder why you would need Quay if OpenShift already has an integrated registry. Here is how they compare:
| Feature | Internal OpenShift Registry | Red Hat Quay |
| Scope | Bound to a single OCP cluster. | Global. Can serve multiple OCP and non-OCP clusters. |
| Primary Use Case | Build-to-deploy pipelines inside the cluster. | Central enterprise source of truth, geo-replication. |
| Security Scanning | Minimal (basic integration). | Advanced (Clair integration for deep vulnerability scanning). |
| Content Types | Container images only. | Container images, Helm charts, and arbitrary OCI artifacts. |
| High Availability | Simple pod replicas on shared storage. | High-capacity geo-replication with active-active clustering. |
2. Red Hat Quay Architecture & Components
Quay is a modular application that scales horizontally. When deployed on OpenShift via the Red Hat Quay Operator, it manages several key services:
- Quay Registry (App Layer): The stateless container engine that handles pull/push API requests. It can be scaled up dynamically to meet high traffic demand.
- Database: A persistent database (like PostgreSQL) that stores the registry metadata, user accounts, and image tags (the image filesystem layers themselves are stored separately in object storage).
- Redis: A fast in-memory cache used to handle live build logs, user session tracking, and transit registry configurations.
- Clair (Vulnerability Scanner): An integrated API utility that continuously scans container layers against national vulnerability databases (CVEs) as images are pushed.
- Storage Backend: Quay abstracts the physical storage layer, integrating natively with S3-compatible object storage (AWS S3, Azure Blob, Google Cloud Storage, or Red Hat OpenShift Data Foundation).
3. Key Enterprise Features
Active-Active Geo-Replication
If you run multiple OpenShift clusters globally (e.g., one in North America and one in Europe), developers pushing to a single central registry can cause extreme latency. Quay supports active-active geo-replication.
If a developer pushes an image to the North American registry, Quay automatically replicates the image metadata and filesystem blocks to the European storage target in the background. European worker nodes can then pull the image locally at gigabit speeds.
Automatic Image Pruning
Over time, continuous deployment pipelines push thousands of development images, creating massive storage costs. Quay allows administrators to set auto-pruning policies at the organization or repository level (e.g., “automatically delete any image tag older than 30 days” or “only keep the 10 most recent tags”).
4. OpenShift Integration: The Quay Bridge Operator
To make Quay feel like a native part of your OpenShift developer experience, Red Hat provides the Quay Bridge Operator.
This bridge creates an automated synchronization loop between the two platforms:
- Automated Pull Secrets: When a developer creates a new namespace in OpenShift, the Quay Bridge Operator automatically provisions the required credentials and pull secrets into that namespace, giving the local pods instant, authorized access to secure private Quay repositories.
- In-Console Vulnerability Reporting: When Clair scans an image and finds a security flaw, the Quay Bridge Operator surfaces that security status directly inside the OpenShift Web Developer Console. System administrators can immediately see if a running pod is using an insecure or vulnerable container image.