On this page
SBB Red Hat Quay
Service Information
Red Hat Quay is the selected Solution Building Block for the DC 3.0 registry capability. Selected means the product/SBB mapping is ADR-backed; the service still needs onboarding evidence before it can move to active. adr-005-datacenter-services-baseline selects it as the Datacenter Services registry implementation, while adr-011-connected-vs-disconnected defines the restricted-network baseline that Quay must support.
The service model is tiered. A main ACM-governed seed Quay tier curates approved upstream and platform content for the fleet. The AM1 and AM4 Datacenter Services clusters each have a DCS-internal platform Quay instance for OpenShift lifecycle content, marketplace/operator content, platform mirrors, and managed cluster pull paths. Application teams use one shared tenant-facing Quay service endpoint per datacenter for HCP tenant CI/CD push and workload pull paths, so tenant traffic is not direct exposure of DCS-internal registry services. Dedicated tenant-owned Quay instances are exception patterns, not the default service catalog item.
| Item | Information |
|---|---|
| Solution architect | Thomas Commandeur. |
| CMDB number | Assigned during service onboarding. |
| Service Level Agreement | Baseline Datacenter Services platform SLA; concrete response and recovery objectives are recorded in the service onboarding record before active service state. |
| 1st and 2nd line support group | Datacenter Services platform operations service desk model, with queue and escalation paths recorded during onboarding. |
| 3rd line support group | Platform Engineering with Red Hat support escalation. |
| Support response times | Aligned to the Datacenter Services platform SLA once approved. |
| Managing party | Datacenters. |
| Contact person | Thomas Commandeur. |
Activation gates before active service state: CMDB registration, service level publication, support group assignment, backup/restore evidence, monitored dependency health, tenant onboarding workflow, main-to-DCS synchronization runbook, tenant-facing cross-datacenter synchronization runbook, and registry trust-control runbook.
Cost and Responsibilities
Cost and responsibility allocation follows the shared platform-service model. The service must expose enough usage signals to allocate storage, traffic, tenant, and lifecycle cost where the platform operating model requires showback or chargeback.
Cost
| Description | Unit | Price |
|---|---|---|
| Quay application runtime | OpenShift compute and platform overhead | Priced through platform service capacity model. |
| Blob storage | Object-storage capacity and request volume | Priced through the selected object-storage service. |
| Metadata services | PostgreSQL, Redis, backup, and monitoring capacity | Priced through shared Datacenter Services dependencies. |
| Tier synchronization | Mirror worker capacity, network transfer, selected tenant image copies, and local cache footprint | Priced through platform service capacity and traffic model. |
| Red Hat subscription | Quay entitlement and support | Confirmed through procurement and subscription management. |
Additional Specifications
- Cost attribution must distinguish mirrored platform content, tenant-facing workload images, OCI artifacts, and retention/garbage-collection classes.
- Capacity reporting must include object-storage growth, manifest count, repository count, pull/push traffic, mirror cadence, and scan backlog.
- Service onboarding must define retention classes for platform mirrors, tenant repositories, and release-promotion repositories.
- Capacity reporting must distinguish main seed content, DCS-internal platform mirrors, tenant-facing repositories, and selected cross-datacenter mirror copies.
- Tenant-facing Quay capacity covers tenant workload images, tenant OCI artifacts, and selected cross-datacenter tenant mirror copies; it does not include duplicated platform mirror catalogs.
Responsibilities
The managing and consuming parties share responsibility for a trusted image path. Platform teams operate the registry service and enforce paved-road controls; consuming teams own the artifacts they publish and the evidence required for deployment.
Managing Party
Datacenters is the managing organizational domain for the service. Platform Architecture and Platform Operations own the Red Hat Quay technical baseline, Operator lifecycle, main seed registry endpoint, DCS-internal platform registry endpoints, tenant-facing registry endpoints, tenant onboarding workflow, mirroring policy, monitoring, backup and restore evidence, and integration contracts with identity, storage, network, and security services.
Consuming Party
Consumers own image provenance, repository hygiene, retention alignment, correct robot-account use, and release evidence for images and artifacts they publish into the tenant-facing Quay endpoint assigned to their service or datacenter locality.
Roadmap and Lifecycle
Lifecycle
| Version | Delivery start date | Delivery end date | Extended support candidate |
|---|---|---|---|
| DC 3.0 selected baseline | 2026-06-22 | Service onboarding gate | Assessed during platform service review. |
Roadmap
| Development status | Plan | Functionality |
|---|---|---|
| Selected | Complete service onboarding and ownership model | CMDB entry, support groups, service levels, cost model, and runbook ownership. |
| Target implementation | Deploy Operator-managed main ACM-governed seed Quay | Approved upstream intake, mirror catalog ownership, OIDC, TLS, ODF-backed object storage, PostgreSQL, Redis, Clair, and fleet seeding. |
| Target implementation | Deploy DCS-internal platform Quay in AM1 and AM4 | Local cluster pull endpoint, local platform mirrors, marketplace/operator content, and local backup/restore evidence for platform lifecycle content. |
| Target implementation | Deploy one tenant-facing Quay service endpoint per datacenter | Shared tenant organizations, CI/CD publishing path, HCP workload pull path, selected cross-datacenter mirroring, and tenant-facing backup/restore evidence. |
| Target implementation | Publish controlled mirror catalog | Red Hat platform content, operator catalogs, OpenShift lifecycle content, Quay dependencies, approved third-party sources, main-to-DCS synchronization scope, and tenant-facing synchronization scope with owners and retention classes. |
| Target integration | Define trusted artifact gates | Signing, SBOM, vulnerability visibility, promotion evidence, and admission integration through the adjacent release-governance control plane. |
| Future option | Assess geo-replication or air-gapped transfer pattern | Separate DR or isolation decision with explicit database, cache, object storage, and load-balancing design. |
Architecture
Application functions:
| ABB | Functionality |
|---|---|
| registry | Provides governed OCI registry, mirrored content distribution, tenant repositories, artifact storage, access control, vulnerability visibility, and registry evidence for platform and workload delivery. |
Dependencies:
| SBB or ABB | Dependency description |
|---|---|
| clusters-as-a-service | Hosts platform-managed Quay instances on Datacenter Services or hub platform runtime where selected by service design. |
| block-file-s3-storage | Provides an S3-compatible durable object-storage backend for image and artifact blobs. |
| federated-authentication via keycloak | Provides OIDC-based human authentication and optional robot-account federation. |
| public-key-infrastructure via cert-manager | Provides TLS certificate lifecycle for registry and backend connections where applicable. |
| backup-and-disaster-recovery | Protects Quay configuration, PostgreSQL metadata, and object-storage blobs. |
| security-operations-center | Consumes registry logs, metrics, vulnerability evidence, and alert signals. |
Technical Architecture
The target design is Operator-managed Red Hat Quay on OpenShift, deployed as a main seed tier, DCS-internal platform tiers, and tenant-facing service tiers. Quay is the controlled registry boundary between upstream sources, platform automation, tenant publishing, and OpenShift consumers.
Core components:
- Quay Operator: reconciles the QuayRegistry custom resource and managed Quay components.
- Main ACM-governed seed Quay: curates approved upstream sources and seeds DCS-internal platform Quay instances.
- DCS-internal platform Quay: provides local platform mirror repositories and the default OpenShift lifecycle pull endpoint in AM1 or AM4.
- Tenant-facing Quay service: provides shared tenant organizations, CI/CD push endpoints, HCP workload pull paths, and selected cross-datacenter synchronization.
- Quay application replicas: expose the OCI registry API, web UI, API, repository metadata, authentication flows, and push/pull paths.
- PostgreSQL: stores durable metadata for users, organizations, teams, robot accounts, repositories, tags, manifests, and permissions.
- Redis: supports runtime features such as events, garbage collection, and build-related state.
- Object storage: stores image and artifact blobs in an S3-compatible ODF-provisioned object bucket backed by the dedicated Ceph platform baseline; raw block or file storage is not the production Quay blob backend.
- Clair: provides vulnerability scan visibility for stored images.
- Mirror workers: synchronize approved upstream repositories, organizations, tags, Red Hat content, and operator content into the main seed tier, from the main seed tier into controlled DCS-internal platform namespaces, and selected tenant-facing repositories across datacenters.
- External endpoint: uses approved DNS, TLS, firewall, and load-balancing controls in the Datacenter Services external profile.
Service controls:
- Human access uses OIDC, organizations, teams, and repository permissions.
- Automation uses scoped robot accounts; short-lived robot-account federation is preferred where the IAM integration supports it.
- Mirrored repositories are treated as controlled imports and are not general manual-push targets.
- Tenants use tenant-facing Quay organizations by default. DCS-internal platform repositories are not tenant push targets, and the main seed tier is reserved for platform-controlled upstream intake and fleet seeding.
- The tenant-facing service is shared per datacenter. Quay organizations, teams, repository permissions, and robot accounts provide tenant isolation inside that service; one Quay instance per tenant is not baseline.
- Dedicated tenant Quay instances require an exception decision or time-bound exception record with owner, expiry, IAM, mirroring, backup, scanning, logging, and admission-control evidence.
- Immutable tags, tag expiration, repository logs, and Clair findings provide evidence, but deployment blocking remains an admission-policy and release-governance function.
- Backup scope includes Quay configuration, PostgreSQL metadata, and object-storage blobs; restore evidence must prove pull by digest after recovery.
- Geo-replication is not part of the baseline because it requires a separate database, cache, object-storage health, and global load-balancing design.
Detailed architecture is captured in quay-registry-architecture and red-hat-quay-solution-architecture.
Technical Documentation
- Architecture note: quay-registry-architecture
- ARC42 HLD: red-hat-quay-solution-architecture
- Vendor architecture summary: source-red-hat-quay-architecture
- Vendor operations summary: source-red-hat-quay-management
- Vendor usage summary: source-red-hat-quay-usage