Choose Harbor for containers and Helm, and Artifactory when you need more than OCI content
Harbor fits self-hosted OCI images and Helm charts, while Artifactory covers more than 60 package types and its paid security tiers. If a renewal, a tier change or a data residency requirement has forced a fresh look at Artifactory, start by listing what your teams actually push and pull. Harbor is built on the open-source Distribution registry and stores container images and Helm charts as OCI artifacts, so a team whose estate is mostly containers and charts has a direct candidate. Artifactory's breadth matters only if you depend on Maven, npm, PyPI or other formats that Harbor does not serve.
The decision turns on four things: your package mix, your scanning requirements, your SSO and high availability needs by JFrog tier, and whether a second tool is acceptable for non-container packages. Harbor's scanning relies on the open-source Trivy scanner enabled at install time with the --with-trivy option, which you should compare against the findings and policy controls your security team uses today. Check which SSO and HA features your current JFrog subscription includes, since those controls differ by tier and determine how much of the replacement you must build. Pulp can cover Maven, npm, Python, RPM and Debian formats through plugins, but it is a separate system with its own operating model.
Before you commit, confirm the exact feature list of your current subscription with JFrog and map each package type to a named owner. If the answer is mostly containers and Helm, Harbor is a credible replacement for that slice. If the answer includes many language ecosystems with strict policy needs, plan for Artifactory to stay in place for those formats or for a two-tool design, and cost both paths before renewal.
Which platform fits which scenario
This table compares Harbor and JFrog Artifactory across common estate types, naming the better fit and the conditions behind each choice. Read each row against your own package mix, security tooling and network constraints, then check the conditions before committing to a migration path.
| Scenario | Better fit | Reason and conditions |
|---|---|---|
| Container-only estate (images and Helm charts) | Harbor | Harbor stores images and Helm charts as OCI artifacts and runs proxy cache and replication. Confirm that every client pulls over the OCI API and that no Artifactory-specific features are in use. |
| Mixed Maven, npm and Python estate | Artifactory, or Pulp alongside Harbor | Harbor does not handle these package types. Pulp adds Maven, npm, Python, RPM and Debian through plugins, but check each plugin's maturity before cutover. |
| Air-gapped network with containers only | Harbor | Harbor replicates into an isolated registry and its installer supports offline transfer. Confirm your transfer process and that image scanning data can be updated inside the enclave. |
| Xray-dependent security program | Artifactory, unless scanning is re-architected | Xray policies, curation and license checks have no direct open-source match. Harbor with Trivy covers image vulnerability scanning only, so confirm which findings your auditors require. |
| Teams already running Harbor | Harbor | Existing projects, robot accounts and replication rules carry over. Plan upgrades carefully: recent Harbor releases changed the bundled database, cache and default webhook behavior. |
| Single-tenant estate with strict data residency | Harbor or Pulp, self-hosted | Both run entirely in your infrastructure, so content and metadata stay inside your boundary. Confirm the storage backend and backup location meet your residency rules. |
| Legacy self-managed Artifactory near end of support | Depends on package mix | If containers dominate, moving them to Harbor first limits the remaining Artifactory scope. If packages dominate, weigh another upgrade cycle against a Pulp rebuild. |
Where Harbor cannot replace Artifactory
Harbor covers one part of an Artifactory estate. It is a container and Helm registry, so Maven, npm, PyPI, NuGet and other language or operating system package formats have no native home in it. Teams that depend on those formats need a second tool such as Pulp, which adds them through plugins, or a decision to keep Artifactory for those repositories during a transition. Before committing, inventory every repository type in your Artifactory instance and map each one to Harbor, Pulp or a different tool. Harbor's project page describes its scope as container images and Helm charts, so treat any other format as out of scope until you have tested it.
Harbor proxy cache projects are not the same as Artifactory virtual repositories. A proxy cache project caches content from one upstream registry, such as Docker Hub or another Artifactory instance, and serves the cached copy when the upstream is unreachable. An Artifactory virtual repository can aggregate several local and remote repositories behind one URL with a defined resolution order. If your CI relies on a single virtual endpoint, you will need to repoint clients to several Harbor project paths or place a routing layer in front of them. Federation between Artifactory instances is also not a Harbor feature. Harbor replication copies content between registries on rules you define, so plan for it as a copy process rather than a shared namespace. Xray-style curation and license policy have no direct open-source match in Harbor or Pulp. Harbor's vulnerability scanning runs Trivy when enabled at install time, which covers image findings, but it does not block downloads by license or by curation policy across formats. Confirm which policies your security and legal teams enforce today and decide whether each one is replaced, moved to another tool, or dropped. Harbor v2.15.3 also introduced two breaking changes, with webhooks to internal network addresses blocked by default and signing of unsigned images failing in projects that enforce content trust. Run your replication, webhook and signing workflows in a staging instance on the version you plan to deploy before you upgrade production.
How JFrog tiers and Harbor deployment modes compare on SSO and HA
If your Artifactory runs as JFrog SaaS, SSO and availability are provided by JFrog's cloud service, so your team has little control over the underlying design. Your work is mainly to confirm what the subscription commits to in writing and to plan how identity and operations move to your own infrastructure if you switch to Harbor.
- Identity connection: Confirm which SSO protocols JFrog Cloud accepts for your plan and whether user provisioning is included. Harbor needs its own OIDC or LDAP/AD configuration, which your team sets up and maintains.
- Availability terms: Ask JFrog for the written availability commitment, failover design and hosting region for your subscription. Do not rely on general marketing statements.
- Data export: Cloud customers cannot use system or repository export, so plan how images and packages leave JFrog before any cutover begins.
- What you take on in Harbor: A complete Harbor deployment with its own identity federation, backups, upgrades, monitoring and failover testing, all running in your cloud account or data center.
Check the SaaS agreement for SSO and uptime language, then compare it with the operating load your team would carry in Harbor.
Self-managed Pro X and Enterprise X subscriptions move SSO configuration and high-availability design into your environment. Your current setup is the starting point, and the tier determines which SSO integrations and HA options JFrog supports for you. Feature boundaries change between releases, so confirm them in writing rather than from older documentation.
- Tier feature matrix: Ask JFrog to confirm which SSO integrations and HA deployment options your Pro X or Enterprise X subscription includes, and for which Artifactory version.
- Current configuration inventory: Document the existing SAML, OIDC or LDAP settings and the group mappings that control repository access. These mappings must be reproduced as Harbor project roles.
- Harbor equivalent: Harbor supports LDAP/AD and OIDC single sign-on, and its projects use role-based access control. Map each Artifactory group to a Harbor role before any user moves over.
- HA responsibility: Harbor's high-availability layout runs on your own Kubernetes or Helm setup, so your team owns the shared storage, database, cache and load balancing tiers, including their sizing and backups.
Test the same login, group and failover scenarios in both platforms before you decide which tier and which deployment you need.
Enterprise+ is the tier where JFrog's multi-site and high-availability capabilities are most likely to matter to your architecture, and where the gap with Harbor is widest. Harbor offers replication between registries, which is a different mechanism from federation. Be precise about which behaviors your teams depend on before you decide what to replace.
- Federation and multi-site scope: Ask JFrog exactly what the Enterprise+ tier provides for multi-site replication or federation, including conflict handling, and which of those behaviors your workflows actually use.
- Harbor replication: Harbor replication rules can run push-based or pull-based, filter by repository name, tag, label and resource type, and run manually, on a cron schedule or on push and retag events. This covers copying content between sites, but it does not provide federation semantics.
- Failover targets: Write down the recovery time and recovery point your organization requires for each site, then test those targets in both platforms during the evaluation.
- What you build in Harbor: Multi-site DNS, certificates, database consistency across sites and the failover runbook are your responsibility.
Map each Enterprise+ behavior your teams use to a Harbor mechanism or record it as a gap that needs a decision.
Harbor's documentation describes a high-availability deployment through its Helm chart, and the goharbor/harbor-operator repository is a separate project for teams that manage Harbor with an operator. The chart and the Harbor application have separate release cycles, so pin both versions and read the release notes before every upgrade. The Harbor high-availability Helm guide is the starting point for the topology.
- Version pinning: Track harbor-helm releases and the Harbor application version separately, and pin both in your GitOps repository.
- Database and cache changes: Harbor v2.15.2 upgrades the bundled internal database from PostgreSQL 15 to PostgreSQL 18 at container startup and replaces Redis with Valkey. Take a backup first, and prepare a reindexdb run in case index problems appear.
- Breaking changes in v2.15.3: Webhooks to internal network addresses are blocked by default, and signing unsigned images fails in projects that enforce content trust. Review webhooks and signing workflows before you upgrade.
- Operator maturity: Confirm the support status and release history of the operator with its maintainers before choosing it over the Helm chart.
- SSO across replicas: Test that OIDC or LDAP/AD logins, sessions and token handling behave the same after a node or pod failover.
Run the upgrade, failover and SSO login tests in a staging cluster from a restored backup before any production change.
Where your images and metadata live under each model
Each deployment model puts container images, Helm charts, package metadata and audit logs in a different place, under a different operator. Read the cards as a set of custody questions: who holds the bytes, who holds the keys, and who produces the evidence when an assessor asks.
JFrog SaaS consumption hosting
In JFrog SaaS, JFrog hosts the repositories, so artifacts sit in JFrog-operated cloud storage and are billed by storage and data transfer. JFrog's pricing page counts consumption against 25 GB included on its Pro plan. Ask JFrog in writing which cloud regions hold your data, where backups and logs are kept, and whether system or repository export is available to you, since the export path for cloud customers is limited.
Self-managed Artifactory in your environment
A self-managed Artifactory subscription runs on servers you operate in a data center or your cloud account, so you control storage location, network paths and patch timing. Your team still owns the database, object storage, backups and upgrades. Confirm which Artifactory version and support window your subscription covers, because each self-managed minor line has a fixed end of support.
Harbor in your own accounts
Harbor keeps container images, Helm charts and scan results in storage and a database you provision, such as your own object store and PostgreSQL. Nothing is sent to a vendor cloud by default. Your team owns high availability, backup and restore, and the upgrade path, including the database and cache changes shipped in recent releases. Confirm where Harbor's replicated copies and proxy cache entries reside.
Air-gapped operation
In an isolated network, the question shifts from where data is hosted to how content crosses the gap. Harbor can receive replicated images inside the enclave, and Skopeo can copy images to a local directory for transfer. Decide who approves each import, how signatures and scan results travel with the content, and whether Artifactory upstream dependencies can be removed without breaking builds.
Identity integration
Access to the registry is only as strong as the identity source behind it. Harbor supports role-based projects and LDAP, Active Directory and OIDC single sign-on, while Artifactory integrates with its own identity and access settings for each subscription tier. Map which groups may push to production projects, confirm how service accounts for CI are issued and rotated, and test revocation before cutover.
Compliance evidence
DeployOpen can prepare the controls, configuration baselines and evidence that a registry supports in an assessment, such as access reviews, audit log retention and scan records. It does not issue audit reports or attestations. Independent auditors and certification bodies make those determinations. Ask your auditor which evidence they will sample, and confirm which logs each platform retains and where they are exported.
How a Docker and Helm move from Artifactory to Harbor works
The sequence moves container images and Helm charts from Artifactory into a self-hosted Harbor registry while keeping pulls working through cutover, with each step closing on a check you can verify.
Inventory repositories, images and consumers
Your platform or DevOps lead lists every Docker and Helm repository in Artifactory, the projects and tags that matter, and every consumer that pulls from them: CI pipelines, Kubernetes clusters, build agents and developer workstations. Record which repositories are local (hosted), which are remote proxies of Docker Hub or other upstreams, and which are virtual aggregations. Non-container package types such as Maven, npm and PyPI are listed separately because they follow a different path. The step is done when you have a written inventory that maps each source repository to a target Harbor project and to the consumers that depend on it.
Take a backup and confirm the current state
Before any change, the platform owner takes a backup of the Artifactory instance or confirms that a recent one exists and can be restored, then records the versions of Artifactory and the clients in use. Harbor's own upgrade guidance also recommends a backup before upgrading, so the same discipline applies to any Harbor version you install. Ask your Artifactory administrator to confirm what export and backup options your subscription tier allows, since self-managed and cloud deployments differ. The step is done when a restore test or a documented backup location is confirmed in writing.
Stand up Harbor in your infrastructure
The platform team installs Harbor in your own cloud account, data center or air-gapped network, following the installation prerequisites and choosing whether to enable the bundled Trivy scanner at install time. Configure TLS, the storage backend, authentication (LDAP, Active Directory or OIDC single sign-on) and the projects that mirror your Artifactory repository layout. Confirm the high availability model you need before go-live, because the Helm-based HA deployment is a separate setup. The step is done when Harbor answers a test push and pull from a sample image and a sample Helm chart stored as an OCI artifact.
Register Artifactory as a replication endpoint and pull content
Create a registry endpoint in Harbor that points at the Artifactory Docker and Helm repositories, then create a pull-based replication rule that copies selected repositories, tags and labels into the target Harbor projects. Use filters to limit scope, and use a bandwidth limit if the link is shared. Run the rule manually first, then on a schedule once the first pass is clean. The step is done when the replicated tag count and digests in Harbor match the inventory for a representative set of repositories.
Configure proxy cache projects for cutover
For the cutover window, create Harbor proxy cache projects whose upstream is Artifactory, so consumers pointed at Harbor can still reach images that have not yet been replicated. Harbor proxy cache projects are read-only for pushes and serve the cached copy when the upstream is unreachable, but they apply a default 7-day retention policy, so review retention before relying on them as a long-term store. Confirm that the Docker Hub upstream remains reachable from Harbor if you also cache public images. The step is done when a test pull through the proxy project returns the expected digest.
Repoint CI credentials and Kubernetes pull secrets
Update CI variables and secrets so pipelines push and pull through Harbor, using robot or service accounts scoped to the right projects. Update Kubernetes image pull secrets in each namespace, change Helm chart references to oci:// addresses on Harbor, and adjust any image references in manifests, Helm values and GitOps repositories. Roll changes out one environment at a time, starting with non-production. The step is done when a deployment in each environment pulls its images from Harbor and the Artifactory access logs show no further traffic from those clients.
Verify digests, signatures and referrers
Compare image digests between Artifactory and Harbor for every replicated repository, not just tags, because a tag can move while the digest does not. Check that signatures and SBOMs attached as referrers survived replication, since the OCI Distribution Specification defines a referrers API for manifests that point at an image, and confirm that your signing tool can still verify them against the Harbor copy. Record any mismatch and resolve it before continuing. The step is done when a sampled set of images passes digest and signature verification and the results are saved as evidence.
Decommission Artifactory content after a hold period
Once consumers have been on Harbor through a full release cycle and no failures are recorded, disable writes to the Artifactory Docker and Helm repositories, keep the backup and retention records your policy requires, and then remove the repositories and any proxy cache dependencies. Non-container packages stay in Artifactory until their own migration to Pulp is finished, so the subscription decision depends on that path. The step is done when the decommission change is approved, the retained backup is verified and the final inventory is signed off by the owners.
Questions buyers ask before switching from Artifactory to Harbor
What drives the cost of moving from Artifactory to Harbor?
The cost depends on how much of your estate is Docker and Helm content, how many CI pipelines and Kubernetes clusters point at Artifactory, and what you keep paying JFrog for during the overlap. The components are the engineering time to plan and migrate, the infrastructure to run Harbor (compute, PostgreSQL, Valkey, and object storage for image layers), backups, and ongoing upgrades. Harbor itself is Apache-2.0 licensed, so there is no license line item. On the JFrog side, ask for the renewal term and whether your current tier bundles features such as Xray, which have no direct Harbor equivalent. Ask any implementation partner for a quote built from a written scope so each component is priced separately.
How long does a move from Artifactory to Harbor take?
The timeline is set by the number of repositories and pipelines that need repointing, not by Harbor's install time. Teams usually run both registries in parallel, using replication or proxy cache projects during cutover, so the main variables are how many image and chart repositories you hold, how many CI credentials and Kubernetes image pull secrets must change, and how long your change approval process takes. Harbor's upgrade notes also matter: v2.15.2 moved the bundled database to PostgreSQL 18 and replaced Redis with Valkey, and the release notes recommend a backup first. Agree a timeline in writing after an inventory of repositories and consumers.
What does the internal team need to provide during the migration?
Your team needs to supply the people who know the consumers of each registry. That means platform engineers who own the CI systems and clusters, an owner for registry credentials and robot accounts, and a security contact who approves changes to scanning and access policy. Someone must also own the Harbor platform after cutover, including backups, upgrades and the Trivy database. Plan for time from these people in the inventory and cutover windows. An external partner can run the technical work, but decisions about access, retention and scanning policy stay with your organization.
Can our own engineers migrate from Artifactory to Harbor without outside help?
Yes, a team with Kubernetes and CI experience can install Harbor from the official installer or the harbor-helm chart and move Docker and Helm content with replication rules. The harder parts are validation and cutover: checking that every pipeline pulls from the new endpoint, handling image signatures, and keeping rollback possible. Harbor's documentation covers each step, and the Helm documentation shows charts pushed and pulled over oci:// references. Decide early whether you want a fixed-scope engagement, a retainer for ongoing operations, or a fully internal project, and document that choice with your change board.
Can Harbor replace Maven and npm repositories from Artifactory?
No, Harbor is a registry for container images and Helm charts, so it does not serve Maven, npm, PyPI or other language packages. For those formats you need a separate repository manager, such as Pulp with its Maven, npm and Python plugins, or a self-hosted forge package registry for simpler cases. Plan these as a second workstream with its own inventory and upstream remotes. Before you commit, confirm each plugin's maturity and the features your build tools rely on, because some Pulp plugins are still pre-1.0 or in tech preview.
How do Xray findings translate to Trivy results in Harbor?
Trivy in Harbor performs static vulnerability analysis of images, which covers much of what teams use Xray for, but it does not replicate Xray's full feature set. Trivy is enabled with the --with-trivy option at install time, or you can connect Harbor to an external Trivy instance. Map each Xray policy and watch to a Harbor project setting and a Trivy severity threshold, then check how findings are reported and retained. Xray features such as curation and license policy have no direct open-source match, so list them separately and decide how you will cover them, for example with DefectDojo for tracking findings.
What should we confirm with JFrog before cancelling Artifactory?
Confirm the contract end date, the notice period and the data export rights for your tier. Ask whether repositories can be exported with metadata, which depends on whether you run self-managed or SaaS, and whether JFrog Cloud customers can use system export at all. Check the storage and data transfer usage on your bill, the support terms for the overlap period, and any retention obligations for logs or artifacts you must keep. Also confirm how long your self-managed version remains supported, since the support window determines how long you can run both platforms safely.
Does moving to Harbor change the compliance evidence we need?
Yes, your evidence changes because the system of record moves from JFrog to a platform you operate. You will need to document access control, audit logs, backups, upgrades, and vulnerability scanning settings for Harbor. Harbor provides role-based access control, LDAP, AD and OIDC single sign-on, audit logs and garbage collection, but how those controls map to your framework is your decision. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or certification.
How DeployOpen evaluates and migrates from Artifactory to Harbor
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, upgrades and documents self-hosted open-source platforms inside the client's own infrastructure. For JFrog Artifactory vs Harbor, we start by mapping which Docker and Helm workloads can move to Harbor and which package types need a separate path before any migration work begins.
How we scope
- Inventory every Artifactory repository, separating Docker, Helm and non-container package types before choosing a target.
- Record which JFrog tier, deployment model and features your estate uses, including SSO, HA and Xray-based scanning.
- Engagements are fixed-scope, with scope and deliverables agreed in writing before any work starts.
How we build
- Install Harbor in your environment, configure projects, RBAC, OIDC or LDAP sign-on, and Trivy scanning according to agreed scope.
- Configure replication rules or proxy cache projects, then test pulls, pushes and image pull secrets against real CI pipelines.
- Test rate limit behavior, garbage collection, backup restore and failover against documented acceptance criteria before cutover.
How we hand over
- Document registry architecture, replication rules, retention settings, access model and the runbook for upgrades and backups.
- Deliver evidence of controls and configuration to support your internal or external compliance assessment, without issuing attestations.
- Walk your platform and security teams through operations, including the Harbor upgrade and backup steps called out in release notes.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Track Harbor patch releases and breaking changes, and plan upgrades with your change process before they reach production.
- Confirm open questions, such as non-container package handling, with you in writing before scope changes are accepted.
