cloudparts

Quay

A container registry that runs the public Quay.io service and ships as Red Hat Quay for your own clusters: organizations and robot accounts, Clair scanning, image builds, geo-replicated storage, repository mirroring, proxy caching and auto-pruning.

What it is
Artifact registries
Used for
Common Vulnerabilities and Exposures (CVE)
Type
Open source
Made by
Red Hat
License
Apache 2.0 (Project Quay); Red Hat Quay is a subscription product
Facts checked
24 October 2026
Website Source code

What it is

Quay is one codebase in three forms. Project Quay is the open-source upstream under Apache 2.0; Quay.io is Red Hat’s hosted registry, built and deployed from that upstream; and Red Hat Quay is the supported product Red Hat builds and releases for running on your own infrastructure (the Quay Operator deploys it on Kubernetes). It speaks the Docker Registry v2 protocol and OCI Distribution 1.1, signs users in through LDAP, Keystone, OIDC, Google or GitHub, and stores image data on local disks, S3, Google Cloud Storage, Swift, Ceph or OpenShift Data Foundation.

Repositories belong to users or organizations with teams, ACLs and robot accounts for automation, with audit logs. Clair, which the Quay team started in 2015, scans images for known vulnerabilities, and Quay can build images itself when code is pushed to GitHub, Bitbucket, GitLab or any Git repository. Geo-replication shares one database across sites while copying the storage backend, so users can push and pull at any site; repository mirroring instead copies chosen repositories and tags from an external registry on a schedule, every 24 hours by default, into read-only repositories.

An organization can be set up as a proxy cache for an upstream registry such as Docker Hub, which avoids its pull limits; when the upstream is down, cached images are still served within a configured staleness period, and with a storage quota the least recently used tags are evicted. Auto-pruning policies, set per repository, organization or for the whole registry, delete the oldest tags beyond a count or tags older than a time span. Pruned tags stay recoverable during the organization’s “time machine” window before garbage collection removes them.

Why teams pick it

  • The same code runs Quay.io, the public registry Red Hat operates, and the supported Red Hat Quay product
  • Built-in image builds, Clair scanning, robot accounts and audit logs without extra services
  • Geo-replication and repository mirroring cover both one global registry and separate, synchronized ones
  • A label such as quay.expires-after=2w in the Dockerfile lets CI images expire on their own

Watch out for

  • Container images and OCI artifacts only: no Maven, npm or PyPI repositories
  • Most documentation is written for the paid Red Hat Quay product; running Project Quay yourself means following upstream guides with less support
  • Proxy cache gaps: anonymous users can’t pull an image that isn’t cached yet, and after the staleness period an upstream outage reaches users
  • Auto-pruning needs the newer v2 UI and doesn’t apply to mirrored or read-only repositories

Alternatives

What all artifact registries have in common →Compare side by side →
HarborOpen sourceA CNCF-graduated, self-hosted registry for container images and other OCI artifacts that adds projects, access control, vulnerability scanning, signing, replication, proxy caching and tag retention on top of the standard registry.

How it fits with other technologies

Let Quay expire a CI image tag two weeks after it is built · dockerfile

FROM registry.access.redhat.com/ubi9/ubi-minimal
COPY app /usr/local/bin/app
# Quay deletes this tag 2 weeks after the image is built
LABEL quay.expires-after=2w
ENTRYPOINT ["/usr/local/bin/app"]

See it in a real stack

No architecture uses Quay yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2013–2026

Quay launched in late 2013 as the first private hosted Docker registry, started in New York by Jake Moshenko and Joseph Schorr. It became known for developer experience and responsive support, and for features such as image rollback and zero-downtime garbage collection.

On August 13, 2014 CoreOS bought Quay.io; its two founders joined CoreOS to open a New York office, Quay.io stayed open as a standalone product, and CoreOS launched an on-premise version, CoreOS Enterprise Registry, powered by Quay.io. The Quay team started the Clair image scanner in the open in 2015. Red Hat announced on January 30, 2018 that it would buy CoreOS for $250 million, and the on-premise product became Red Hat Quay.

On November 8, 2019 Red Hat open-sourced the Quay code base, together with the tooling to build and run it, as Project Quay under Apache 2.0, with a maintainer committee; Quay.io is now built and deployed from that upstream. Later versions added proxy cache organizations and storage quotas, and auto-pruning of old tags. Several release lines are maintained at once; 3.18.2 came out on October 20, 2026.

Why it’s built this way

Run a hosted service and an on-premise product from one code base
Red Hat said Quay.io is built and deployed from the open upstream, while Red Hat Quay is built and released by Red Hat, so the public service and the product don’t drift apart.
Two ways to copy images between sites
Geo-replication gives one registry with shared metadata across regions, while mirroring keeps independent registries in sync; the docs say the two can be used together.
Expire tags instead of deleting them at once
Pruned and expired tags go to a time machine window before garbage collection, so a mistaken cleanup policy can be undone.

Timeline

  1. 2013

    Quay launches as a private hosted Docker registry (late 2013)

  2. 2014

    CoreOS acquires Quay.io (August 13)

  3. 2015

    The Quay team starts the Clair scanner

  4. 2018

    Red Hat announces it will acquire CoreOS (January 30)

  5. 2019

    Red Hat open-sources Project Quay (November 8)

  6. 2026

    Project Quay 3.18.2 (October 20)

Sources7 · facts checked 24 October 2026

Improve this page on GitHub