Quay.io

What Quay.io actually is

Quay.io is a hosted container image registry run by Red Hat. You push Docker/OCI images and other artifacts to it, organize them into organizations, teams and repositories, and let servers pull them with robot accounts or user credentials. It is not a server or cloud-compute product — there are no cores, RAM or block volumes to compare — but it sits in the same buying decision as the rest of your infrastructure, which is why we track it alongside the rest of our /category/container-platforms entries.

The product has a longer history than most registry services. Quay launched in late 2013 as the first private hosted registry on the market, introduced at a Docker meetup in New York in October 2013 by the founders of DevTable, who built the first version in about a month. CoreOS acquired Quay in 2014 to bolster its container-security mission, and when Red Hat acquired CoreOS in January 2018 the registry joined the Red Hat portfolio and was renamed Red Hat Quay for the self-managed line. The code was later open sourced as Project Quay. Practically, that lineage means two things: the hosted service has more than a decade of production use behind it, and the same registry can run on your own hardware as Red Hat Quay if you ever want out of the SaaS.

The feature set is aimed squarely at teams with compliance pressure. Organizations and teams with repository-level permissions, robot accounts for CI/CD (including keyless authentication via OIDC and Red Hat Single Sign On), image build triggers against GitHub, Bitbucket, GitLab or self-hosted Git repositories, a full HTTP API, audit and usage logs that can be exported, SSL/TLS encryption on every plan, and automatic vulnerability scanning on every push via Clair v4. Two capabilities we value in practice: image rollback and zero-downtime garbage collection — both called out since the early product days, and both things that quietly bite teams on lesser registries.

Pricing: what you really pay

Pricing is public and the model is simple: public repositories are free and unlimited; you pay per private repository. On the current plans page that means $15/month for 5 private repositories (Developer), $30 for 10 (Micro), $60 for 20 (Small), then $125 for 50, $250 for 125, $450 for 250, $850 for 500, $1,600 for 1,000, $3,100 for 2,000 and $21,700 for 15,000. Every tier includes unlimited public repos, robot accounts, teams, continuous integration, logging and auditing; team-based permissions are advertised from Micro upward. Subscriptions run monthly through Stripe with a valid credit card, and the Developer and Micro tiers advertise a 30-day free trial. Enterprise procurement can go through the AWS Marketplace instead: stackable yearly subscriptions in multiples of 100 private repositories, with volume discounts and Red Hat's 24x7 Premium Support, invoiced to the AWS account.

There is a free tier in the real sense, not just a trial. If you only host public repositories you pay nothing, which is why a large share of open-source images live on Quay.io. Red Hat documents fair-use bounds: above roughly 100 GB of stored image layers or 1 TB of downloads per month, an organization may face quota limits and a conversation with the Quay team. Open-source projects expecting to exceed those numbers are asked to contact support up front, which we consider the right posture — it beats silent throttling.

Our read of the model: per-repository billing rewards tidy repositories and punishes sprawl. A team shipping 200 small microservice repos pays $450/month at the 250-repository tier, while a team shipping five fat mono-repos pays $15. We generally prefer per-seat or per-gigabyte pricing for private registries because it tracks actual consumption, but the predictability here is real: you always know next month's bill before it arrives. The big jump, from $3,100 for 2,000 repositories to $21,700 for 15,000, needs a spreadsheet — at that scale you should be negotiating with Red Hat and comparing against running Red Hat Quay yourself. Note that the two products bill differently: self-managed Red Hat Quay is priced per deployment, billed annually with a purchase order, and is also bundled into OpenShift Platform Plus. Upgrading from hosted Quay.io to self-managed Red Hat Quay is supported, and the reverse path exists too.

Performance & infrastructure

Quay.io is fully managed and serves image content through global content delivery networks; Red Hat publishes no breakdown of where the registry itself runs, so we leave the datacenter fields in our database empty rather than guess. Image pulls for a CI runner or Kubernetes node therefore feel like any CDN-backed download: close to the edge, consistent. Pushes and API calls still go to the origin, and teams far from it will notice latency on large layers. We have not benchmarked registry push/pull throughput ourselves — our /benchmarks covers compute instances, not registries — so treat any specific throughput number you read elsewhere as that author's test, not ours.

Reliability is the harder question, and honesty requires saying what we do not know: we found no published uptime SLA for hosted Quay.io. What exists publicly is Red Hat's status page plus third-party monitors watching it. One aggregator (statusfield) recorded 98.6% availability for the Quay.io component over a 90-day window with two incidents, the longest 23 hours and 25 minutes. Another (IsDown) has logged 271 incidents across 13 tracked components since June 2020, about 3.6 per month — many of them build-system or integration components rather than the registry itself. Aggregator data is a rough signal, but a service with a real SLA usually publishes it. Enterprises that need contractual uptime should push for the number in a Red Hat contract rather than assume one exists.

Where the infrastructure genuinely shines is the security tooling. Clair v4 is enabled automatically on Quay.io — unlike self-managed Red Hat Quay, where it is off by default and you must switch it on — and scans every pushed image against CVE databases, enriched with CVSS scores from the US National Vulnerability Database, with no manual rescans required. Coverage is not universal: OS packages plus the Java, Golang, Python and Ruby ecosystems are analyzed, and an image containing, say, a Lua application gets no report for those dependencies. The documentation is explicit that scanning only lists vulnerabilities found; what you do about them is your decision, and registry superusers do not act on them for you. A clean scan report is evidence of process, not a compliance certificate.

Where it falls short

• Per-repository pricing punishes micro-repo architectures, and the largest published tiers get expensive fast — $3,100/month at 2,000 private repos before the jump to five figures.
• No published SLA for the hosted service, and support entitlements depend on which Red Hat contract you hold.
• Clair's blind spots (unsupported languages, the "we list it, you fix it" posture) mean green dashboards can hide real exposure.
• Product sprawl: Quay.io, Red Hat Quay, OpenShift Platform Plus and the AWS Marketplace route all price differently, and picking wrong is expensive to unwind.
• Free-tier fair-use caps (100 GB storage, 1 TB egress) are generous but enforceable, so heavy open-source projects live partly at Red Hat's discretion.
• The web UI works but shows its age next to newer registry services; power flows through the API, which suits engineers and less so occasional users.

Who should pick this

Our pick for open-source projects that need free, dependable public image hosting with CVE scanning attached — the free tier genuinely covers that case, and Quay.io's permissions model beats ad-hoc alternatives the moment a second maintainer joins. It is also the natural default for organizations already buying Red Hat: the same vendor as your Kubernetes platform, SSO through Red Hat Single Sign On, and a supported upgrade path to self-managed Red Hat Quay when data-residency or firewall rules push the registry inside your perimeter. Teams with audit obligations — who pushed what, from which robot account, when — get exportable logs and a permissions model that maps to how security teams actually think.

We would look elsewhere when your repository count is large and your images are small, when you need contractual uptime in writing before deploying, or when you want pricing that tracks seats or gigabytes instead of repo names. Teams deep in one cloud should also weigh that provider's own registry for pure convenience, though few match Quay.io's permission model or its free public tier.

Key takeaways

• Free and unlimited public repositories; paid plans start at $15/month for 5 private repos and scale by repository count to $21,700/month at 15,000.
• Automatic Clair v4 vulnerability scanning on every push with NVD CVSS enrichment — zero configuration on the hosted service.
• Registry lineage since 2013 (Quay, then CoreOS, then Red Hat/IBM), with a supported path to self-managed Red Hat Quay.
• No published uptime SLA for the hosted service; enterprises needing guarantees must negotiate them into a Red Hat contract.
• Per-repo pricing is predictable but rewards few repositories over many; budget before adopting a micro-repo layout.
• Best fit for open-source projects, Red Hat-centric shops, and teams that want robot accounts, SSO and audit logs out of the box.

Sources

• https://quay.io/plans/
• https://cloud.redhat.com/blog/reintroducing-quay.io-welcome
• https://docs.redhat.com/en/documentation/red_hat_quay/3.18/html/about_quay_io/quayio-ui-overview
• https://docs.redhat.com/en/documentation/red_hat_quay/3.12/html/about_quay_io/clair-vulnerability-scanner
• https://redhat.com/en/blog/red-hat-introduces-open-source-project-quay-container-registry
• https://redhat.com/en/blog/introducing-red-hat-quay
• https://packet.net/customers/quay
• https://aws.amazon.com/marketplace/pp/prodview-obcdisdfyp5oc
• https://statusfield.com/services/red-hat/quay-io
• https://isdown.app/status/quay-io
• https://en.wikipedia.org/wiki/Red_Hat