Does self-hosted Harbor cost less than Amazon ECR?
Harbor is cheaper than Amazon ECR only in specific estates, and the answer depends on where your image pulls come from. ECR has no license fee for Harbor to replace, so the comparison is not license against license. Harbor itself is Apache-2.0 licensed with no license fee, which leaves infrastructure and people as the two cost lines to compare. ECR bills for stored images and for data transfer, and transfer is the component that most often moves the total. Harbor is more likely to win when a large share of pulls cross regions or leave AWS to reach on-premises clusters or other clouds, when many clusters pull from outside AWS, or when your organization already runs compute, object storage and database operations that can absorb a Harbor deployment at low marginal cost.
Price out Harbor as a set of recurring and one-time components. Recurring costs include compute for the Harbor core services and the bundled Trivy scanner, object storage for layers and Helm charts, a PostgreSQL database, backups and replicas, and the staff time to patch and upgrade. Patch work is not optional: Harbor v2.15.2 migrated the bundled database from PostgreSQL 15 to PostgreSQL 18 on container startup and recommended a backup first, and v2.15.3 introduced breaking changes to webhook and content trust behavior. One-time costs include the installation, identity integration and replication setup. Ask any implementation partner for a written scope that separates these lines so you can see what recurs. Confirm your own egress, storage and pull volumes from the AWS billing reports before you run a model, because no generic figure applies to your estate.
Before you decide, run one check: export the last three months of ECR storage and transfer charges and split pulls by source network. If most pulls come from inside the same region, ECR usually stays cheaper once you count the people who run Harbor. If a large share of pulls comes from on-premises clusters or other clouds, model Harbor with proxy cache and replication in place, and include the cost of the storage and staff that keep the cache current. Ask for the quote to state which Harbor component each price covers, how upgrades are billed, and what support is included. Where the numbers are close, the operating burden often decides the outcome, so weigh the team's capacity to run a stateful registry alongside the bill.
Which cost components change between ECR and Harbor
This table lists each cost component of running Amazon ECR against running self-hosted Harbor, and marks whether it is one-time or recurring. ECR bills storage and data transfer, while Harbor is Apache-2.0 with no license fee, so most of the difference sits in infrastructure, operations and people. Take ECR rates from the AWS pricing page and your own invoices before comparing.
| Cost component | ECR | Self-hosted Harbor |
|---|---|---|
| Registry license or service fee | No separate license. AWS bills the registry through storage and data transfer charges. | Recurring: none for the software, since Harbor is Apache-2.0. Support contracts, if bought, are recurring and quoted separately. |
| Image storage | Recurring, billed per GB stored. Confirm the current rate on the AWS pricing page. | Recurring, billed through the object storage or volume backing Harbor. Growth comes from retained tags and untidy garbage collection. |
| Data transfer | Recurring. Cross-region and internet egress are billed, so pulls from other clouds or on-premises clusters add cost. | Recurring only where your network charges apply. Replication and pulls inside your own network avoid AWS egress, but check WAN and cloud egress costs. |
| Compute for the registry | None to manage. AWS runs the service. | Recurring: VMs or Kubernetes nodes for Harbor components, sized for peak pull and push traffic and vulnerability scanning load. |
| Object storage backend | Included in the ECR storage charge. | Recurring: S3-compatible or on-premises object storage. Replication across sites may add capacity. |
| Database and cache | None to manage. | Recurring: PostgreSQL and the cache backend. Harbor v2.15.2 moved the bundled database to PostgreSQL 18 and Redis to Valkey, so plan upgrade time. |
| Backups and replication | Recurring cost for backing up images if you copy them elsewhere, plus any replication transfer. | Recurring: backups of the database, object store and configuration, plus replication bandwidth and storage at the target. |
| Implementation and migration | One-time: mapping repositories, IAM and CI push targets, usually internal effort. | One-time: installation, identity integration, replication rules, proxy cache setup, and cutover of image references. Ask a partner for a fixed-scope quote. |
| Upgrades, support and internal skills | Low recurring effort on the registry itself. Staff time still goes to IAM policy and lifecycle rules. | Recurring: staff time for upgrades, patching, monitoring, on-call and security advisories. Skills in Kubernetes or Linux, PostgreSQL and object storage are required. |
What moves the cost comparison most
Harbor's cost is mostly fixed infrastructure and staff time, while ECR's cost scales with what you store and move. The six drivers below show which direction each variable pushes the comparison, so you can ask for the right numbers before you decide.
Image and chart volume stored
ECR bills for stored image layers, so storage cost grows with every retained tag, image build and Helm chart version. In Harbor, the same content lands on your own object storage, where the per-gigabyte cost depends on the backend you choose. Ask how many images and chart versions you keep today, how many are untagged or stale, and how fast that count grows each month.
Clusters and regions that pull
Every cluster, region or CI runner that pulls an image adds traffic to the registry that holds it. Pulls from a single AWS region to in-region workloads are the cheapest path for ECR, while pulls from on-premises clusters or other clouds add transfer charges. Count the clusters and regions that pull, and how often each pulls, before you size the comparison.
Cross-region and internet egress
Data transfer out of AWS, whether cross-region or to the internet, is often the largest variable line on an ECR bill. Harbor moves the same bytes, but the charge becomes the bandwidth and transit cost of your own network or data center link. Model egress from your real pull pattern, including replication to other registries, rather than from storage alone.
Required availability and Harbor HA
ECR is a managed service that AWS operates across its own infrastructure, so availability is part of the price. A single-node Harbor is cheap but becomes a pull dependency for production clusters. Running Harbor highly available means extra nodes, a shared database, shared storage and a load balancer, each of which recurs every month. Ask what outage your pipelines and clusters can tolerate.
Skills already on staff
The biggest hidden cost in self-hosting is the time your platform team spends on upgrades, certificates, database maintenance, backups and incident response. If your team already runs Kubernetes, PostgreSQL and object storage well, the marginal effort is smaller. If not, you will pay for training or for an implementation partner. Estimate the hours per month in your own team, not a generic figure.
Retention and scanning requirements
Longer retention, signed images, SBOM storage and per-image vulnerability scans all add storage and compute. In Harbor, Trivy scanning runs on infrastructure you size, and in ECR scanning is billed separately. Confirm how long your policy requires images to be kept, which scans and attestations you must store, and whether an auditor will expect evidence drawn from a specific system.
When Amazon ECR stays cheaper than Harbor
Amazon ECR stays the cheaper option when the registry sits inside one AWS region next to the clusters that pull from it, the image footprint is modest and nobody on the team would run Harbor's servers, database and backups well. In that case the bill is storage plus whatever data transfer the pulls generate, and it recurs without a platform team attached to it. The cost comparison on this page only holds if the workload really stays local. Map which clusters pull, from which regions and accounts, and whether any CI runners or on-premises nodes pull across a boundary, because cross-region and internet transfer is the line item most likely to erase ECR's advantage. Ask AWS for the current ECR pricing for your region and transfer paths rather than relying on general rules of thumb.
ECR is also the simpler choice where IAM already governs access. If your organization manages developers, CI roles and cluster nodes through IAM and the registry's repository policies, adding Harbor means a second identity model: projects, robot accounts and OIDC or LDAP integration that someone must design, rotate and audit. Count that work as a recurring cost, not only the installation. Check whether your current controls cover image scanning and retention policies in ECR before assuming Harbor adds protection you lack. A useful test is to write down the three controls you would need to reproduce in Harbor and confirm whether ECR already meets each one.
Staying on ECR does not rule out Harbor. Harbor's proxy cache can front Amazon ECR as an upstream, and its replication can pull from an ECR endpoint, so a team can keep ECR as the system of record inside AWS while using Harbor in a data center or another cloud. The proxy cache also checks cached images with HEAD requests, which the Docker documentation on pull limits helps explain when comparing Docker Hub traffic. Before adding that layer, confirm that the extra hop does not generate transfer charges that outweigh what it saves, and that Harbor's cache retention settings match how often your images change.
How to build the cost model with your own numbers
This sequence turns the cost components into a three-year model built from your own image volumes, traffic, quotes and staffing, so the comparison with Amazon ECR reflects your estate rather than a generic estimate.
Inventory stored image and chart volume
The platform or registry owner exports the current storage footprint of every ECR repository, split by repository, and records how many images and Helm charts each one holds. Ask the team to note how much of that content is untagged or stale, since that drives how much you must store. Record growth month by month for at least the period your billing data covers. The step is done when you have a baseline gigabyte figure per repository and a growth trend you can extend across three years.
Measure egress by region and destination
Pull the data transfer lines from your AWS billing reports and split them by source region, destination and whether the traffic left AWS to the internet or to another region. Pair this with the clusters that pull from each region so you can tell which pulls cross a billed boundary. Treat cross-region and internet transfer as separate lines, because they are priced differently and only some of them would change after a move. The step is done when every monthly transfer cost maps to a named flow.
List every cluster and CI system that pulls
Build a list of every Kubernetes cluster, build runner, deployment tool and developer workstation group that pulls from or pushes to ECR, including clusters outside AWS. For each one, note its location, how often it pulls, and whether it runs on-premises, where ECR egress would apply on every pull. Mark which consumers would move their image references and which would keep pulling from ECR during a transition. The step is done when the pull inventory accounts for the majority of your measured transfer and you can explain any remaining gaps.
Price Harbor's infrastructure from your own quotes
Ask your cloud account team or hardware vendor for quotes on the compute, object storage, managed or self-run PostgreSQL database, cache, load balancer, backup targets and network links that a highly available Harbor deployment would use. Harbor's installation prerequisites and high-availability Helm guide list the components, so use them to build the bill of materials. Include the object storage capacity that matches your baseline from the first step, plus headroom for growth. The step is done when each component has a quoted or list price tied to a named source, with no figure taken from a general estimate.
Add staff hours for operation and upgrades
Estimate the people cost of running Harbor, covering installation, patching, certificate and identity configuration, monitoring, scanner updates and on-call coverage. Include upgrade work explicitly, because Harbor release notes call for backups first. For example, the v2.15.2 notes recommend a backup before upgrading and a reindexdb run if index problems appear, and the v2.15.2 upgrade also moves the bundled database from PostgreSQL 15 to PostgreSQL 18. Ask your team to estimate hours for each upgrade cycle and to price their time at your internal rate. The step is done when recurring staff time appears as its own line in the model.
Add backup and recovery costs to the model
Price the backup targets for the Harbor database and image storage, including the retention you require and the cost of restoring to a test environment. Treat the pre-upgrade backup as a recurring operational event with its own storage and staff time. Confirm with your compliance and security leads how long backups must be kept, since that setting drives the storage line more than any other. The step is done when backup storage and restore testing are listed as recurring costs with an owner.
Set a three-year view with one-time and recurring lines
Lay out the model over 36 months in a spreadsheet with separate sections for one-time costs such as migration work, initial setup, cutover testing and any licensing or subscription purchases, and recurring costs such as compute, storage, transfer, backup, support and staff time. Model ECR storage and transfer on the same timeline using your growth trend, so both sides use identical volume assumptions. Ask any implementation partner for a fixed-scope written quote so the one-time line is firm. The step is done when the two columns produce a cumulative cost curve you can test against changes in volume, traffic or staffing.
Test the model against sensitivity cases
Vary the key drivers, including storage growth, cross-region traffic, the share of pulls that move to Harbor, backup retention and the staff hours for upgrades, and record how the break-even point shifts. Use one clearly labeled illustrative scenario, for example a cluster set that doubles its pulls, to show how the curve responds. Note where the result depends on AWS pricing that you should confirm with your account team. The step is done when a finance reviewer and a platform lead have both signed off the assumptions and the result shows where ECR stays cheaper.
How the balance shifts by environment
When clusters, CI runners and build hosts all sit in the same AWS region as the registry, the ECR charges that matter most are storage and data transfer, and in-region pulls generally keep transfer costs low. Harbor adds compute, object storage, a database, backups and staff time that ECR does not bill as separate line items. For this estate, Harbor usually has to justify itself on governance, portability or licensing grounds rather than on transfer savings.
- Storage growth: ECR bills stored image data per GB-month, so retention policies and untagged image cleanup drive most of the storage line. Harbor's equivalent cost sits in the object storage backend you provision.
- Transfer in region: Pulls from workloads in the same region as the registry are the cheapest path. Moving Harbor outside AWS would reverse that and add cross-boundary egress.
- Harbor hosting: Harbor runs on EC2 or EKS in your account, so you pay for those instances, load balancers, the database and backup storage.
- Operating time: Upgrades, such as the move to PostgreSQL 18 in Harbor v2.15.2, need a planned backup and a test window, and that engineer time is a recurring cost.
Confirm in your billing data how much of your ECR spend is storage versus transfer, and whether any transfer crosses regions or leaves AWS.
When some clusters run on premises and pull images from AWS, every on-premises pull from ECR can generate data transfer out of AWS, and that charge grows with image size and pull frequency. Placing a Harbor registry on premises, and replicating or caching selected images into it, moves most pull traffic onto your local network. Harbor's own infrastructure then sits in your data center, which shifts cost from cloud billing to hardware, power, facilities and staff.
- Egress growth: On-premises nodes that pull from ECR across the internet are the main driver of transfer charges, so the cost rises with cluster count and deploy frequency.
- Local footprint: A Harbor install needs servers, storage and a database in your facility or private cloud, which are capital or lease costs that recur through refresh cycles.
- Replication traffic: Pull-based replication from ECR into on-premises Harbor still transfers data out of AWS once per synced image, so filters on repository, tag and schedule control how much is copied.
- Proxy cache: Harbor proxy cache projects serve cached copies when the upstream is unreachable, which helps when the WAN link is the weak point.
- Staff skills: Both sides need on-call coverage, so the people cost of running an on-premises registry is often the largest recurring item.
Confirm your data transfer charges for each on-premises path and the image volume pulled per month before you size the local footprint.
When workloads span AWS, Azure, Google Cloud or other providers, each cloud usually runs its own registry, and each one bills storage and egress separately. A single self-hosted Harbor can act as a central store, pulling from or pushing to the other registries through replication endpoints and serving cached copies through proxy cache. The outcome changes when fewer registries, fewer duplicate image copies and fewer cross-cloud pulls outweigh the cost of running Harbor itself.
- Duplicate storage: Copying the same image into several cloud registries multiplies storage charges, while one central Harbor keeps a single managed copy that other clouds replicate from.
- Cross-cloud transfer: Each pull from one provider's registry into another's cluster is billed as egress, so proxy cache reduces repeated transfer for popular base images.
- Supported endpoints: Harbor's documentation lists AWS ECR, Azure Container Registry, Google Artifact Registry and other endpoints, so confirm the exact types you need against the current docs.
- Single control plane: Harbor's role-based access control and audit logs apply to one place, which reduces administration across providers but concentrates availability risk.
- Rate limits: Harbor's proxy cache checks cached images with HEAD requests that do not trigger the Docker Hub rate limiter, which matters when many nodes pull public images.
Confirm which clouds generate the most egress and how many duplicate image copies exist before deciding whether one central Harbor reduces total cost.
Questions buyers ask before comparing ECR with Harbor
Does self-hosted Harbor have a license fee?
No license fee applies to the Harbor software itself, because the project is licensed under Apache-2.0, and the CNCF project page records that Harbor reached the Graduated maturity level on June 15, 2020. The costs that remain are the costs of running it: compute for the Harbor services, object storage for image layers, a PostgreSQL database, backups, monitoring, and the staff who patch and upgrade it. These costs recur every month and grow with the number of images, the number of tags you keep, and how often you replicate or scan. Ask any provider quoting Harbor support to separate the software from the support contract, and ask for the hosting assumptions behind the infrastructure line. Confirm with your own cloud or data center team what storage and transfer will cost in your environment, because no figure applies across all estates.
How much effort does running Harbor take day to day?
Day-to-day effort is mostly routine operation: keeping Harbor on a supported patch line, monitoring the registry, checking garbage collection and replication jobs, reviewing scan results, and rotating credentials. The deployment path you choose changes the workload. The installer runs on a Docker host, while the harbor-helm chart runs on Kubernetes and supports a high availability layout described in Harbor's documentation. The bundled components need attention too. Harbor v2.15.2 moved the internal database from PostgreSQL 15 to PostgreSQL 18 and replaced Redis with Valkey as the cache backend, so those services must be watched after each upgrade. Vulnerability scanning is enabled at install time with the Trivy option. Ask for a written operations runbook, tested backup and restore procedures, and a weekly effort estimate from the implementer, and check the installation prerequisites against your hosts before sizing anything.
Can an internal team run Harbor without outside help?
Yes, if the team already operates Linux hosts or Kubernetes, PostgreSQL-backed services, object storage and TLS certificates, and has a named owner for on-call duty and patching. The skill gap usually sits in the less obvious parts: backup and restore of both registry data and the database, garbage collection scheduling, replication setup across endpoints, and identity integration with LDAP, Active Directory or OIDC. Check the team against the breaking changes in Harbor v2.15.3, where webhooks to internal network addresses are blocked by default and signing unsigned images fails in projects that enforce content trust. Run a short internal skills check on those items before deciding. Outside help tends to be most useful for the first installation and hardening, the first major upgrade, and knowledge transfer. DeployOpen works on fixed-scope engagements and offers retainers for ongoing support, so a team can hand over some tasks and keep others. Ask each provider which tasks they would take on and in what order.
How long does a migration to Harbor take and what does it depend on?
No single duration applies, because the length depends on what you move and how your systems consume it. Start with an inventory of repositories, tags, image sizes, and the Kubernetes manifests, Helm releases and CI pipelines that reference current image paths. Harbor's pull-based replication from an AWS ECR endpoint can filter by repository name, tag, label and resource type, and it can run manually, on a cron schedule, or on push and retag events. An optional per-task bandwidth limit lets you protect other traffic, and that limit, together with the size of the data set, sets how long the copy takes. The cutover then changes image references and CI push targets, and lifecycle policies must be re-created in Harbor because they do not move automatically. Ask the implementer for a written schedule with these phases, the approvals each phase needs, the test environment used, and what is excluded from scope.
What do Harbor upgrades require before and after the change?
Each upgrade needs a backup, a test run in a non-production environment, and a reading of the release notes for every version between your current release and the target. The recent history shows why. Harbor v2.15.2 upgrades the bundled internal database from PostgreSQL 15 to PostgreSQL 18 on container startup, and its release notes recommend a backup beforehand and a reindexdb run if index problems appear. Harbor v2.15.3 fixed a batch of security advisories but introduced two breaking changes, covering internal webhook addresses and signing in projects with content trust. Patch releases for the 2.14 and 2.13 lines followed on October 6, 2026, so an estate on an older line still needs a planned move. Schedule a maintenance window, keep the previous release available for rollback, and verify replication, scanning and authentication after the change. Ask any provider to document the rollback steps in writing before the first upgrade.
What does DeployOpen's fixed-scope work cover compared with recurring support?
Fixed-scope work covers what the written scope lists: planning, implementing, customizing, integrating, hardening, backing up, documenting and handing over a self-hosted platform inside your own cloud accounts, data centers or air-gapped networks. Scope, deliverables and timelines are agreed in writing before work starts, and the quote follows from that scope, because DeployOpen does not publish a price list. Recurring support is a separate arrangement. Retainers cover ongoing support, upgrades and continuous testing, so the recurring cost depends on the frequency and level of service you agree. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue the reports and certifications. Ask for the scope in writing with the included deliverables, the exclusions, the acceptance criteria for handover, and a separate line for any retainer.
When does Amazon ECR stay cheaper than running Harbor?
ECR tends to stay cheaper when your clusters and build pipelines run in one AWS region, most pulls happen inside that region, and no one on the team has capacity to operate another stateful service. In that case you pay for ECR storage and data transfer as you use them, with no servers, database or backup jobs of your own. Harbor becomes more attractive when the cost drivers shift: images must be pulled across regions, clouds or into on-premises clusters, the same images must be replicated to several endpoints, or data residency rules require registry storage in your own facilities. Harbor's proxy cache can also serve a cached copy if an upstream registry is unreachable, which matters for some estates. Model both options with your own pull volumes, storage growth and staff hours, and ask each provider to show the assumptions behind every line.
What to ask for in a written scope
A written, fixed-scope quote for a self-hosted Harbor registry should describe the architecture before it describes effort. Ask for the high availability approach in writing: whether the installer-based deployment or the Harbor Helm chart with high availability is proposed, how the core, registry, jobservice and database components are replicated, and which shared storage backend the registry uses. The storage section should name the backend (for example, S3-compatible object storage on your own infrastructure), the retention settings for untagged manifests and old tags, and when garbage collection runs. Ask who sets the 7-day default proxy cache retention and who approves changes to it, because retention drives storage growth more than any other setting.
The database and backup design is where most of the recurring risk sits. The quote should state which PostgreSQL version the bundled database uses, how upgrades to later Harbor releases will handle database changes, and the backup schedule, retention and restore test frequency for both the database and the image store. Ask for the migration scope to be tied to your ECR endpoint: which AWS accounts and regions are in scope, how the pull-based replication endpoint is authenticated, which repositories and tags are filtered, and which Kubernetes image references and CI push targets change at cutover. Finally, define upgrade and patch responsibilities in a responsibility matrix covering Harbor, its bundled components, the operating system and the hosting platform, and list the handover documents you will receive, such as runbooks, architecture diagrams, backup and restore procedures and access records. Confirm these items with the implementation partner before comparing prices, because they determine the quote.
How DeployOpen scopes a fixed-price Harbor implementation
DeployOpen plans, implements, hardens, backs up and documents self-hosted Harbor inside your own cloud accounts, data centers or air-gapped networks. Engagements start from a written, fixed scope that states which registries, clusters and build pipelines are in and what each cost component will be, so the comparison with Amazon ECR is grounded in your own estate.
How we scope
- Inventory current ECR repositories, image sizes, pull volumes and cross-region traffic to size the Harbor comparison.
- Record which clusters, CI runners and regions pull images, and where egress is billed today.
- Agree in writing which Harbor components, object storage, database and backup targets are included.
- Ask for a quote that separates one-time setup from recurring infrastructure and staff time.
How we build
- Install Harbor in your environment with the bundled Trivy scanner or an external scanner you choose.
- Configure projects, role-based access, LDAP, AD or OIDC single sign-on to match your identity model.
- Set up replication rules and proxy cache projects for upstream registries that your teams actually use.
- Test pull and push paths from each cluster and pipeline before any cutover is scheduled.
How we hand over
- Document the architecture, retention and garbage collection settings, and the backup and restore procedure.
- Provide runbooks for upgrades, including the backup step and database changes called out in release notes.
- Walk your platform and security teams through access control, audit logs and scanning results.
- Deliver evidence of configured controls so your own auditors can assess them independently.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover patching of Harbor releases, including security advisories and breaking changes.
- Schedule periodic restore tests and review of replication and proxy cache behavior with your team.
- Confirm retainer terms and response expectations in the written scope before work begins.
