Does replacing Artifactory with Harbor and Pulp lower cost?
Replacing Artifactory removes the license line, but it does not remove the cost. Before you act on a renewal or a pricing change, the answer depends on how your Artifactory bill is built and on which components you would take on yourself. JFrog's pricing page shows that SaaS consumption counts storage plus data transfer against 25 GB included on the Pro plan, so a team whose images and packages grow past that allowance pays for both volume and egress. Self-managed editions are priced by server count, which means a change in the number of nodes for high availability or disaster recovery changes the subscription directly. Neither price is quoted here. Ask JFrog for the exact figures against your current storage, transfer and server counts, and for the terms that apply at renewal.
Harbor is licensed under Apache-2.0 and Pulp is licensed under GPLv2+, so neither carries a per-seat or per-server fee. The costs move to your budget: the servers and object storage that hold image layers and package blobs, the PostgreSQL databases that Harbor and Pulp depend on, backups, network egress, and the upgrade work that comes with each release line. Recent Harbor releases, such as v2.15.2, changed the bundled database and cache, and v2.15.3 introduced breaking changes to webhooks and content trust, so each upgrade needs test time and a backup. Those are recurring costs. Implementation, migration and parallel running during cutover are one-time costs that depend on how many repositories you move and how much CI configuration must change.
The outcome depends on three factors: your content volume, the Artifactory edition you run today, and whether your team can operate Harbor and Pulp without a vendor escalation path. Teams with heavy Maven, npm or Python traffic should price the engineering time needed for the Pulp plugins, because several are still 0.x releases. Ask any implementation partner for a written, fixed-scope estimate that lists each component, who pays for it, which costs recur, and what would change the total. Compare that estimate with your current renewal before you commit.
Which cost components move when you leave JFrog Artifactory
This table maps each cost component of running JFrog Artifactory against the matching cost on self-hosted Harbor and Pulp, and marks whether it is one-time or recurring. Use it to build a quote request, since the commercial side is billed by consumption or server count and the self-hosted side is paid mainly in infrastructure and people. The main takeaway is that the largest self-hosted costs are recurring engineering time for upgrades and operations, so budget for them before comparing subscription totals.
| Cost component | JFrog Artifactory (commercial side) | Harbor and Pulp (self-hosted side) | One-time or recurring |
|---|---|---|---|
| Subscription or license | SaaS consumption on storage and data transfer, or self-managed subscription priced per server; check the JFrog pricing page for current terms | Harbor is Apache-2.0 and Pulp is GPLv2+, so there is no license fee; support contracts are optional and must be quoted separately | Recurring on the commercial side; none on the open-source side |
| Servers and compute | Included in SaaS consumption, or hosted by you for self-managed editions | Harbor and Pulp run on your own virtual machines or Kubernetes nodes; plan separate nodes for API, content and workers in Pulp | Recurring, driven by request volume and redundancy |
| Object storage | Storage and egress billed against the included allowance on the JFrog pricing page | Your own S3-compatible or block storage, sized to image layers and package content retained | Recurring, grows with retention policy |
| Database | Managed by JFrog in SaaS; included in self-managed packaging | Harbor's bundled PostgreSQL 18 (from v2.15.2) and Valkey cache, or an external database you operate; Pulp requires PostgreSQL as its task source of truth | Recurring for operation; backups need an owner |
| Backup and recovery | Included in SaaS terms; confirm restore testing and retention in your contract | You design and test backups of the database, object storage and Harbor configuration; the v2.15.2 release notes recommend a backup before upgrading | Recurring, and a one-time design effort |
| Vulnerability scanning | Xray is a separate higher tier or add-on; confirm which bundle includes it | Trivy is open source and enabled at install with the --with-trivy option; you run it and tune its vulnerability database updates | Recurring operation; no license line |
| Implementation and migration | Typically limited to repository configuration and CI repointing on the commercial side | Installation, replication or proxy cache setup, Pulp plugin configuration, cutover and rollback testing; scope it in writing | One-time, fixed scope recommended |
| Upgrades and support | Vendor-managed in SaaS; self-managed upgrades are your work within the supported version window | Harbor patch and minor releases, the v2.15.3 breaking changes, and Pulp plugin updates across 0.x and 1.0+ releases are your work or a retainer | Recurring, and the main hidden cost |
| Internal skills and staffing | Administrators familiar with Artifactory APIs and JFrog tooling | Kubernetes or Docker operations, PostgreSQL administration and Pulp plugin knowledge; confirm skills before cutover | Recurring as staff time |
How JFrog bills SaaS and self-managed deployments
JFrog bills Artifactory in two different ways, and the one you are on determines which costs you can actually control. On SaaS, the bill follows consumption: storage plus data transfer, measured against an allowance. JFrog's pricing page counts storage and data transfer against 25 GB included on its Pro plan, so anything beyond that allowance is metered. On self-managed subscriptions, the unit is the server, so the cost is set by how many Artifactory nodes your topology needs, whether or not they are busy. These are different risks: the SaaS model rewards keeping data close to where it is consumed, while the self-managed model rewards consolidating nodes.
Certain usage patterns push the SaaS bill up quickly. Large image layers pulled across regions generate egress on every cold pull, and CI pipelines that re-download the same dependencies on each run multiply that transfer. Retention of old images and packages grows storage on the same meter. On the self-managed side, a multi-server high-availability topology, with separate nodes for availability, is the main driver of the server count, and a staging or disaster recovery copy adds subscriptions of its own. Confirm with JFrog whether each of these nodes is licensed separately, and whether non-production instances carry their own entitlement.
Before you model anything, pull your current invoice and the entitlement terms from JFrog. Export the last several months of storage and transfer usage for SaaS, or the server count and subscription tier for self-managed, and ask JFrog to confirm in writing what the included allowance, overage rates and server definitions cover. Those figures are the baseline for every Harbor and Pulp comparison that follows. Without them, any cost model compares your guess against a number you have not verified.
What moves the Artifactory comparison most
The gap between a commercial Artifactory subscription and a self-hosted Harbor and Pulp estate depends on a few inputs more than on list prices. Each card below names one input, what it changes in the total, and what to confirm before comparing numbers.
Storage and transfer volume
Storage and data transfer are the meter that SaaS consumption pricing bills against, so volume is the first input to pin down. JFrog's pricing page counts storage plus data transfer against 25 GB included on its Pro plan. In a self-hosted estate, the same volume becomes object storage capacity, backup copies and network egress from your own cloud or data center. Measure current storage and monthly transfer from your own usage reports, and ask how the vendor's quote handles growth over the renewal term.
Number of package formats in use
Harbor covers OCI content, meaning container images and Helm charts, while Pulp covers Maven, npm, Python, RPM, Debian and other formats through plugins. Each format you run adds a plugin to test, upgrade and monitor, and several Pulp plugins are still 0.x releases. Count the formats your build pipelines actually pull and push, not the formats the vendor supports. A short list of two or three formats keeps the self-hosted scope small, while a long tail of niche formats raises engineering time more than any license line.
Required HA and availability tier
Availability design is a recurring cost in a self-hosted setup. Pulp runs separate API, content and worker services that scale horizontally, and Harbor HA is typically deployed through its Helm chart with shared storage and database. Each replica, load balancer and failover test is infrastructure and staff time you pay for directly. Decide the recovery objectives your CI and production clusters need, then ask the commercial vendor which HA capabilities sit in your current tier, so the comparison covers equal availability.
Edition and add-on features
JFrog features such as federation, Xray and curation are sold as higher tiers or add-ons, and several have no direct open-source match. Harbor replication and Trivy scanning cover part of the need, but federation semantics and curation policies must be built, bought or accepted as a gap. Make a list of the add-ons your security and compliance teams rely on today. Each one either stays on the commercial side of the budget or becomes an engineering or tooling line item in the self-hosted model.
Team skills in Kubernetes and Postgres
Harbor and Pulp both depend on PostgreSQL, and Harbor's bundled database was upgraded from PostgreSQL 15 to PostgreSQL 18 in v2.15.2. Running them well means someone can manage backups, restores, upgrades and index maintenance, and in many estates on Kubernetes too. If that skill is already in-house, the recurring cost shrinks to routine operations. If not, the cost is either hiring, training or paying an implementation partner for the first cycle. Ask which skills are present today before estimating effort.
Air-gap and data residency needs
If registries must run without internet access or keep artifacts in a specific jurisdiction, the self-hosted option often becomes the only option, and the cost comparison shifts to what isolation requires. Harbor replication and Skopeo can move content across a gap, and Pulp can sync content for transfer, but each transfer step needs a process, a reviewer and evidence. Confirm with your security and legal teams which networks, regions and data classes apply, and price the transfer workflow as part of the design rather than as an afterthought.
What Harbor and Pulp each add to your budget
Harbor is the open-source registry for OCI images and Helm charts, licensed under Apache-2.0 and built on the Distribution registry. Its budget footprint is mostly the platform itself: the servers or cluster it runs on, the storage behind image layers, and the people who install, patch and upgrade it. Harbor bundles its own scanning, replication and proxy cache features, so most of the Artifactory container workload maps to features you already operate rather than to a second product.
- Vulnerability scanning: Trivy is enabled at install time with the
--with-trivyoption, so scanner updates and database refreshes become part of your routine operations. - Replication and proxy cache: Replication rules and proxy cache projects reduce external pulls, but they still consume bandwidth and storage on your side.
- v2.15.x upgrades: Harbor v2.15.2 moves the bundled database from PostgreSQL 15 to PostgreSQL 18 on container startup and replaces Redis with Valkey. Plan a backup before the upgrade and budget time for a
reindexdbrun if index problems appear. - v2.15.3 breaking changes: Webhooks to internal network addresses are blocked by default, and signing unsigned images fails in projects that enforce content trust. Check integrations before you roll out this release.
- Helm charts: Charts are served as OCI artifacts, because Harbor removed ChartMuseum in v2.8.0.
Before you build a budget, confirm your Harbor version, your database and storage topology, and which upgrade path your platform team will own.
Pulp is a GPLv2+ multi-format repository platform. Its core, pulpcore, runs alongside content plugins for Maven, npm, Python, RPM, Debian, Container and other formats, and each plugin adds maturity risk that must be priced into the plan. The effort is less a single install and more a set of services to run, plus a decision about which formats your teams depend on.
- Three services: pulpcore-api, pulpcore-content and pulpcore-worker processes run separately, with PostgreSQL as the source of truth for tasks. Each component scales horizontally, so high availability adds nodes and database planning.
- Plugin maturity: pulp_rpm (3.39.2), pulp_python (3.37.1), pulp_container (2.30.0) and pulp_deb (3.11.1) are past 1.0, while pulp_maven (0.35.0), pulp_npm (0.10.2) and pulp_gem (0.8.0) are still 0.x releases.
- Tech previews: The pulp_rust plugin is labeled a tech preview whose APIs may change, and its authentication and full syncing are not yet supported. Container pull-through cache mode is also a tech preview.
- Deployment options: Official images include a multi-process container and single-process images for Docker Compose or Kubernetes, which affects how much platform work you own.
- Release cadence: pulpcore 3.122.2 was released on October 15, 2026, and the project patched the older 3.118 and 3.105 lines the same day, so plan for regular patching across your chosen line.
Before you commit, ask which plugin versions and tech-preview features your target formats require, and who on your team will own PostgreSQL and worker scaling.
Both platforms are self-operated, so the recurring cost is the work of keeping them current. Harbor upgrades are largely about the bundled database, cache and scanner components, while Pulp upgrades involve several services and plugin versions that may not move together. The effort your team takes on depends on how often you upgrade and how much testing you run before each change.
- Backup discipline: Take database and object storage backups before each Harbor or Pulp upgrade, and test restores on a schedule rather than only at install time.
- Patch cadence: Harbor's 2.13 and 2.14 lines still receive patch releases alongside 2.15, so you choose which line to run and how quickly to move.
- Integration regression: Webhooks, signing policies and CI credentials can break during a minor upgrade, which means each upgrade needs a test environment.
- Scaling changes: Adding Pulp workers or Harbor replicas raises compute and database load, so capacity reviews should follow traffic growth.
- Support model: Decide whether internal staff or a retained partner handles on-call response, because the platform cost is mostly this labor.
Before you finalize an estimate, confirm the upgrade window you can sustain, the backup and restore test frequency, and which vendor or community channel you will rely on for security advisories.
Some JFrog capabilities have no direct open-source equivalent in Harbor or Pulp, and these gaps are where budget surprises usually appear. The most important are federation across JFrog instances, the Xray-style security and policy stack, and curation with license policy. Treat each as a line item to either build, buy from another vendor, or accept as a documented gap.
- Federation: Harbor replication runs push or pull with filters, triggers and bandwidth limits, but it is not the same as federated repositories across JFrog instances. Confirm the sync topology you need.
- Xray-style policy: Trivy covers image vulnerability analysis inside Harbor, but license policy and broader component governance need additional tooling such as DefectDojo for findings tracking.
- Curation: No direct open-source match was confirmed for JFrog curation. Plan for a manual approval workflow or a separate policy engine.
- Package types: Harbor does not handle non-container packages, so Maven, npm and Python content needs Pulp or another repository.
- Pulp gaps: Maven deploy does not use authentication and makes no SNAPSHOT or release distinction, which affects governance design.
Before you budget, ask the vendor or JFrog account team which of these features your current contract uses, and document how you will replace each one.
How to build the comparison with your own numbers
This sequence turns JFrog's pricing model and your current usage into a cost comparison that reflects your estimate, not ours. Each step produces a figure you can defend in a budget review or a vendor negotiation.
Inventory repositories, formats and consumers
List every Artifactory repository, its package type, whether it is local, remote or virtual, and which pipelines, clusters and developer groups read or write to it. Separate container and Helm content, which Harbor covers, from Maven, npm, Python, RPM and Debian content, which points toward Pulp. Note any repository that aggregates several upstreams through a virtual repository, because that aggregation needs its own plan. The step is done when every repository has one owner, one format and one list of consumers.
Measure storage and monthly transfer
Pull storage and data transfer figures from your own JFrog usage or billing reports for at least one full billing cycle, and record them per repository group where the reports allow it. JFrog's SaaS pricing counts storage and data transfer against an included allowance on its Pro plan, so check the current allowance and rates on the JFrog pricing page and in your contract, not in this article. Record peak month and typical month separately. The step is done when you have a storage total and a monthly egress figure with the report date and the source named beside each.
Document servers, high availability and backups
For self-managed Artifactory, list each node, its CPU, memory and disk, the database it depends on, the load balancer and the object storage backend. Confirm with JFrog which subscription tier you hold and how many servers it covers, since self-managed pricing follows server count. For SaaS, record the regions and any availability or backup terms in your order form. Note your recovery objectives as your own policy values. The step is done when you have a written topology that a replacement design can be checked against.
Price your cloud or hardware footprint
Convert the topology from the previous step into the infrastructure you would run for Harbor and Pulp: compute for the API, content and worker processes, a PostgreSQL service, Valkey or Redis for caching, object or block storage sized to your measured total, and backup storage. Harbor's current release notes describe its bundled database and cache changes, so confirm with your platform team which database and cache you will operate. Price each line with your cloud provider's calculator or your hardware vendor's quote. The step is done when every line has a unit cost, a monthly or one-time label, and a source document.
Estimate engineering hours for each lifecycle phase
Estimate hours for the install, the migration, recurring upgrades, security patching, backup tests and on-call coverage. Use your own team's records from past platform projects where you have them. Account separately for the Pulp plugins with 0.x versions or tech-preview status, because they may need more testing and fallback work. Ask whether the work will be done in house or through an implementation partner, and record the rate you use. The step is done when hours are listed by phase, by role and by whether they recur, and each estimate has a stated basis.
List gaps and features to budget separately
Write down the JFrog capabilities you rely on that have no direct open-source match, such as Xray-level scanning with curation and license policy, federation, and any tier-specific SSO or HA features. For each, record whether you will drop it, replace it with a tool such as Trivy or DefectDojo, or pay for it somewhere else. Each replacement carries its own cost line. The step is done when every gap has a decision and a cost line or an explicit decision to accept the loss.
Request a written quote for the implementation scope
Send the inventory, topology, measured usage and gap list to one or more implementers and ask for a fixed-scope quote with written deliverables, timelines and assumptions. DeployOpen works from a written scope and does not publish a price list, so a quote follows from the scope you define. Ask each bidder to state what is included in install, migration, hardening, backup testing, upgrades and support, and what is excluded. The step is done when you hold written quotes that can be compared line by line against your JFrog renewal figures.
Which JFrog features to budget for as gaps
Federation, curation and license policy, and the tiered SSO and HA features are the JFrog capabilities most likely to stay on your budget after a move to Harbor and Pulp, so settle them before you size the open-source stack. Harbor's replication is not federation. Replication rules copy images or charts between registries on push, on a schedule or on demand, and can pull from Artifactory as an endpoint, but they do not provide the bidirectional, metadata-aware synchronization that Artifactory federation is sold for. Confirm with JFrog exactly which federation topology and sync behavior your estate depends on, then decide whether replication covers it or whether you accept a manual or scripted process.
Xray-style scanning and curation have the same shape of gap. Harbor runs Trivy for static image analysis, which covers the vulnerability scanning side, but it does not provide the policy-based curation that blocks or quarantines upstream packages before they enter your repositories, and it does not offer a license-policy engine. Pulp's vulnerability reporting is a tech preview, so do not treat it as a production findings register. For findings tracking across scanners, budget for a separate tool such as DefectDojo, and for curation or license decisions either write and maintain your own allow-list process or accept the gap in writing with your security and legal teams.
SSO and high availability are tiered in JFrog's offering, and the open-source side is configured rather than licensed. Harbor supports LDAP/AD and OIDC single sign-on, and its high-availability deployment is documented for Helm. Pulp scales its API, content and worker components horizontally, but you assemble the database, storage and load balancing yourselves. Ask JFrog which SSO and HA features your current tier includes, then map each one to a named configuration in Harbor or Pulp and an engineering owner. Confirm any remaining needs, such as fine-grained permissions for non-container formats, with JFrog and with the Pulp and Harbor projects before you commit.
Questions buyers ask before comparing costs
Is moving from JFrog Artifactory to self-hosted Harbor and Pulp cheaper overall?
It depends on which costs you compare, so the answer is rarely yes or no in advance. Your current spend is a subscription that covers the software, support and the hosted or self-managed service. A self-hosted move replaces that with infrastructure you pay for (servers, object storage, PostgreSQL, backups, monitoring) plus the staff time to install, patch, upgrade and support both platforms. Harbor is Apache-2.0 and Pulp is GPLv2+, so the software itself carries no license fee. Build a three-year total from your own inputs: your current invoice, your storage and transfer volumes, and the hours your team will spend running the new stack. Compare that total, not the line items alone.
How much effort does a Harbor and Pulp migration take?
Effort depends on how many repository types you hold, how much content is in each, how many CI pipelines and Kubernetes clusters point at Artifactory, and how many non-container formats need a rebuild path. Docker and Helm content usually moves through Harbor replication and proxy cache projects, which is a smaller task than rebuilding Maven, npm or Python repositories in Pulp. No duration figure is supplied for this work, so ask for a written scope that lists each repository, its consumers and the cutover plan before agreeing a timeline.
Can our own team run the migration without outside help?
A capable platform team can do it, provided it has someone who runs Kubernetes or Docker Compose, PostgreSQL, object storage and a CI system, and who can own the upgrade calendar. Harbor's recent releases changed the bundled database and cache, and some patch releases introduced breaking changes, so upgrades need a tested runbook and a backup step. Pulp requires comfort with Django-based services and its REST API. Count the people who will carry this work after go-live, not only during the migration.
What does the work require from our team?
Expect to supply access and decisions as much as hours. You need an inventory of repositories and their consumers, admin access to Artifactory, a place to host the new platforms (cloud accounts, data center or air-gapped network), identity integration for single sign-on, and a sign-off process for cutover. Security and compliance staff will need to review scanning, access control and audit logs in Harbor, and any Pulp plugin you depend on should be checked against its maturity status before you commit.
Which costs recur after the migration, and which are one-time?
One-time costs include discovery, migration work, testing and initial configuration. Recurring costs include compute and storage for both registries, backup copies, database hosting, monitoring, certificate and identity upkeep, staff time for patching and upgrades, and any support retainer you choose. Storage and data transfer grow with your image and package volume, so track those figures monthly. Upgrade effort recurs with every Harbor and Pulp release cycle.
How do we request a quote from DeployOpen?
DeployOpen does not publish a price list. A quote follows from a written scope that covers the repositories in play, the target environment, the migration approach, testing, documentation and handover, and any ongoing support or upgrade retainer. Send your repository inventory, hosting constraints and compliance drivers so the scope reflects your estate. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
What happens to JFrog features that have no open-source match?
Some capabilities, such as Xray-style policy and curation features, federation, and some fine-grained package management, do not have a direct equivalent in Harbor or Pulp. Harbor can scan images with Trivy and connect to external scanners, and Pulp's vulnerability reporting is at tech preview, so budget for a separate tracking or policy layer or accept a process change. Confirm each feature you use against the open-source documentation, decide whether to replace it, rebuild it or drop it, and price that work into the scope before you compare totals.
When the self-hosted case holds and when it does not
The self-hosted case lowers total cost when container and package volumes are steady, when the team already runs Kubernetes and PostgreSQL in production, and when data residency or air-gap rules make a hosted repository hard to justify. Harbor's costs are mostly infrastructure and people: the servers or cluster nodes, the object storage that holds image layers, a PostgreSQL database (Harbor's bundled database moved from PostgreSQL 15 to PostgreSQL 18 in v2.15.2, so plan for that upgrade path), and the engineer hours for upgrades and backups. Those costs recur, but they are predictable once the platform exists. JFrog's SaaS bills by consumption, and self-managed editions bill by server, so an estate with steady traffic and few deployments may find the self-hosted line items easier to forecast. Ask any vendor for a quote that separates storage, egress, compute and support so the comparison is like for like.
Artifactory tends to stay cheaper in three situations. The first is heavy use of federation or Xray, because Harbor's replication and Trivy scanning do not reproduce those features, and building equivalents costs engineering time that is easy to underestimate. The second is a thin platform team: if no one can own a database, an ingress, certificates and a release calendar, the hours spent on Harbor or Pulp upgrades can exceed the subscription. The third is a mix of many non-container formats. Pulp's plugins for Maven, npm and Python are usable, but pulp_maven, pulp_npm and pulp_gem are still 0.x releases, and pulp_rust is a tech preview, so each format needs its own testing and some may need a workaround. Confirm the plugin maturity and your formats before you model the saving.
Before deciding, run a short inventory: image and package volumes by month, egress from the cloud accounts that pull them, the number of distinct upstream registries, and the names of the people who would run each service. Then ask your JFrog account team for the self-managed subscription terms and the SaaS consumption rates that apply to your volumes, and ask DeployOpen for a written scope that prices the Harbor and Pulp components in the same structure. If the inventory shows that most of your traffic is container images and Helm charts, and your platform team can run PostgreSQL and Kubernetes, the case often holds for those formats first, with packages moved in a second phase.
How DeployOpen scopes a fixed-price Harbor and Pulp implementation
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a move off JFrog Artifactory, we start by turning your current cost lines and repository inventory into a written scope that separates the Harbor container work from the Pulp package work.
How we scope
- We inventory which Docker, Helm, Maven, npm and Python repositories you run and which are hosted, remote or virtual.
- We map each JFrog feature you pay for, such as federation, Xray or curation, to a named replacement or to an accepted gap.
- We agree in writing which Harbor and Pulp components, environments and cutover steps the engagement covers before work starts.
How we build
- We deploy Harbor and Pulp in your environment with the storage, database and identity integrations your policies require.
- We configure replication rules, proxy cache projects and Pulp remotes against the upstreams your CI pipelines actually use.
- We test pulls, pushes, scanning and access controls against the scope and record the results for your review.
How we hand over
- We document architecture, backup and restore steps, upgrade runbooks and the credential changes your CI and clusters need.
- We prepare the controls and evidence your compliance assessors may ask for, while independent auditors perform any formal assessment.
- We walk your platform team through operation so the handover is complete before the scoped engagement closes.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work ends.
- A retainer can cover Harbor and Pulp version upgrades, backup verification and periodic security testing of the registries.
- Ask for the retainer terms in the written quote so the post-handover support scope is as clear as the build scope.
