Self-hosted Amazon ECR alternative for hybrid and multi-cloud

Why hybrid estates outgrow ECR and how one self-hosted Harbor registry fits

A self-hosted Harbor registry can serve as the single internal registry for clusters on premises or across several clouds, replicating images out to cloud registries where they are needed and caching upstream images locally. Teams that push from one place and pull from many usually find that a registry per cloud multiplies credentials, scanning policies, retention rules and audit trails. Amazon Elastic Container Registry is billed for storage and data transfer, and it is strongest when the clusters and pipelines that pull from it sit inside AWS. Once workloads run on premises or in other clouds, every pull from ECR becomes a cross-boundary transfer that someone pays for and must account for.

Harbor extends the open-source Distribution registry with projects, role-based access control, LDAP, AD or OIDC single sign-on, vulnerability scanning with Trivy, audit logs and a REST API. Its replication endpoints include AWS ECR, Azure Container Registry, Google Artifact Registry and Docker Hub, and its proxy cache projects can front those same upstreams, serving the cached copy if the upstream is unreachable. The practical decision is which direction each image should flow: push-based replication to cloud registries for workloads that run there, pull-based replication or proxy cache for images that originate in the cloud. Confirm with your own network team which clusters can reach which registries and whether egress from each cloud is metered for your account.

Before committing, ask three questions. Which of your clusters pull images that originate in ECR, and does that traffic justify keeping ECR as a source? Who will operate Harbor, including upgrades, backups of its database and object storage, and the Kubernetes platform beneath it? Do your compliance obligations require a registry that you control end to end? If the answer to the first question is mostly yes, a hybrid pattern with ECR still in place may be the better fit, and the sibling comparison pages cover that trade-off in detail.

What a hybrid registry must do before it can replace per-cloud registries

A registry that serves on-premises and multi-cloud clusters has to meet the same requirements in every location. The cards below set out what Harbor and the OCI Distribution Specification provide, and what your own environment must confirm before you retire per-cloud registries.

One pull path for every cluster

Every cluster, whether on premises or in a cloud account, should pull images and charts from the same hostname. The OCI Distribution Specification requires every conforming registry to support pull, which gives a common baseline, but the hostname, TLS chain and network route are your responsibility. Confirm that each cluster can reach the Harbor endpoint across its firewall and egress path, and that node runtimes trust your internal certificate authority.

OCI images and Helm charts together

Harbor stores container images and Helm charts as OCI artifacts, so one API and one access model cover both. Since v2.8.0 Harbor no longer bundles ChartMuseum, so existing chart repositories must be pushed again as OCI artifacts and clients must switch to oci:// references. Check that your CI pipelines, Helm clients and admission policies use the new references before cutover.

Replication and proxy caching across registries

Harbor replication can push or pull between Harbor and cloud registries, including AWS ECR, Azure Container Registry and Google Artifact Registry, and proxy cache projects serve upstream images locally. Rules can filter by repository, tag and label, and can run on a schedule or on push. Confirm which registries hold the source of truth, which way each rule runs, and how bandwidth limits apply on your WAN links.

Pull-through cache for rate-limited upstreams

Clusters that pull from Docker Hub share one outbound IP address, so unauthenticated pulls can hit the published limit quickly. A Harbor proxy cache project fetches each image once and serves later pulls locally, and Harbor's documentation says its cache checks use HEAD requests that do not count against the Docker Hub limiter. Confirm your Docker Hub credentials, the upstream egress address, and what happens to cached images when the upstream is unreachable.

Access control with SSO and audit logs

Harbor provides projects with role-based access control, LDAP or Active Directory and OIDC single sign-on, and audit logs. Each cluster and CI system needs its own robot or service account so that access can be revoked without affecting others. Confirm that your identity provider groups map to Harbor roles, that audit logs leave the registry for retention, and that cloud IAM roles used for replication are scoped to the repositories they need.

Vulnerability scanning on every registry

Harbor can run Trivy during installation, through the --with-trivy option, or connect to an external Trivy instance or other scanners. Scanning results should gate deployment in the same way for on-premises and cloud-hosted images, because a replicated image carries its vulnerabilities with it. Confirm your scan policy for pulled and replicated images, the vulnerability database update schedule in air-gapped sites, and who acts on findings.

Which registry setup fits each environment

When every cluster runs in your own data centers, the registry is usually the one shared component that all clusters pull from. A single self-hosted Harbor instance, placed close to the clusters, is the natural fit. Harbor extends the open-source Distribution registry with projects and role-based access control, LDAP/AD and OIDC single sign-on, vulnerability scanning, garbage collection, audit logs and a REST API. Distribution alone gives you the OCI push and pull API but none of those identity, scanning or audit features, so you would need to add them around it.

Replication is optional here: with no other registry to sync with, you may only need projects and access control. Add replication rules later if a second site appears.
Scanning and audit: Harbor's Trivy integration and audit logs cover the evidence questions that most auditors ask first.
Air-gapped transfers: Skopeo can sync images into an internal registry or a local directory when the network has no route to the internet.
Storage and backup: plan for image storage, the database and backups as recurring operating work.
Cluster access: confirm how node pull credentials are issued and rotated for each cluster.

Confirm your storage backend, the Harbor release line you will run and your upgrade window with your platform team before you commit to a layout.

Self-hosted options compared with Amazon ECR for hybrid use

This table compares self-hosted registry options against Amazon ECR for estates that run clusters on premises or across several clouds. Read each row against your own cluster locations, package formats and scanning needs, and note where ECR remains the simpler choice inside AWS.

Option	How it meets the constraint	Trade-offs
Harbor	Stores container images and Helm charts as OCI artifacts, replicates to and from AWS ECR, Azure Container Registry, Google Artifact Registry and Docker Hub, and proxy-caches those registries for pulls from any cluster.	Your team runs the servers, database, storage and backups. Trivy scanning and garbage collection are included, but retention and cache sizing need deliberate planning.
Distribution registry (open source)	Implements the core OCI registry API with a small footprint, suitable for a single site or a simple internal pull target.	Provides no built-in RBAC, replication, scanning, auditing or web interface. Teams usually need to add those layers themselves, which Harbor already packages.
Pulp	Manages container content alongside Maven, npm, Python, RPM and Debian packages through plugins, giving one repository layer for mixed estates.	Container workflows are not its primary focus compared with Harbor. Confirm which plugins and formats your build pipelines need before choosing it for images.
Gitea or Forgejo packages	Host container, Helm, Maven, npm, PyPI and other formats in the same forge as your source code.	Their documentation does not describe proxying or caching upstream registries such as Docker Hub or Maven Central, so they do not reduce external pull rates or serve as a cache across clusters.
Amazon ECR (managed, inside AWS)	Integrates with AWS IAM for access control, so workloads running in AWS can pull without operating registry servers.	Works best for workloads inside AWS. Clusters outside AWS need credentials and network paths to ECR, and replicating across clouds or on premises adds cost and configuration. Confirm current scanning and replication features in AWS documentation.

How replication and proxy caching keep images close to every cluster

Replication and proxy caching are two different tools, and hybrid estates usually need both. Replication copies stored artifacts between registries on purpose: a Harbor replication rule can be push-based, sending images from the Harbor instance to an endpoint, or pull-based, fetching images from a remote endpoint into Harbor. Endpoints can include another Harbor, Docker Hub, AWS ECR, Azure Container Registry, Google Artifact Registry, GitHub Container Registry and JFrog Artifactory. Rules filter by repository name, tag, label and resource type, so a team can replicate only the images a given cluster needs. Triggers are manual, cron-based, or fired on push and retag events, and each task can carry an optional bandwidth limit so that a replication run does not saturate a WAN link to a remote site. Confirm the exact filter syntax and trigger behavior against the replication rule documentation in your Harbor version before you build the rule set.

Proxy cache projects work differently. A proxy cache project in Harbor fetches an image from an upstream registry the first time a node requests it and keeps a local copy, so clusters on premises or in a second cloud pull from Harbor rather than across the internet. The project is read-only for pushes, the cached copy is served if the upstream is unreachable, and cached content gets a default 7-day retention policy that you can change. Harbor's documentation says its cache checks cached images with HEAD requests, which do not count against the Docker Hub pull limit. That matters because Docker Hub caps unauthenticated pulls at 100 per 6 hours per IPv4 address or IPv6 /64 subnet, and a cluster with many nodes behind one NAT can exhaust that quota quickly. Authenticating the proxy cache to Docker Hub is the usual remedy, and the limits for authenticated accounts should be checked on Docker's usage page before you size the plan.

How to deploy Harbor across hybrid sites

This sequence takes a team from install planning to a working Harbor registry that serves on-premises and cloud clusters, replicates images to and from cloud registries, and runs on a schedule the team can operate. The output is one governed registry with cached upstreams, tested image references and a backup and cleanup routine in place.

Confirm prerequisites and choose the install method
Platform engineering and the security lead agree on the install method before any server is provisioned: the Harbor installer on Docker Compose for a single-host deployment, or the Helm chart for a Kubernetes deployment with high availability. Check the installation prerequisites for CPU, memory, disk and the container runtime against the chosen method, and confirm the Harbor release you will pin, noting that v2.15.2 upgrades the bundled database to PostgreSQL 18 and replaces Redis with Valkey. Done means a written install decision and a pinned version recorded in your change log, with the target hostnames and TLS certificate sources agreed.
Place Harbor on infrastructure that meets your availability needs
Infrastructure and network teams choose where the registry runs, ideally in a site that all clusters can reach with low latency. For high availability via Helm, confirm the cluster, the shared storage backend and the external database and cache options against the Harbor high availability guide, and decide whether the bundled database is acceptable for your recovery targets. Done means a reachable Harbor endpoint on your chosen hostname, with a load balancer or ingress path tested from each on-premises and cloud network that will pull images.
Configure SSO, RBAC and projects
The identity team connects Harbor to your directory through LDAP/AD or OIDC single sign-on, and platform engineering creates projects that map to teams or environments, assigning roles per project. Keep one project per trust boundary so that production and development images, and robot accounts for CI and cluster pulls, stay separated. Done means a test user from each group can log in and see only their projects, and a robot account can pull but not delete.
Enable Trivy or an external scanner
The security team decides whether Harbor runs the bundled Trivy scanner, enabled at install time with the --with-trivy option, or connects to an external Trivy instance or another scanner. Set a scan-on-push policy for production projects and confirm that scan results appear on a pushed test image. Done means a deliberately old test image shows findings in the Harbor interface, and the team knows which severity threshold blocks pulls.
Create replication endpoints, rules and proxy cache projects
Platform engineering registers endpoints for each cloud registry in use, such as AWS ECR, Azure Container Registry or Google Artifact Registry, and creates pull-based or push-based replication rules filtered by repository name and tag. Create proxy cache projects for Docker Hub and other upstreams so cluster pulls go through Harbor, and review the default 7-day cache retention policy. Before enabling any webhook, note that v2.15.3 blocks webhooks to internal network addresses by default, so confirm the destinations you need and set any exception deliberately. Done means a manual replication run succeeds and a pull through a proxy cache project returns the image.
Cut over image references and CI push targets
Application and platform teams update Kubernetes manifests, Helm values and CI pipelines to reference Harbor hostnames, starting with a non-production cluster. Confirm that each cluster can pull with its robot credentials, and that signing or content trust rules in your projects are tested before enforcing them, since v2.15.3 makes signing unsigned images fail in projects that enforce content trust. Done means a rollout in each target environment pulls from Harbor, and the previous registry is kept read-only until the rollback window you agree has closed.
Schedule garbage collection and backups
Operations sets a garbage collection schedule so deleted tags and blobs release storage, and a backup routine for the database, the configuration and the image storage backend. Take a backup before any Harbor upgrade, including minor patch upgrades to the 2.15 line, and run a restore test in a separate environment. If index problems appear after the PostgreSQL 18 upgrade, follow the release notes and run reindexdb as they recommend. Done means a recorded backup has been restored successfully to a test instance and the schedule appears in your operations calendar.

Questions buyers ask before replacing ECR across sites

What drives the cost of replacing ECR with a self-hosted Harbor registry?

The cost depends on who pays for what, and it splits into one-time work and recurring running costs. On the ECR side, you pay AWS for storage and data transfer, which grows with image volume and with pulls that leave the region or the cloud. On the Harbor side, you pay for the servers or Kubernetes nodes, object storage for image blobs, a PostgreSQL database, backups, monitoring, and the engineers who patch and upgrade the platform. Ask any integrator for a quote built from these components, with the assumed image volume, pull pattern and backup retention written out. Ask your own team to size egress from each cluster, because that is often the largest variable.

How long does a Harbor migration across sites usually take?

The timeline depends on the number of repositories, the number of clusters that pull from them, how many CI pipelines push to ECR, and how much cutover coordination your change process requires. No duration is set by the product itself, so treat any single number with caution. A practical approach is to stand up Harbor, replicate a pilot set of repositories from ECR using pull-based replication, cut one non-critical cluster over, and then expand. Harbor's replication rules let you filter by repository name and tag, which keeps the first wave small. Agree the timeline in writing against a defined scope before work starts.

What does our team need to provide before an implementation starts?

Most of the input is decisions and access that only your organization can provide. You need to define which clusters and sites will pull from the registry, which AWS accounts and regions hold ECR repositories, and which identity provider will handle single sign-on. You also need storage and network capacity in each site, DNS names and TLS certificates, a backup target and retention rule, and the list of CI systems that push images. A named owner for on-call and change approvals is also important. Confirm these inputs with the integrator in the written scope, since they set the work that can be done.

Can our own platform team run Harbor without an outside partner?

Yes, many teams run Harbor themselves, provided they already operate Kubernetes or a similar container platform, a PostgreSQL database and object storage. Harbor is open source under Apache-2.0, and its installation prerequisites and HA Helm deployment guide describe the components involved. The harder part is the ongoing work: patch releases, upgrades that change bundled components, and incident response. Recent releases show why this matters. Harbor v2.15.2 moved the bundled database from PostgreSQL 15 to PostgreSQL 18 and replaced Redis with Valkey, and its release notes recommend a backup before upgrading. Honestly assess whether your team has the capacity for that cycle before deciding.

Is Amazon ECR still cheaper for workloads that stay inside AWS?

For workloads that run in AWS and pull within the same region, ECR is often the simpler and cheaper option, because you avoid running registry servers, databases and backups. Harbor starts to pay off when you run clusters on premises or in several clouds, when cross-cloud or internet pulls become significant, or when you need one policy and audit trail across providers. Harbor's proxy cache can also reduce repeated pulls from upstream registries, and it serves the cached copy if the upstream is unreachable. Compare both models with your actual egress and storage bills, not with list rates, and ask for a quote that shows each component.

How does Harbor handle high availability and upgrades?

Harbor can be deployed for high availability through its Helm chart, and the HA guide describes running several replicas of its components behind load balancing with shared storage and a highly available database. Your design must still cover the external dependencies: a resilient PostgreSQL service, a cache, object storage and DNS. For upgrades, Harbor publishes patch releases on several supported minor lines, so you can plan staged moves between versions. Check the release notes for each target version, since breaking changes occur. Harbor v2.15.3 blocked webhooks to internal network addresses by default and changed content trust signing behavior. Ask any integrator to document the upgrade runbook, backup procedure and rollback path as part of the scope.

What does Harbor need for security controls and audit evidence?

Harbor provides role-based access control within projects, LDAP, Active Directory or OIDC single sign-on, vulnerability scanning through Trivy, garbage collection and audit logs. Those are features you configure and operate, not outcomes an assessor will accept on their own. Auditors will want evidence of who can push and pull, how access is reviewed, how scans are reviewed and retained, how the platform is patched, and how backups are restored. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications. Independent auditors and certification bodies make that determination. Confirm the evidence list with your assessor before implementation.

Evidence auditors and platform owners ask for

Auditors and platform owners want proof that the registry replicates, caches, scans and recovers the way the design says it does. The items below connect the hybrid estate's configuration to records that can be inspected, sampled and repeated during an assessment.

Replication and cache configuration exports

Export every replication rule and proxy cache project as configuration, not screenshots. Record the direction (push or pull), the endpoint, the name, tag and label filters, the trigger (manual, cron, or push and retag events) and any bandwidth limit. Check that each cache project's retention policy is set on purpose, since the default for proxy cache is 7 days, and confirm that the upstream credentials are stored with the registry and rotated under a documented procedure.

Access control and audit log samples

Collect a sample of project membership, role assignments and single sign-on group mappings, along with audit log entries for pushes, deletions and permission changes. Confirm that identities come from LDAP/AD or OIDC rather than local accounts, that robot accounts are scoped to single projects, and that log retention matches your policy. Auditors usually test whether a departed engineer's access was removed and whether the removal shows up in the log.

Scanning reports and enforcement policies

Keep the Trivy scan reports for the images in production, along with the project settings that block pulls of images with unresolved high-severity findings. Record the scanner version in use, since Harbor v2.15.4 bundles Trivy 0.75.0, and show how scanner database updates are handled in an air-gapped segment. Where a scanner is external or a different tool is used, document which one produced each report.

Backup and restore test records

Keep dated records of backups for the registry database, the image storage backend and the configuration, and of restores performed into a separate environment. Each record should name the Harbor version, the database version and the person who verified the restored registry could pull an image by digest. Harbor v2.15.2 moved the bundled database to PostgreSQL 18, so restore tests should cover the version you actually run, and the release notes recommend a backup before any upgrade.

OCI conformance status and referrer support

State the registry's conformance position from its source, not from memory. The OCI Distribution Specification requires pull support, and registry providers can self-certify by submitting results to the conformance project. Harbor's repository runs the OCI distribution conformance tests in CI, which is evidence of testing but not a certification. Ask the platform team to record the spec version under test, which is 1.1.1 at the time of writing, and whether the referrers API is exercised for signatures and SBOMs.

Change and upgrade records

Keep a dated log of every Harbor upgrade with the release notes reviewed, the breaking changes assessed and the test outcome. Recent patch releases introduced changes that affect operations, such as webhooks to internal addresses being blocked by default in v2.15.3, so a change record should show who reviewed those changes and what was adjusted. This log is the evidence that patching happens on a schedule rather than only after an incident.

Where Amazon ECR still fits better inside AWS

Amazon ECR remains the simpler choice when the workloads that pull and push images run almost entirely inside one AWS account and region structure. Its main advantage is that access is governed by IAM policies and roles your team already manages, so an EKS node role or a CodeBuild project can pull without a separate registry credential or identity integration. There are no registry servers to size, patch, back up or upgrade, and no database or garbage collection job for your team to schedule. That work is real, and a self-hosted Harbor deployment adds it: a Kubernetes control plane for Harbor, a PostgreSQL database, a cache, object storage for layers, backups and a scanner. Before you move anything, ask your platform team to estimate the hours it spends on the registry today, and compare that with the hours a Harbor estate would need for upgrades and restores.

A mixed model is often the practical answer for estates that have both AWS-only and off-AWS clusters. In that model, ECR stays the registry for AWS-only build and deploy paths, and Harbor acts as the hub that receives images from CI, replicates selected repositories to ECR and to other clouds, and serves on-premises clusters. Harbor's replication endpoints include AWS ECR, so the hub can push to the ECR registries that AWS workloads already use, with filters on repository name, tag or label to limit what is copied. Pull-based replication or proxy cache can run in the other direction. Confirm the exact endpoint settings, IAM permissions and token refresh behavior against the Harbor replication endpoint documentation before you rely on them in production.

How DeployOpen deploys Harbor under hybrid constraints

DeployOpen plans, implements, hardens, documents and supports self-hosted Harbor inside your own infrastructure, whether that is on-premises clusters, your cloud accounts or an air-gapped network. The work starts with a written scope that defines which clusters, clouds and registries Harbor must serve and how images move between them.

How we scope

Inventory every cluster, cloud registry and CI pipeline that pushes or pulls images today.
Agree in writing which Harbor projects, replication rules and proxy caches are in the engagement.
Confirm with your team which upstream registries, such as ECR or Docker Hub, Harbor must mirror or cache.
Define the network paths, DNS names and certificates that each site needs, including air-gapped segments.

How we build

Deploy Harbor with the installer or Helm chart in the environment you choose, with high availability where the scope requires it.
Configure replication endpoints, filters and triggers, and test pull-based and push-based rules against real repositories.
Set up proxy caches with retention policies and check how Harbor behaves when an upstream registry is unreachable.
Integrate identity through LDAP, AD or OIDC, enable vulnerability scanning with Trivy, and test access controls.

How we hand over

Document the architecture, replication topology, backup and restore procedures, and upgrade steps for your operators.
Walk through a restore test and a Harbor upgrade plan, including a backup before each upgrade, with your platform team.
Deliver runbooks for cutting over image references and CI push targets, with rollback steps written down.
Hand over configuration as code where it fits your toolchain, so changes can be reviewed and repeated.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, scoped in writing.
Review Harbor release notes for breaking changes, such as webhook and content trust behavior, before each upgrade.
Confirm with DeployOpen during scoping which upgrade and patch cadence your retainer will cover.