Is self-hosted Harbor cheaper than Docker Hub for your team?
Harbor has no license fee, but it moves the infrastructure, upgrade and operating work onto your team, so whether it costs less than Docker Hub depends on your pull volume, your user count and the engineer time you can spare. Most readers arrive with one of three triggers: a renewal quote, pull-limit failures in CI, or a rule that images must stay inside a specific network. Each trigger points to a different cost comparison, and the numbers should come from your own environment rather than from assumptions about either side. Self-hosting tends to cost less when your costs grow with people or pulls. Docker Hub's free use is limited to 100 unauthenticated pulls per 6 hours per IPv4 address or IPv6 /64 subnet, and 200 per 6 hours for Docker Personal accounts, according to Docker's pull usage documentation. A Harbor proxy cache project can absorb much of that traffic inside your network, and its cache checks use HEAD requests that do not count against the limiter. Air-gapped networks are the clearest case where a hosted registry is not an option at all, so the comparison becomes Harbor against the cost of building a transfer process by hand. Per-user subscription prices and the features gated to Team and Business plans must be read from Docker's current pricing page before you compare them, because both change and this page does not assume any particular figure. Self-hosting tends to cost more for a small team with few pulls and no on-call capacity. Harbor's own costs include servers, storage, the bundled PostgreSQL and Valkey components, backups, and time for upgrades. Recent Harbor releases changed bundled components, including the move to PostgreSQL 18 and Valkey in v2.15.2, so plan for upgrade testing and a backup before each change. Ask your team to estimate the hours per quarter for patching, certificate renewal, garbage collection and incident response, then price that time at your internal rate. If nobody can own a registry outage at night, the cheaper subscription may be the lower-risk choice, and keeping a paid Docker plan alongside Harbor for authenticated pulls can still make sense.
Which cost components move when you replace Docker Hub with Harbor
This table lists each cost component on the Docker Hub side and the self-hosted Harbor side, and whether it is one-time or recurring. Read it as a checklist for a quote request, since Docker's plan prices are not published here and the self-hosted costs depend on your own infrastructure. The main takeaway is that Harbor removes the license line but adds hosting, database, upgrade and engineering work that you own.
| Cost component | Docker Hub side (commercial) | Harbor side (self-hosted) | One-time or recurring |
|---|---|---|---|
| Docker subscription | Per-user plan; Team and Business gate features such as SSO and higher limits. Confirm current prices on Docker's site. | No license fee. Harbor is Apache-2.0 licensed. | Recurring on the Docker side; none on the Harbor side |
| Harbor software | Not applicable | Free to use. Cost is the staff and infrastructure that run it. | One-time setup; ongoing operation |
| Servers and compute | Not applicable | Hosts for Harbor core services, scanning and replication workers, sized to your pull and push volume. | Recurring |
| Storage for images and replicas | Hosted storage counted against your plan, if any. Ask Docker how it bills storage for private repositories. | Your object or block storage for layers, plus extra copies if you replicate to a second site. | Recurring, grows with image count and tags |
| PostgreSQL and Redis | Not applicable | Harbor v2.15.2 bundles PostgreSQL 18 and replaces Redis with Valkey as the cache. You operate these or use managed equivalents. | Recurring |
| Trivy scanning | Docker Scout is the vendor scanner. Check which scanning features your plan includes. | Trivy is open source and enabled with the --with-trivy install option. You pay for the compute it uses. | Recurring compute |
| Implementation and migration | Mostly internal effort to repoint CI and Kubernetes pull secrets. | Install, configure SSO, replication, proxy cache and cutover. Scope it in writing with a partner or your own team. | One-time |
| Upgrades and patch cycles | Handled by Docker as part of the hosted service. | You schedule upgrades. Take a backup first, since v2.15.2 changed the bundled database and cache. Patch releases such as v2.15.4 need regular rollout. | Recurring |
| Support | Included in the Docker plan you buy, at the level that plan provides. | Community channels or a paid support or retainer contract. Ask any provider for response terms in writing. | Recurring if you buy support |
| Internal engineer time | Low for daily use, plus admin time for seats and access. | Ongoing ownership of availability, backups, certificates, access reviews and incident response. | Recurring, the largest driver for most teams |
What moves the Docker Hub versus Harbor comparison
Six drivers decide whether a Docker Hub subscription or a self-hosted Harbor registry costs less for your team. Most of them push the cost in both directions, so the same change can favor either side depending on how the others move.
Authenticated users and seats
Docker bills paid plans per user, so every engineer, bot account and CI identity that needs private access adds to the subscription. Harbor has no per-user fee, but its role-based access control, LDAP or AD, and OIDC setup add identity work up front. Count named users, service accounts and external contractors, and ask Docker which of these count as seats on your plan.
Pull volume from CI and nodes
Unauthenticated pulls from a shared IP address count against Docker Hub's limit of 100 per 6 hours, and Personal accounts get 200 per 6 hours. Large CI fleets and Kubernetes nodes behind one NAT can hit these limits quickly, which pushes teams toward a paid plan or a local cache. A Harbor proxy cache can absorb repeated pulls, but it adds storage and a cache to operate.
Image and artifact storage growth
Docker storage quotas and overage terms depend on your plan, so confirm them in writing. In Harbor, storage is your own disk or object store, and it grows with every tag, architecture and signed artifact you keep. Set retention rules and run garbage collection on a schedule, or the bill for disks and backups rises without a visible owner.
Availability and HA requirements
A hosted registry carries Docker's uptime, while a self-hosted Harbor inherits yours. Production clusters that cannot wait for an image pull need redundant Harbor components, shared storage and a database that fails over, which the harbor-helm HA deployment describes. Multi-zone HA adds hardware, load balancers and on-call coverage, so ask what availability target your deployment actually needs before you size it.
Docker Hub features you actually use
Docker Hub bundles hosted repositories, automated builds, Docker Scout and team features, and some of these are gated to Team or Business plans. Harbor covers private projects, replication, proxy cache, Trivy scanning and audit logs, but not every hosted extra has a direct equivalent. List the features your pipelines depend on today, then price only those, because unused features on either side add cost without value.
Existing Kubernetes and database skills
Harbor runs on Kubernetes or Docker Compose and depends on PostgreSQL, Redis-compatible caching and object storage, so the team must upgrade and back up these components. Harbor v2.15.2 moved the bundled database to PostgreSQL 18 and replaced Redis with Valkey, which shows the upgrade work is continuous. Teams with these skills in house carry less outside effort, while teams without them should price training or a support retainer into the comparison.
How Docker Hub pull limits change the bill
Docker Hub limits unauthenticated pulls to 100 per 6 hours per IPv4 address or IPv6 /64 subnet, and Docker Personal accounts to 200 per 6 hours, according to Docker's documentation on Docker Hub pull usage and limits. The limit applies to the source address, not the team, so a build farm or Kubernetes cluster behind shared NAT can exhaust it even when each engineer's workload is small. Before comparing costs, confirm which of your pulls are anonymous and which are authenticated, and which egress addresses they leave from. Those two facts decide whether the fix is a paid plan, a cache, or both.
A pull-through proxy cache changes the arithmetic. Harbor's proxy cache projects check cached images with HEAD requests, and Harbor's documentation says those checks do not trigger the Docker Hub rate limiter, so only the first fetch of each image consumes pulls from the upstream quota. That moves the cost from Docker's per-account allowance to storage and operations you run yourself: disk for cached layers, the Harbor host and its PostgreSQL database, and the time to monitor and maintain it. Proxy cache projects also get a default 7-day retention policy, so images that are not pulled within that window are removed and will be fetched again on the next request. Set the retention rule deliberately, because a short window increases upstream pulls and a long one increases storage.
Measure before you buy. Pull a week of build and cluster logs or registry access data and count unique image and tag pairs, anonymous versus authenticated pulls, and pulls per source address. Compare that volume with the published limits and with how often the same images are reused. If most pulls are repeats of a small set of base images, a proxy cache with a sensible retention rule will likely remove the pressure for little ongoing cost. If the pulls are mostly unique images from many sources, a paid Docker plan may be the simpler answer. Ask Docker which plan and pull entitlement applies to your account, and confirm the exact pull accounting for your own CI runners before deciding.
How to build the Docker Hub and Harbor cost model with your numbers
This sequence turns vague licensing concerns into a side-by-side model of current Docker Hub spend and self-hosted Harbor cost, built from your own users, pull volumes, storage and engineering hours over the same period.
Inventory users and Docker Hub features in use
Start from your current Docker subscription invoice and admin console. List every paid seat, every private repository, the organization and team structure, the SSO and access controls in use, and any scanning or Docker Scout features your teams rely on. Confirm with Docker which of these features are gated to Team or Business plans, because plan entitlements change and must be checked against the current pricing page and your contract. The output is a feature inventory that maps each item to a Harbor equivalent or a noted gap, such as Trivy scanning in place of a Docker Scout workflow.
Measure pulls per day and per egress IP
Pull logs from CI runners and Kubernetes clusters show where pulls come from. Count pulls per day, group them by egress IPv4 address or IPv6 /64 subnet, and separate authenticated pulls from anonymous ones. Compare the totals with Docker's documented limits of 100 unauthenticated pulls per 6 hours per IPv4 address or IPv6 /64 subnet and 200 per 6 hours for Docker Personal accounts. Record which pipelines are blocked or retried today. The output is a pull profile that shows whether the cost problem is seat count, pull ceiling, or both.
Size image and chart storage with replicas
Query your current registry or Docker Hub account for total stored image and chart size, including every architecture variant and retained tag. Estimate growth from the last several months of pushes. Then add the copies you would keep in Harbor for replication, disaster recovery and any air-gapped or secondary site. Price storage with your cloud or data center rates, not vendor list prices. The output is a storage figure for the first year and a monthly growth rate, both traceable to logs you can show an auditor or finance reviewer.
List the Harbor components you must run
Write down each component the design needs: Harbor core and registry services, the PostgreSQL database, the Valkey cache that replaces Redis in current releases, the Trivy scanner if you enable scanning, the backup target, and the load balancer and TLS termination. Include a second instance if you need high availability, following the Harbor high availability guidance for Helm deployments. For each component, note the compute, storage and licensing it needs. Harbor is Apache-2.0, so there is no license fee, but cloud or hardware costs still apply. The output is a bill of materials that a platform engineer can review line by line.
Estimate engineer hours for operations
Assign hours to install, upgrades, monitoring and on-call. Use the Harbor v2.15.2 release as a worked example: it upgrades the bundled database from PostgreSQL 15 to PostgreSQL 18 on container startup and replaces Redis with Valkey, and its notes recommend a backup and a reindexdb run if index problems appear. Use v2.15.3 as a second example, since it introduced breaking changes around webhooks to internal addresses and signing in content-trust projects. Test both in a staging copy and time the work. These hours recur with each upgrade cycle and should be entered as a yearly figure. The output is a runbook-based hour estimate, not a guess.
Add one-time migration effort
Price the move separately from run costs. Include replication endpoint setup, pull-based replication rules with name and tag filters, proxy cache projects for public images, repointing CI pipelines and Kubernetes pull secrets, and the period when both registries run in parallel. Count testing, rollback planning and developer time spent on retagging. Note any artifacts that need reconstruction, such as signatures or SBOMs, because the OCI referrers API links them to images. The output is a one-time effort list with an hour estimate per item, which you can later convert to cost using your internal rates.
Compare one-time and recurring totals over one period
Place both options on the same timeline, for example a fixed three-year window, so that Docker subscription fees, storage, compute, backup, engineer hours and the migration effort all fall into the same columns. Show one-time costs separately from recurring ones, and show the point where cumulative Harbor cost crosses the Docker cost, if it does. Run the model again with a higher pull volume and with a seat reduction to see which input drives the result. Keep a version of the spreadsheet that records each assumption. The output is a cumulative cost chart with stated assumptions, and a clear view of whether a paid Docker plan kept alongside Harbor is cheaper for some pipelines.
Request written quotes against a fixed scope
Once the model shows which components and hours are needed, send the same written scope to every implementation partner you consider, including DeployOpen. Ask each to state deliverables, assumptions about your environment, the upgrade and support model, and the items that are excluded. Ask whether support is priced as a fixed scope or a retainer. Check each quote against your bill of materials and hour estimates, and reject any line you cannot trace to a component. The output is a set of comparable quotes that plug into the same model without guesswork.
What buyers ask before pricing Harbor against Docker Hub
How much effort does it take to run a self-hosted Harbor registry?
Effort depends mostly on how many people use the registry, how many images and tags you store, and how many clusters or CI runners pull from it. A single-node install with the installer is a different job from a highly available deployment on Kubernetes using the Harbor Helm chart. Ongoing work includes storage capacity planning, garbage collection schedules, backups of the PostgreSQL database and image storage, certificate renewal, identity integration and patching. Ask your team to estimate these hours against your own environment, since no researched figure for your workload is available here.
Can our team run Harbor without an outside partner?
Many platform teams can run Harbor in-house if they already operate Kubernetes or Linux servers, PostgreSQL and object storage, and have an on-call rotation. The harder parts are usually the first upgrade plan, the backup and restore test, and the security configuration for projects, robot accounts and scanning. A services provider such as DeployOpen can plan, implement, harden, back up and document the deployment inside your infrastructure, and provide ongoing support as a retainer. Whether you need that help depends on the skills and capacity you have today.
How long does a migration from Docker Hub to Harbor take, and what drives it?
The main drivers are the number of repositories and tags, the number of CI pipelines and Kubernetes clusters that pull images, how many pull secrets and image references must change, and whether you need to run both registries during cutover. Bulk copying is usually limited by bandwidth and by Docker Hub pull limits, so large exports take longer. No researched duration applies to your estate, so ask for a timeline based on a written inventory of repositories, consumers and integrations.
Does a paid Docker plan still make sense alongside Harbor?
It can, especially when developers need Docker Desktop features, Docker-managed services or Docker Hub as a public source for images you do not host yourself. Harbor's proxy cache project can front Docker Hub, and Harbor's documentation says its cache checks use HEAD requests that do not trigger the Docker Hub rate limiter, so a paid plan may be needed only for specific workflows. Compare the per-user subscription price on Docker's current pricing page with the features you actually use before deciding.
Does Harbor have a license cost?
Harbor is licensed under Apache-2.0, according to its GitHub repository, so there is no license fee for the software itself. Recurring costs come from the infrastructure that hosts it, storage, backup, monitoring, staff time and any support contract you choose. Confirm the license terms of any bundled components, such as the database and cache, in your own review.
How do upgrades such as v2.15.2 and v2.15.3 affect staffing?
Upgrades change the staffing load because they can include infrastructure changes, not just new features. The v2.15.2 release notes say the bundled internal database moves from PostgreSQL 15 to PostgreSQL 18 on container startup and that Redis is replaced with Valkey as the cache backend. The notes recommend a backup before upgrading and a reindexdb run if index problems appear. The v2.15.3 release notes list two breaking changes: webhooks to internal network addresses are blocked by default, and signing unsigned images fails in projects that enforce content trust. Plan a test environment, a rollback path and review time for each minor release.
What should we ask a services provider to include in a quote?
Ask for a written scope listing the deployment target, whether it is cloud, data center or air-gapped, and the integrations with your identity provider, CI systems and Kubernetes clusters. Request deliverables for backup and restore testing, upgrade procedures, security hardening, documentation and any migration from Docker Hub. Ask which tasks are one-time and which recur, what support hours and response expectations are included, and how changes to scope are handled. DeployOpen agrees scope, deliverables and timelines in writing before work starts and does not publish a price list, so a quote follows from that written scope.
When keeping a paid Docker plan alongside Harbor still makes sense
A paid Docker plan stays cheaper or simpler in three situations. The first is a small team with low pull volume that stays well under Docker Hub's limits of 100 unauthenticated pulls and 200 pulls for Personal accounts per 6 hours, with no shared CI runners or cluster nodes behind one IP address. The second is a team that relies on Docker-hosted features it does not want to rebuild, such as hosted private repositories and Docker's own scanning and access tooling, and whose developers already work daily in Docker Desktop. The third is a transition window. While both registries run during cutover, an active subscription lets you fall back to Docker Hub if a replication rule misses tags and keeps existing pull paths working until CI pipelines and Kubernetes pull secrets point at Harbor.
The choice should rest on a feature comparison, not on the plan price alone. Ask Docker for the current feature list of each tier you would consider, then check every gated feature against what Harbor provides: project-level role-based access control, LDAP, AD or OIDC sign-on, Trivy vulnerability scanning, audit logs and replication rules. Confirm with Docker which controls, scanning results and audit history your auditors or customers expect, and whether the tier you would buy includes them. Turn each requirement into a line item with an owner. If a requirement is covered only by the paid plan, that is the strongest case for keeping it, and it should be written down with a review date.
Treat any overlap as temporary and give it an end date. While the subscription and Harbor both run, you pay the recurring Docker fee and Harbor's ongoing costs for servers, storage, upgrades and engineer time, so the overlap adds to the total. Set exit criteria in writing: every active pipeline pulls from Harbor, replication has been verified for the tags you need, and Docker Hub traffic has stopped. Plan Harbor upgrades into the same window, since recent releases changed the bundled database and cache, and the Harbor GitHub releases notes recommend a backup before upgrading. Then cancel or downgrade the plan on that date.
How DeployOpen scopes a fixed-price Harbor implementation
DeployOpen plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure, including Harbor registries. For Docker Hub cost vs self-hosted Harbor, we start from your actual pull volumes, image inventory and cost lines, then agree a written scope before any work begins.
How we scope
- We inventory your repositories, tags, pull sources and the CI and Kubernetes clients that depend on Docker Hub today.
- We size Harbor hosting, storage, PostgreSQL, Valkey and scanning needs against your environment and the components you name.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We install Harbor in your cloud accounts, data center or air-gapped network, with OIDC or LDAP single sign-on configured.
- We configure proxy cache projects for public images and replication rules with name and tag filters for private content.
- We test pull and push paths, Trivy scanning, garbage collection and upgrade steps before cutover, and document each result.
How we hand over
- You receive architecture notes, runbooks for backup, restore and upgrades, and the configuration records for each project.
- We document how to repoint CI pipelines and Kubernetes pull secrets, and how to keep both registries running during cutover.
- We walk your platform and security teams through operations so the registry is run by your own staff.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover Harbor patch and minor releases, including upgrade rehearsals on a copy of your data first.
- Ask any quote to state which Harbor upgrade and security testing tasks are included and which are billed separately.
