Container Registry Market Share 2026: What the Data Can Show

No neutral dataset publishes container registry market share in 2026. Docker reports Docker Hub pull counts, cloud providers publish limits and prices but not usage, and neither the Stack Overflow 2025 survey nor the CNCF 2025 survey asks which registry you use. The honest picture is assembled from separate signals, each counting something different.

This post gathers those signals, labels what each one counts and when it was measured, and shows where they disagree. It is written for platform and DevOps leads choosing or consolidating registries, and for security teams deciding where to scan.

Key takeaways

• No trustworthy registry share number exists. We found no survey question, filing or neutral measurement that splits registry usage by provider.
• Docker Hub's most cited totals are old. The 318 billion all time pulls and nearly 30 billion pulls in a quarter come from a Docker blog post dated 10 February 2021.
• "11 billion pulls a month" is widely repeated but hard to trace. We could not find it on a Docker page we could open.
• Surveys measure tools, not registries. Stack Overflow 2025 reports Docker used by 71.1% of 24,473 respondents to its cloud development question; CNCF reports 82% of container users run Kubernetes in production. Neither says where images are stored.
• Cloud registries publish prices and quotas, not volumes. Registry use plausibly follows cloud use, but nobody publishes the ratio.
• Self-hosted data is project data. Harbor publishes contributors and stars, and even those disagree between sources.
• Most images pass through several registries. For security, that matters more than any share figure.

Why there is no clean registry market share number

Market share needs a common unit, and registries have at least five candidates: pulls, accounts, stored images, revenue and survey usage. Docker has published the first three for Docker Hub. No cloud or project registry we checked publishes any of them, registry revenue is folded into broader cloud or subscription revenue, and the big developer surveys do not ask.

A registry is also rarely chosen on its own. It comes with a cloud account, a source code host, a Kubernetes distribution or a tool's default. So the useful question for most teams is not "which registry has the most share" but "which registries do our images actually come from and go to".

How many pulls does Docker Hub serve, by Docker's own figures?

The most quoted Docker Hub numbers come from the Docker Index on Docker's blog. The post we fetched is dated 10 February 2021.

Three points matter. First, the date: some summaries we saw in planning called the 318 billion figure a late 2024 number, but the primary post is from February 2021, and we found no later Docker Index with comparable pull totals. Second, the unit: Docker's current usage documentation says a pull includes a version check and any resulting download, and a multi architecture image counts as one pull per architecture. CI systems and Kubernetes nodes generate most pulls, so a pull is a request event, not a person or a deployment. Third, the 20 million developer figure is for Docker as a whole and should not be set beside 7.3 million Hub accounts as a growth line.

Where does the 11 billion pulls per month figure come from?

"11 billion pulls per month" appears in talks, decks and academic writing. In planning we saw it attributed to an ACM journal article, "A Decade of Docker Containers" (DOI 10.1145/3761803). When we tried to open that article on 23 October 2026, the publisher returned an access error, so we could not check the sentence or its citation.

We did not find the figure on any Docker page we fetched: the 2021 Docker Index post, the Docker Hub product page, the company page or the usage documentation. Docker's 2021 figure of nearly 30 billion pulls in one quarter works out to roughly 10 billion a month, so 11 billion is the same order of magnitude. Consistency is not confirmation. Quote the 2021 figures with their 2021 date, and label 11 billion per month as secondary.

What do Stack Overflow 2025 and CNCF 2025 say, and why does neither give registry share?

Stack Overflow Developer Survey 2025

The Stack Overflow 2025 technology results include a "cloud development" question covering cloud platforms, container tools, package managers, build tools and infrastructure as code. Stack Overflow reports 24,473 respondents to the question, including 20,070 professional developers.

Source: survey.stackoverflow.co/2025/technology, fetched 23 Oct 2026. Per tool counts are not published.

No registry appears among the answer options. Docker use tells you how many respondents use Docker tooling, not how many push to Docker Hub; many pull from Docker Hub and push somewhere else.

CNCF Annual Cloud Native Survey 2025

The CNCF announced its 2025 survey results on 20 January 2026. It reports that 82% of container users run Kubernetes in production, up from 66% in 2023; that 98% of surveyed organizations have adopted cloud native techniques; and that 66% of organizations hosting generative AI models use Kubernetes for some or all inference.

Neither the announcement nor the report page we fetched states the sample size, fielding period or anything about registries. Secondary coverage gave two different sample sizes (628 and 689). We could not confirm either, so we use neither.

Why surveys miss registries

Surveys ask about tools people choose. Registries often come preconfigured by a platform team, and a developer may not know where production images live. That makes a registry question harder to ask well, which probably explains its absence.

Ranked: what the one comparable survey measures

This table ranks tools from the Stack Overflow 2025 cloud development question by one measured number: the share of all respondents using each. Same question, same year, same base. It ranks tool usage, not registries.

Respondents could pick several tools, so the column does not sum to 100% and is not a split of anything. The pairing column is context: an AWS user may store images in GitHub Container Registry, and a Docker user may never push to Docker Hub.

How do cloud registries track cloud provider adoption?

Amazon ECR, Google Artifact Registry and Azure Container Registry are the default private registries on their clouds, so registry use plausibly follows cloud use. That holds in direction and fails in magnitude. What the clouds publish is pricing and limits, and those explain why images stay near compute.

Amazon ECR. AWS's pricing page (fetched 23 October 2026) says transfer between ECR and EC2, Lambda, App Runner or Fargate in the same region is free, while cross region and internet transfer is billed to the repository owner. Its worked example prices private storage at $0.10 per GB-month. ECR Public includes 50 GB per month of storage, 500 GB per month of anonymous internet transfer, 5 TB per month for authenticated AWS accounts, and unlimited transfer to AWS compute.

Google Artifact Registry. Google's transition documentation says Container Registry shut down effective 18 March 2025 and writes stopped. gcr.io URLs hosted on Artifact Registry keep working, and most Google owned images now live there. A gcr.io reference that still resolves is now served by Artifact Registry.

Azure Container Registry. Microsoft's SKU page (updated 15 October 2026) lists Basic, Standard and Premium with 10, 100 and 500 GiB of included storage. Geo-replication, private endpoints, customer managed keys, connected registries and content trust are Premium only; artifact cache rules come with Standard and Premium. Data plane reads are limited to 10,000 requests per minute per registry on Basic and Standard and 20,000 on Premium, described as best effort maximums not backed by an SLA.

What you cannot infer: none of the three publishes pull volume or registry counts, so cloud share cannot be converted into registry share. One cloud customer may run several registries, for example pushing to GitHub Container Registry from CI and caching into ECR. And Stack Overflow's 43.3% for AWS is a share of respondents, not of cloud revenue. We did not use a revenue based cloud share dataset because we could not fetch one from its publisher during this research.

What does Harbor's CNCF status and journey report show about self-hosted adoption?

Harbor is the CNCF graduated open source registry and the clearest public window into self-hosting. The window shows project activity, not installs.

The journey report describes CERN using Harbor across more than 170 sites. The adopters file lists about 35 organizations, says some users are unlisted, and includes entries describing fleets from hundreds to tens of thousands of nodes. It is a floor, not an estimate.

The star counts disagree: 3,446 from LFX Insights on the CNCF page and 29.6k on GitHub, on the same day. They cannot describe the same thing; LFX may count a window or subset. The journey report also disagrees with itself, showing 5,227+ individuals and 659+ companies in its snapshot but 6,090 and 762 in its contributor section.

The CNCF's 8 December 2025 Harbor blog lists vulnerability scanning (Trivy installs with the --with-trivy flag), project level RBAC, replication between Harbor instances, LDAP and Active Directory, and SBOM generation since v2.11. The README adds OIDC single sign-on, blocking vulnerable images from deployment, and notes v2.15.0 as the first release with Cosign signed artifacts. Self-hosted registries report usage to nobody, which is often the point.

What do we know about GitHub Container Registry, Quay.io and the Red Hat registries?

GitHub Container Registry. GitHub's documentation describes ghcr.io, scoped to a user or organization, supporting Docker V2 Schema 2 and OCI images. New packages are private by default and public images can be pulled anonymously. GitHub recommends publishing from workflows with GITHUB_TOKEN. Layers can be up to 10 GB, and command line pushes link to a repository only through the org.opencontainers.image.source label. GitHub publishes no GHCR pull or package totals on the pages we fetched.

Quay.io. Its documentation covers build triggers, robot accounts and notifications, and has a troubleshooting page for HTTP 429 responses, so rate limiting exists. We found no published limits, pull totals or repository counts. AWS lists Quay as an unauthenticated upstream for ECR pull through cache.

Red Hat registries. Red Hat's authentication page (updated 9 May 2025) describes registry.access.redhat.com (product images, no login), registry.redhat.io (product images, login required, service accounts recommended for shared systems such as OpenShift clusters) and registry.connect.redhat.com (third party vendor products, login required). Some images exist only on registry.redhat.io. No usage numbers are published.

Docker Hub is the only registry in this post with a vendor published pull total, and that total is from 2021.

Signals per registry: one public figure for each

One public signal per registry. They are different measures, so the rows are alphabetical, not ranked.

What happened to k8s.gcr.io and why did the Kubernetes project move to registry.k8s.io?

Kubernetes is one of few cases where a registry's economics were explained in public. The Kubernetes blog said on 28 November 2022 that from Kubernetes 1.25 the project registry moved from k8s.gcr.io to registry.k8s.io. On 6 February 2023 the project announced k8s.gcr.io would be frozen from 3 April 2023, and on 10 March 2023 it published a redirect explainer.

AWS's containers blog of 20 March 2023 gives the reasons. Google had hosted the registry since Kubernetes began, and egress charges on pulls from other clouds made that unsustainable for the CNCF. The community moved to a distributed model with other providers, including AWS, hosting layers so clients are redirected to storage in a nearby region. Traffic to k8s.gcr.io was redirected from 20 March 2023, and the old registry was frozen on 3 April 2023: pushes blocked, pulls still served, no long term guarantee.

The registry.k8s.io README says traffic currently goes to GCP and AWS, supported by donations, that there is no uptime SLA, and: "DO NOT depend on the implementation details of this registry." For uptime or IP allow lists it recommends mirroring into infrastructure you control. Two lessons travel: a public registry hostname is a dependency with its own lifecycle, and egress, not storage, is what usually forces a registry to change shape.

How do rate limits and egress pricing shape where teams mirror images?

Pull limits and transfer prices are the main reasons images get copied into private registries.

The two Docker rows disagree. Docker's usage docs and its policy post of 21 February 2025 (updated 8 April 2025) say the limits in force are 100 per 6 hours unauthenticated and 200 per 6 hours for Personal, that the tighter scheme planned for 1 April 2025 was not enforced, and that any change gets at least 6 months' notice. The product page shows hourly limits. We treat the docs and policy post as current; check the headers your own pulls return (step 3 below).

Documented mirroring options:

• Docker registry mirror: the open source registry with proxy.remoteurl set to https://registry-1.docker.io. Docker says only Docker Hub can be mirrored this way.
• Amazon ECR pull through cache: ECR Public, the Kubernetes registry and Quay without credentials; Docker Hub, Azure Container Registry, GitHub Container Registry, GitLab Container Registry (SaaS only) and a hardened image vendor's registry with credentials in Secrets Manager; other ECR registries through an IAM role. ECR rechecks upstream for a newer image under a tag at most once every 24 hours.
• Azure artifact cache rules: Standard and Premium tiers.
• Harbor replication: policy based replication between registries.

Each one copies an image into another registry, which is where the security question starts.

How many registries does a typical image travel through?

No dataset measures this. The path below is illustrative, built from the documented features above:

1. Upstream base image in Docker Hub, registry.k8s.io, ECR Public or Quay.io.
2. Cache or mirror in a private registry, to avoid rate limits and egress.
3. CI registry for the built application image, often GitHub Container Registry or GitLab's registry.
4. Production registry next to the workload.
5. Replicas across regions (ACR geo-replication, ECR replication) or edge sites (ACR connected registries).

That is three to five registries for one image, and each hop can change what you think you are running:

• Tags move. ECR pull through cache repositories default to mutable tags and refresh them from upstream within 24 hours.
• Attached artifacts may not travel. AWS says ECR caches OCI referrers such as signatures and SBOMs and rechecks them every 6 hours; other mirrors may not copy them.
• Scan coverage differs. A scan in the CI registry misses images that bypass CI; a scan in production misses the cache until promotion.

So identify images by digest, not tag or hostname, and scan the digest. An identical image has the same digest in every registry.

Where do the datasets disagree?

None of these change the main conclusion. They show how fast a number loses its date as it is repeated.

How we measured

Datasets and dates. Every figure comes from a page fetched on 23 October 2026, listed under Sources. Docker Hub totals: Docker's blog, 10 February 2021. Developer usage: Stack Overflow Developer Survey 2025. Kubernetes production use: CNCF announcement, 20 January 2026. Harbor: CNCF project page (LFX Insights data shown 23 October 2026), Harbor Project Journey Report (22 September 2023, data to Q3 2023), the Harbor repository and ADOPTERS.md. Registry policies: each operator's own documentation.

Samples and wording. Stack Overflow figures come from the "cloud development" question, answered by 24,473 respondents including 20,070 professional developers, with multiple answers allowed. The CNCF pages we opened give no sample size or question wording, so we quote only CNCF's published headline percentages.

What each counts. Docker Hub pulls count request events, including automated ones, with multi architecture images counted per architecture under Docker's current definition; we do not know whether the 2021 totals used that definition. Docker Hub accounts count accounts, not people. Stack Overflow counts respondents using a tool. CNCF counts survey respondents or organizations. Harbor figures count contributors, companies and stars. Cloud registry pages state prices and limits, not usage.

Why they cannot be added. Pulls, accounts, respondents, contributors and prices are different units. Adding or averaging them produces a number that describes nothing. The ranked table therefore uses one question from one survey, and the signals table is deliberately unranked.

What we left out. Hosting comparison sites ranking registries without a method, vendor research without a stated sample, any cloud revenue share we could not fetch from its publisher, and the 11 billion per month figure as a measured value.

Step by step: map the registries your images actually use

Share figures will not tell you where your own images come from. These commands will.

1. Count the registries your running pods pull from

Extending the Kubernetes project's kubectl query to group images by registry host:

kubectl get pods --all-namespaces -o jsonpath='{..image}' \
  | tr -s '[[:space:]]' '\n' | sort -u \
  | awk -F/ '{ if (NF>1 && ($1 ~ /\./ || $1 ~ /:/)) print $1; else print "docker.io" }' \
  | sort | uniq -c | sort -rn

Images without a registry host resolve to Docker Hub, which is why they map to docker.io. The {..image} path also catches init and ephemeral containers. To find leftover k8s.gcr.io references in manifests, grep -rn "k8s.gcr.io" . and swap the prefix for registry.k8s.io.

2. Check your Docker Hub rate limit status

Docker documents this check; a HEAD request does not count toward the limit.

TOKEN=$(curl -s "https://auth.docker.io/token?service=registry.docker.io&scope=repository:ratelimitpreview/test:pull" | jq -r .token)
curl -s --head -H "Authorization: Bearer $TOKEN" \
  https://registry-1.docker.io/v2/ratelimitpreview/test/manifests/latest \
  | grep -i ratelimit

Look for ratelimit-limit and ratelimit-remaining with w=21600 (6 hours). Run it from CI runners, where shared IP addresses hit limits first.

3. Compare digests across registries

crane digest docker.io/library/nginx:1.27
crane digest 123456789012.dkr.ecr.us-east-1.amazonaws.com/docker-hub/library/nginx:1.27

Different digests mean your cache serves a different image under the same tag. With ECR pull through cache that is expected for up to 24 hours.

4. Cache registry.k8s.io in ECR

aws ecr create-pull-through-cache-rule \
  --ecr-repository-prefix k8s \
  --upstream-registry-url registry.k8s.io \
  --region us-east-1

No credentials are needed for this upstream. Add a repository creation template if you want tag immutability or lifecycle rules, since none apply by default.

5. Verify a Kubernetes image signature upstream and in your cache

cosign verify registry.k8s.io/kube-apiserver-amd64:v1.37.0 \
  --certificate-identity krel-trust@k8s-releng-prod.iam.gserviceaccount.com \
  --certificate-oidc-issuer https://accounts.google.com | jq .

The identity and issuer come from the Kubernetes documentation. Run the same check against the cached copy; if it passes upstream and fails in the cache, the signature did not travel.

6. Push to GitHub Container Registry with the repository linked

permissions:
  contents: read
  packages: write
steps:
  - uses: actions/checkout@v4
  - run: echo "${{ secrets.GITHUB_TOKEN }}" | docker login ghcr.io -u ${{ github.actor }} --password-stdin
  - run: |
      docker build --label org.opencontainers.image.source=https://github.com/${{ github.repository }} \
        -t ghcr.io/${{ github.repository }}:${{ github.sha }} .
      docker push ghcr.io/${{ github.repository }}:${{ github.sha }}

7. Scan the image by digest

safeguard scan --image ghcr.io/your-org/your-app@sha256:<digest>

The Safeguard CLI writes JSON results under ./output. A digest scan applies to that exact image in every registry that holds it.

Common mistakes

Reading the data

• Quoting Docker Hub's 318 billion pulls as recent. It is from February 2021.
• Treating Docker usage (71.1% in Stack Overflow 2025) as Docker Hub share.
• Treating AWS, Azure or Google Cloud usage as their registries' share.
• Reading overlapping survey percentages as a split that should sum to 100%.
• Comparing pulls with stars or contributors.
• Repeating 11 billion per month without saying its source is unconfirmed.

Acting on it

• Choosing a registry by popularity instead of by where compute runs and what transfer costs.
• Scanning in one registry and deploying from another without matching digests.
• Deploying by tag from caches whose tags are mutable by default.
• Depending on a public registry's endpoints, which the registry.k8s.io maintainers warn against.
• Running anonymous CI pulls from shared IP addresses; Docker warns these can trigger abuse limits.
• Assuming signatures and SBOMs follow an image into a mirror.

Where Safeguard fits

Safeguard does not measure registry share or pull volumes. It helps with the security question this post ends on.

Safeguard scans container images, repositories and SBOM files from one CLI (safeguard scan --image <name>, --dir ., --sbom <file>), matches components against vulnerability databases, and uses reachability analysis to rank what matters. The platform shows which projects contain a given component and version, so when a base image pulled from Docker Hub, ECR Public or registry.k8s.io carries a vulnerable library, you can see every project that inherited it, whichever registry holds the image now. Policies and gates evaluated in the platform can block a promotion between registries.

Safeguard does not change a registry's rate limits, egress pricing or availability, and does not replace its access controls.

Gold Registry can serve as a pull source: 6,000+ hardened components across packages and container images, each held continuously to zero exploitable critical or high CVEs, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page. Public Gold artifacts can be pulled free with rate limits; Pro removes pull limits, and Enterprise adds a dedicated Gold mirror inside your VPC or air gapped snapshots. Gold Open Source is free without login and includes a Container Images directory.

Related reading: Docker Hub versus private registries, registry security features across clouds, GitHub Container Registry, Docker Hub rate limit changes, mirroring Docker Hub with a pull through cache, container image supply chain incidents in 2026 and starting clean with Gold Registry.

FAQ

What is Docker Hub's market share in 2026?

Nobody publishes one. Docker's last comparable figures we found are from 10 February 2021: 318 billion all time pulls, nearly 30 billion in Q4 2020 and 7.3 million accounts. Other registries publish no pull totals, so no share can be calculated.

Which container registry is most used?

There is no measured answer by registry. The closest single measure is Stack Overflow 2025, where 71.1% of 24,473 respondents reported using Docker, which measures the tool, not the registry.

How many pulls does Docker Hub get per month?

Docker's 2021 figures imply roughly 10 billion a month in Q4 2020. The widely repeated 11 billion figure could not be confirmed on a Docker page.

Does the CNCF survey ask about container registries?

Not in the 2025 material we fetched. CNCF reported 82% of container users running Kubernetes in production on 20 January 2026, with nothing on registries.

Why did Kubernetes move from k8s.gcr.io to registry.k8s.io?

Egress costs from users on other clouds. Traffic was redirected from 20 March 2023 and k8s.gcr.io was frozen on 3 April 2023.

What are Docker Hub's pull rate limits in 2026?

Docker's documentation says 100 pulls per 6 hours unauthenticated, 200 per 6 hours for Personal accounts and unlimited with fair use on paid plans. The product page shows hourly figures, so check your own response headers.

Is Google Container Registry still available?

Google says it shut down effective 18 March 2025. gcr.io URLs hosted on Artifact Registry still work.

Should I scan images in every registry they pass through?

Scan once per distinct digest and enforce the result where images are promoted. A different digest under the same tag needs its own scan.

Fix it without waiting for upstream

Most registry choices come down to where you pull base images from and how quickly you can replace a vulnerable one. The steps below cover that second part, wherever your images are stored.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

To try these flows, download Safeguard and read the CLI documentation.

This demo is a real CLI session: install, open the interactive terminal and ask it to fix the lodash CVE in a repository. The assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing, then shows /permissions, /model and /scan .. The same terminal is where you would scan the image digests you mapped above.

Click through it at your own pace, or open it full screen.

This demo sets up the runner on your own machine, approves it with its device code and scans from the terminal. Use this setup when images sit in a private registry or cache only your network can reach.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. Once connected, you can ask about findings across your projects in plain language, such as which projects share a vulnerable base image component.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Docker: Docker Index shows continued massive developer adoption (10 Feb 2021)
• Docker Docs: Docker Hub pull usage and limits
• Docker: Revisiting Docker Hub policies (21 Feb 2025, updated 8 Apr 2025)
• Docker: Docker Hub product page
• Docker: Company page
• Docker Docs: Mirror the Docker Hub library
• Stack Overflow Developer Survey 2025: Technology
• CNCF: 2025 Annual Cloud Native Survey announcement (20 Jan 2026)
• CNCF: Annual Cloud Native Survey report page
• CNCF: Harbor project page
• CNCF: Harbor Project Journey Report (22 Sep 2023)
• CNCF blog: Harbor, enterprise grade container registry (8 Dec 2025)
• GitHub: goharbor/harbor repository
• GitHub: Harbor ADOPTERS.md
• Kubernetes blog: registry.k8s.io faster, cheaper and GA (28 Nov 2022)
• Kubernetes blog: k8s.gcr.io redirect to registry.k8s.io (10 Mar 2023)
• Kubernetes docs: Verify signed Kubernetes artifacts
• GitHub: kubernetes/registry.k8s.io README
• AWS Containers blog: Changes to the Kubernetes container image registry (20 Mar 2023)
• AWS: Amazon ECR pull through cache
• AWS: Amazon ECR pricing
• Google Cloud: Transition from Container Registry
• Microsoft Learn: Azure Container Registry SKU features and limits
• GitHub Docs: Working with the Container registry
• Quay.io documentation
• Red Hat: Red Hat Container Registry authentication

Last reviewed: 23 October 2026. Registry policies and limits change; check the linked documentation for the current terms.