Docker Hub vs Harbor

Docker Hub's documented pull limits decide how CI and Kubernetes clusters should fetch images, because the counter is kept per source address rather than per job. Unauthenticated pulls are limited to 100 per 6 hours per IPv4 address or IPv6 /64 subnet, and Docker Personal accounts get 200 per 6 hours, according to the Docker Hub pull usage and limits documentation. When a CI fleet or a cluster egresses through one NAT gateway, every runner and node shares that single address, so a busy pipeline can exhaust the quota for the whole fleet and cause pulls to fail with rate limit errors that look unrelated to the build.

A Harbor proxy cache project changes where those pulls originate. Harbor checks whether a cached image is still current with HEAD requests, and its documentation states that these checks do not trigger the Docker Hub rate limiter, so only the first fetch of each image and changed upstream content consumes upstream pulls. Design the cluster so that nodes and runners point at the Harbor endpoint rather than Docker Hub, and keep the proxy cache's upstream credentials scoped to a dedicated account. Before relying on this pattern, confirm your own upstream limits and quotas with Docker, since the figures above describe unauthenticated and Personal plan use and your contract may differ.

Paid Docker plans remain relevant even with a cache in place. A cache does not create pull capacity for images Harbor has never fetched, and it does not cover workloads that pull directly from Docker Hub outside the cache path. Ask Docker which account type and limits apply to the service account Harbor uses, and map every CI runner, node pool and developer workstation to either the cache or a documented exception. That inventory tells you whether a paid subscription is still needed for the residual direct pulls.

On the Docker side, the recurring cost is the subscription itself, billed per user and tied to the plan that unlocks features such as SSO and advanced controls. Confirm the current per-seat prices and which features each Docker plan includes directly with Docker, because those terms change and this page does not state them. On the Harbor side, there is no license fee, but the bill moves to your own infrastructure: compute for the Harbor services, block storage for image layers and Helm charts, a PostgreSQL database (the bundled internal database moved to PostgreSQL 18 in v2.15.2), and a Valkey cache that replaced Redis in the same release. Storage and egress grow with image count, tag retention and the number of clusters pulling, so ask your platform team to size them against your real pull volume before comparing totals.

Harbor also adds recurring engineering work that a hosted registry absorbs. Vulnerability scanning depends on Trivy, which Harbor bundles at install time through the --with-trivy option, so someone must keep the scanner database and the Harbor release current. Harbor v2.15.3 shipped security fixes together with two breaking changes, blocking webhooks to internal addresses by default and failing signing of unsigned images in projects that enforce content trust, so each upgrade needs a test window and a backup first, as the v2.15.2 release notes advise. Garbage collection, replication schedules, certificates and backups are also yours to run. Cost rises with the number of environments, HA requirements and the staff hours your team spends on upgrades, and falls when you standardize on one installer path and automate upgrades.

The one-time cost is setup: architecture, installation, SSO wiring to your OIDC or LDAP directory, replication and proxy cache configuration, CI and cluster repointing, and runbooks. Ask any implementation partner for a written scope listing these items, the environments covered and the acceptance tests, then ask what ongoing support and upgrade retainer would cost after go-live. Keep a paid Docker plan for a period only if specific developers still need hosted features during the cutover, and budget the overlap explicitly so it does not become a permanent second bill.

Many teams do not have to choose one registry. A common pattern keeps a paid Docker plan for public image pulls and runs a self-hosted Harbor registry for private repositories, regulated images and internal Helm charts. The other common pattern uses Harbor as a proxy cache in front of Docker Hub, so cluster and CI pulls of public images go through your own registry while Docker Hub stays the upstream source. Which path fits depends on where your images come from and who is allowed to see them, not on a general preference for open source.

Keeping Docker Hub makes sense when public base images are the bulk of your pulls, your build fleet already stays within the account-based allowances, and your private repositories are small enough that a per-seat plan costs less than the engineering time to operate Harbor. It also makes sense when a team relies on Docker Scout or other Docker-hosted features that you have not yet confirmed Harbor replaces. Check the current Docker plan terms directly with Docker, including which features are gated to Team and Business, and compare them with your own pull volume measured over several weeks, as the Docker Hub pull usage and limits documentation describes the counting rules.

Running Harbor makes more sense when private application images, proprietary base images or regulated workloads must stay inside your own network or cloud account, when you need the audit logs, role-based access and LDAP or OIDC sign-on that you control, or when air-gapped clusters need an internal source. A hybrid is often the most practical: keep the paid plan for public pulls if needed, and point clusters at a Harbor proxy cache project so that repeated pulls of public images are served locally. Confirm with your security team which images may be cached, how long cached copies are retained (the default proxy cache retention is 7 days according to Harbor's documentation), and who runs the upgrades and backups for the Harbor instance.