Can open source replace Artifactory remote repositories?
For most teams, the answer is yes for containers and mostly yes for packages, but the work is in the redesign, not the copy. Harbor proxy cache projects cover container images pulled from Docker Hub and other upstreams, and pulp_maven and pulp_npm pull-through caching cover Maven Central and npm. The main change is virtual repository aggregation: Artifactory lets one virtual repository front several local and remote sources behind a single URL, and neither Harbor nor Pulp reproduces that model one-to-one. Whether the swap is practical depends on which formats your estate uses and how much your build configuration can change.
Start with an inventory of remote repositories, grouped by format. Container pulls through Docker Hub are the most common reason teams hit rate limits, and Docker's documentation sets unauthenticated pulls at 100 per 6 hours per IPv4 address or IPv6 /64 subnet, with 200 per 6 hours for Docker Personal accounts. Harbor's documentation says its proxy cache checks cached images with HEAD requests that do not count against that limiter, and a cached copy is served if the upstream is unreachable. Proxy cache projects are read-only for pushes and get a default 7-day retention policy, which you should review against your release cadence. Confirm in your environment that CI runners and Kubernetes nodes authenticate to the proxy and not directly to Docker Hub.
Packages need a different plan. pulp_maven can cache Maven Central and pulp_npm mirrors registry.npmjs.org with pull-through caching, but the pulp_maven and pulp_npm plugins are still 0.x releases, and pulp_maven's deploy feature does not use authentication. Each virtual repository in Artifactory typically needs to become a set of Pulp remotes and distributions that your build tools point to, which means updating settings.xml, .npmrc and resolver configuration. Ask your Pulp partner or internal team to test one full build per format against the cached endpoints, and confirm which formats need a fallback for internal packages before cutover.
Which open-source option covers each remote repository capability
This table maps each Artifactory remote and virtual repository capability to the Harbor proxy cache or Pulp remote that covers it, with coverage notes for each. Read the coverage column first, because several options are tech previews or 0.x releases, and the aggregation row has no direct match.
| Capability | Harbor proxy cache (containers and Helm) | Pulp remotes and distributions (Maven, npm) |
|---|---|---|
| Remote repository proxying an upstream | Proxy cache projects cache Docker Hub, Harbor, Docker registry, Quay, GitHub Container Registry and JFrog Artifactory as upstreams. | pulp_maven can pull-through cache Maven Central or another Maven repository; pulp_npm mirrors registry.npmjs.org and offers pull-through caching. |
| Pull-through caching behavior | Proxy cache projects are read-only for pushes and serve the cached copy if the upstream is unreachable. | pulp_maven pull-through is documented as a tech preview; pulp_container pull-through cache mode is also a tech preview. |
| Metadata checks and rate limits | Harbor checks cached images with HEAD requests, which do not trigger the Docker Hub rate limiter. | Confirm with the pulp_npm and pulp_maven documentation how metadata refresh behaves against your upstream before cutover. |
| Retention and cache cleanup | Cached artifacts get a default 7-day retention policy, which you can change; confirm the setting for your version. | Pulp retention is managed through repository versions and content cleanup; confirm the cleanup tasks you need for cached packages. |
| Upstream authentication | Confirm how each upstream credential is stored and rotated in the proxy cache endpoint configuration. | Confirm per-remote credential handling for private upstreams in the Pulp remote settings for each plugin. |
| Virtual repository aggregation | No direct match. Harbor projects group repositories but do not merge several upstreams into one resolved path. | No direct match. Pulp distributions publish one repository version, so teams usually point clients at a single distribution per format. |
| High availability and maturity | Harbor is a graduated CNCF project; plan HA for the Harbor core, database and storage layers. | pulp_maven (0.35.0) and pulp_npm (0.10.2) are 0.x releases, so validate their behavior against your traffic before relying on them. |
| Gitea and Forgejo package registries | Not applicable: Gitea and Forgejo host packages but do not proxy Docker Hub or other upstream registries. | Not applicable: their package registries do not proxy or cache upstream packages. |
Harbor, pulp_maven, pulp_npm and Pulp distributions compared
Artifactory's remote repositories fall into two families: OCI proxy caches for container images and pull-through caches for language packages. Each open-source option below covers one part of that job, and the right choice depends on which upstream you proxy and which format your build tools need.
Harbor proxy cache projects
Harbor proxy cache projects serve Docker Hub, Harbor, Docker Registry, AWS ECR, Azure ACR, Google GCR, Quay, GitHub Container Registry and JFrog Artifactory upstreams. They are read-only for pushes and serve the cached copy if the upstream is unreachable, which matters during outages. Cache checks use HEAD requests that do not trigger the Docker Hub rate limiter, so CI fleets pulling through one proxy are not counted against each pull. Check the default 7-day retention policy against your image update cadence, and confirm which upstreams your build pipelines actually use.
pulp_maven pull-through cache
pulp_maven can act as a pull-through cache for Maven Central or any other Maven repository, so builds resolve dependencies from your own endpoint. The plugin is still 0.x (version 0.35.0), so pin the version and test resolution of your dependency graph before cutover. Its deploy feature does not use authentication and does not separate SNAPSHOT from release repositories, so keep it for caching and use a different publishing path for internal artifacts until you have confirmed the behavior in your environment.
pulp_npm pull-through caching
pulp_npm mirrors packages from upstream registries such as registry.npmjs.org and offers pull-through caching, so installs go through your registry while the upstream stays the source of truth. It also accepts packages published with npm publish or yarn publish, which can cover internal packages in the same service. Version 0.10.2 is still pre-1.0, so test lockfile installs, scoped packages and private registry authentication in a staging pipeline before moving developers over.
Pulp remotes and distributions
Pulp's general pattern is a remote that points at an upstream, a sync or pull-through configuration, and a distribution that publishes the content to clients. This pattern covers formats beyond Maven and npm, including RPM, Python and Debian, where maturity varies: pulp_rpm and pulp_python are past 1.0, while pulp_maven, pulp_npm and pulp_gem are still 0.x. Pulp is GPLv2+ licensed, so confirm that your legal review accepts its terms for internal deployment. Budget for the team that will run PostgreSQL, storage and worker scaling, since Pulp has more moving parts than a single-binary cache.
What to do about virtual repository aggregation
An Artifactory virtual repository presents several local and remote sources behind one URL and resolves requests across them in a configured order. Open-source tools rarely offer that single front door. Harbor serves OCI content through its own projects, and Pulp exposes each mirrored or hosted set of packages as its own distribution with its own base path. The practical consequence is that you replace one aggregated endpoint with one cache or distribution per format, and each client must be told explicitly where to look. Plan for that change in your inventory of build configurations before you cut over anything.
Three patterns cover most estates. First, point CI runners and developer tooling at one cache per format, for example a Harbor proxy cache project for Docker Hub images and a separate Pulp endpoint for Maven or npm, and keep the mapping in version-controlled configuration. Second, where several upstreams feed one client, use a single Pulp distribution over content you have already synced or mirrored, so the client sees one package index. Third, place a reverse proxy or ingress in front of the endpoints so developers see one hostname with path-based routing. The proxy hides topology but adds a component to operate, certificates to renew and a single point of failure to design around.
Before cutover, confirm how each build tool resolves precedence across sources. Maven, npm, pip and container runtimes do not all behave the same way when a package name exists in more than one location, and dependency confusion risks depend on that order. Write down the resolution order your Artifactory virtual repository uses today, test it against representative builds in a staging environment, and check that each replacement endpoint returns the same artifact for the same coordinates. Where the order cannot be reproduced exactly, decide which source is authoritative and block the ambiguous names explicitly.
How the setup differs for connected and isolated networks
When the registry host can reach upstream sources directly, a Harbor proxy cache project can be pointed at Docker Hub or another supported upstream and fills itself on first pull. Pulp's pulp_maven and pulp_npm plugins can likewise act as pull-through caches for Maven Central or registry.npmjs.org, so build agents reach one internal endpoint instead of the public internet.
- Upstream rate limits: Docker Hub limits unauthenticated pulls per IPv4 address or IPv6 /64 subnet, so a shared egress address can hit the limit quickly. Harbor's documentation says its proxy cache checks cached images with HEAD requests that do not trigger that limiter.
- Cache retention: Harbor proxy cache projects get a default 7-day retention policy, which you should review against how long your build pipelines rely on cached tags.
- Credentials at the proxy: Store upstream credentials on the proxy cache endpoint rather than in each CI job, and confirm how your chosen Harbor version handles them.
- Read-only caches: Proxy cache projects are read-only for pushes, so internal images belong in separate projects.
- Pulp pull-through modes: Confirm which Pulp container features are production-ready, since the pulp_container pull-through cache mode is a tech preview.
Before go-live, confirm the upstream list, the rate-limit exposure of your egress address and the retention policy with your platform team.
In a restricted network, the registry may reach upstreams only through an approved proxy or egress gateway. The cache still fills from upstream, but every request crosses a controlled point that security and network teams usually need to log, allow-list and approve. Harbor's replication and Pulp's sync features can move content through that gateway on a schedule instead of on every client pull.
- Controlled egress: Allow-list the specific upstream hosts at the gateway and test each proxy cache endpoint before rolling it out to build agents.
- Scheduled pulls: Harbor replication rules can run on a cron schedule or be triggered manually, and can apply a per-task bandwidth limit to protect the gateway.
- Serving during outages: Harbor proxy cache serves the cached copy when the upstream is unreachable, so builds can continue for images that are already cached.
- Cache gaps: Images never pulled before the outage are not cached, so pre-warm the images your pipelines depend on.
- Scanning in transit: Harbor can scan images with Trivy, and Pulp can sync Cosign signatures stored as OCI images, which helps verify content as it enters the network.
Ask your security team which upstreams, ports and proxy paths are approved, and confirm the gateway's logging requirements before design starts.
Where there is no path to the internet, a proxy cache cannot fill itself. Content has to be brought across the boundary by a transfer step, and the registry inside the isolated network then serves it. Pulp syncs content from upstream on the connected side and distributes it inside the isolated network, which supports transfer across a gap. Skopeo can copy images between registries or into a local directory for the same purpose.
- Sync on one side, serve on the other: Pulp syncs repositories on the connected side, and the synced content is then served from the isolated network.
- Image transfer with Skopeo: Skopeo can sync an external image repository to an internal registry or to a local directory for transfer, according to its README.
- No live fallback: A cache that was never filled cannot serve during an outage, so the transfer schedule defines what is available offline.
- Harbor offline install: Harbor's offline installer and replication into an isolated registry are covered on the air-gapped sibling page.
- Package format limits: Pulp's Maven and npm plugins are still 0.x releases, and the Rust plugin is a tech preview, so confirm each format before you rely on it offline.
For the full procedure, read the air-gapped sibling page, and confirm the transfer media, approval workflow and sync frequency with your security team.
Moving remote repositories without breaking builds
This sequence moves Artifactory remote and virtual repository traffic to Harbor proxy cache projects and Pulp remotes in stages, so builds keep working while each endpoint is verified before the old one is retired.
Inventory remote and virtual repository consumers
The platform team exports the list of Artifactory remote and virtual repositories from the admin console or REST API, then matches each one against the CI pipelines, build agents, developer workstations and Kubernetes clusters that reference it. Record the upstream each remote points to (Docker Hub, Maven Central, npm and so on), the credentials each consumer uses, and any virtual repository that aggregates several remotes. Virtual repositories often need to be split, because Harbor proxy cache projects map one upstream to one project. The step is done when every consumer has an owner and every virtual repository has a documented replacement plan.
Back up before any upgrade or configuration change
Before the Harbor instance is installed or upgraded, the operations team takes a full backup of the Harbor database and registry storage. Harbor's v2.15.2 release notes recommend a backup before upgrading, because that release upgrades the bundled internal database from PostgreSQL 15 to PostgreSQL 18 on container startup and replaces Redis with Valkey. Keep the backup until the upgraded instance has passed the verification steps below. The step is done when a restore has been tested on a separate host, not only when the backup job reports success.
Stand up proxy cache projects and Pulp remotes
The team creates a Harbor proxy cache project for each container upstream, such as Docker Hub, and configures the matching Pulp remotes for Maven, npm and other package formats, such as a pull-through remote for Maven Central. Check the Harbor v2.15.3 breaking changes before this work: webhooks to internal network addresses are blocked by default, and signing unsigned images fails in projects that enforce content trust, so any notification or signing job that depended on the old behavior needs an explicit decision. Confirm the pulp_maven and pulp_npm plugin versions in your environment, since both are still 0.x releases. The step is done when each new endpoint returns a test pull through the proxy path.
Point a non-production pipeline at the new endpoints
The build team changes one non-production pipeline so that image pulls and package resolution go through the Harbor project and Pulp distribution instead of the Artifactory remote. Run the pipeline on the same branches and dependency sets it uses in production, and compare resolved versions and image digests against the Artifactory build. Differences usually come from virtual repository ordering or from tag mutability, so review those first. The step is done when two consecutive runs produce the same dependency tree and image digests that the production baseline does.
Repoint credentials and package manager configuration
The team updates CI secrets, Kubernetes image pull secrets,
settings.xmlfor Maven,.npmrcfor npm and container runtime login configuration to reference the Harbor and Pulp endpoints. Use robot or service accounts scoped to the projects they need, instead of reusing personal Artifactory tokens. Roll the change out one team at a time and keep the Artifactory credentials valid until the last consumer has moved. The step is done when an inventory check shows no remaining references to the old Artifactory hostnames in pipelines, cluster manifests or developer templates.Verify cache behavior during an upstream outage
Harbor's documentation says a proxy cache project serves the cached copy when the upstream is unreachable, and checks cached images with HEAD requests that do not count against the Docker Hub rate limiter. Test this directly: pull an image that is already cached, block the upstream at the network boundary, and confirm the pull still succeeds. Repeat the test for a Pulp remote with an already-synced Maven artifact. Also confirm the default 7-day retention policy in the proxy cache project matches the rebuild cadence of your builds, since an image not pulled within that window may be removed from the cache. The step is done when the outage test is recorded with the commands, timestamps and results.
Retire the Artifactory remote endpoints
After a full build cycle runs cleanly on the new endpoints, the team disables the Artifactory remote and virtual repositories in read-only mode first, then removes them once no traffic appears in the access logs for an agreed observation period. Keep a copy of the repository configuration and the final export of hosted content, because those are needed for audit and rollback. Record the decommission in the change log and update the internal documentation that lists approved package sources. The step is done when the access logs show no requests to the retired repositories and the configuration export is stored with the migration record.
Questions teams ask before replacing remote repositories
How much does it cost to replace Artifactory remote repositories with open-source tools?
The cost depends on the components you run, not on a single license fee, because both Harbor and Pulp are free under open-source licenses. Harbor is Apache-2.0 and Pulp is GPLv2+, so software licensing is not the cost. The recurring costs are the servers or Kubernetes capacity, object storage for cached images and packages, PostgreSQL and any cache service, backups, and the engineering time to upgrade and operate the stack. Ask any implementation partner for a written scope that lists each component, who pays for it, and what is one-time versus recurring. The JFrog Artifactory cost vs self-hosted Harbor and Pulp comparison sibling page breaks these components down in more detail.
How long does it take to move remote repositories off Artifactory?
No timeline is fixed here, because it depends on how many proxy and remote repositories you have, how many CI pipelines and Kubernetes clusters pull through them, and whether Maven or npm clients need changes. Harbor proxy cache projects can be created and pointed at upstreams quickly, but cutover means repointing every client, mirror setting and image pull secret. Pulp remotes for Maven and npm need testing against your real dependency trees. Ask for a written plan with phases, a rollback point for each phase and a list of client configurations that must change.
Can our own platform team do the replacement without an outside partner?
Many teams with container platform experience can deploy Harbor themselves, since its installer, Helm chart and documentation are public. Pulp is more demanding because it needs PostgreSQL, the pulpcore-api, pulpcore-content and worker services, and per-plugin configuration, and it needs someone who can run Django-based services and troubleshoot sync tasks. A useful self-assessment is whether your team can already operate PostgreSQL backups, object storage and ingress for stateful services. Teams that lack these skills often bring in an implementation partner for a fixed-scope build, then keep operations in-house.
Are the 0.x Pulp plugins too risky for Maven and npm remote repositories?
Pulp's Maven and npm plugins are still 0.x releases, so their interfaces can change between versions and you should treat them as less mature than the 1.0-plus plugins such as pulp_rpm and pulp_python. Pulp's Maven plugin can act as a pull-through cache for Maven Central, but its deploy feature does not use authentication and does not separate SNAPSHOT and release repositories, which matters for shared internal publishing. Reduce the risk by pinning plugin versions, testing upgrades in staging, and keeping an exit path to a second cache during cutover. Avoid the Rust plugin for production remotes, since its README labels it a tech preview.
What happens to Docker Hub rate limits after we move images to a Harbor proxy cache?
Docker Hub limits unauthenticated pulls to 100 per 6 hours per IPv4 address or IPv6 /64 subnet, and Docker Personal accounts to 200 per 6 hours, according to Docker's documentation. A Harbor proxy cache project fetches each image from Docker Hub once and then serves it locally, so many build agents and nodes share one cached copy instead of each pulling from Docker Hub. Harbor's documentation says its cache checks cached images with HEAD requests that do not trigger the Docker Hub rate limiter. Confirm the current limits with Docker and test your pull volume against a staging cache before cutover, because the upstream account you configure still counts toward its limits.
What do we need to prepare from our team before the engagement starts?
Before any work starts, gather an inventory of every remote and virtual repository, the upstreams each one proxies, the clients that use it (CI runners, Kubernetes nodes, developer machines and build tools), and the authentication method each client uses. Also document your storage and retention needs, your backup and disaster recovery requirements, and any network restrictions for outbound access to Docker Hub, Maven Central and npm. Ask a partner to list these inputs in the written scope so the quote reflects your real estate rather than assumptions.
What should a written scope for this work include?
A written scope should name each in-scope repository, the target product and version, the deployment target (your cloud account, data center or air-gapped network), and the high-availability design you need. It should list the integrations to test, such as SSO, vulnerability scanning and CI credentials, and the cutover and rollback steps. Ask for the handover items too: runbooks, backup and restore tests, upgrade procedure and who owns each service after go-live. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and ongoing support can be added as a retainer.
Keeping Artifactory for the rest while moving caches
Moving proxy traffic does not have to mean moving everything at once. Harbor and Pulp can take over pull-through caching while Artifactory keeps the hosted, Xray-dependent or non-migrated content, but the split only works if each format has one clear owner.
Route proxy traffic by format
Decide per format which system answers a given client request. Container images and Helm charts usually go to a Harbor proxy cache project, while Maven Central and npm traffic goes to a Pulp remote with pull-through caching. Write this map down before changing any CI configuration, and keep it in the same repository as the pipeline definitions so reviewers can see every endpoint change. Confirm that each client tool can be pointed at a different host per format without breaking authentication.
Use Artifactory as an upstream during cutover
Harbor proxy cache projects can use JFrog Artifactory as an upstream, and Harbor replication can register Artifactory as an endpoint. This lets you keep Artifactory as the source of truth while Harbor warms its cache or copies images across. Treat this as a transition state. Once the Artifactory upstream is no longer needed, remove it so that the cache does not depend on a system you are retiring.
Avoid two sources of truth
When hosted packages live in Artifactory and cached copies live in Pulp or Harbor, the same version can exist in two places with different metadata. A developer may pull a cached artifact that was never published to the hosted repository, or a rebuilt cache may serve a version that Artifactory has since removed. Pick one authoritative store for each hosted package set, and let the caches hold only upstream copies that can be re-fetched.
Check cache retention and upstream outages
Harbor proxy cache projects apply a default 7-day retention policy, and they serve the cached copy when the upstream is unreachable. Those defaults affect what your builds can pull during an outage and how long old images remain available. Set retention deliberately for each project, and test a build with the upstream blocked to confirm which artifacts still resolve.
Review what Artifactory still owns
List everything Artifactory still serves: hosted repositories, virtual repositories that aggregate several sources, and any content covered by Xray scanning or curation policies. Each item needs an owner and an exit condition. Virtual repositories are the hardest part to split, because clients often resolve several sources through one URL. Confirm with your platform team which clients depend on that single endpoint before moving any of them.
Confirm access controls on both sides
Credentials, group mappings and token lifetimes must match across Artifactory, Harbor and Pulp during the split. A user who is blocked in one system may still pull through another, and Kubernetes image pull secrets or CI tokens may point at the wrong host. Ask your identity team to map groups once and review the access logs of each system for unexpected pulls for at least one full release cycle.
Where open source does not match Artifactory
The biggest gap is that no open-source option here reproduces Artifactory's virtual repository as a single endpoint that aggregates local, remote and cached sources behind one URL. Harbor proxy cache projects map one upstream registry to one project, so a team that today points every client at one Artifactory virtual repository will need to configure separate endpoints per upstream or front them with a reverse proxy or an alternative resolver. Pulp distributions and remotes work differently again, so the path depends on the format. Before cutover, list every virtual repository your clients depend on, record which local, remote and cached members it contains and test that each client resolves the same artifacts from the new endpoints. Treat any client that cannot be repointed without code changes as a risk to plan for, not a detail to fix later.
Pulp's container pull-through cache mode in pulp_container is a tech preview, and the pulp_maven deploy feature does not use authentication and makes no distinction between SNAPSHOT and release repositories. If your CI publishes Maven artifacts to a shared repository, an unauthenticated deploy endpoint is a control gap you must close with network restrictions, a reverse proxy or another access layer in front of Pulp before you rely on it. Check the current status of these features in the plugin release notes against the versions you plan to run, because tech-preview APIs can change between releases. Do not assume a tech-preview feature is production-ready because it appears in the documentation.
Several formats are still weak spots. The pulp_rust README labels the Rust and Cargo plugin a tech preview whose APIs may change without notice, and it lists authentication, authorization and full registry syncing as not yet supported. Several other Pulp content plugins, including pulp_maven, pulp_npm and pulp_gem, are still 0.x releases, so their interfaces carry more change risk than the 1.0-and-later plugins. Make a format-by-format inventory of your package types, mark each as supported, supported with a workaround, or unsupported, and run a pilot that pulls and publishes real packages through each plugin under the access controls you intend to use. Ask any vendor or open-source maintainer you rely on for a written support statement, since the research available here does not establish long-term support commitments for these plugins.
How DeployOpen scopes and delivers remote repository replacement
DeployOpen plans and implements self-hosted replacements for Artifactory remote repositories inside your own cloud accounts, data centers or air-gapped networks. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before any work starts.
How we scope
- Inventory every remote and virtual repository, its upstream sources and the clients that depend on it
- Decide per format whether Harbor proxy cache projects or Pulp pull-through remotes fit the workload
- Document which virtual repository aggregations need redesign, and confirm them with your teams before build starts
How we build
- Deploy Harbor proxy cache projects for Docker Hub and other OCI upstreams inside your environment
- Configure pulp_maven and pulp_npm caches against your upstream repositories and confirm authentication and retention settings
- Test cache behavior during upstream outages, cutover traffic and CI pull patterns, then record results and known gaps
How we hand over
- Deliver architecture, configuration, runbooks and a record of each test with the open issues still outstanding
- Train platform and build engineers on cache administration, scanning, retention and upgrade procedures
- Provide a written list of Artifactory features without a direct open-source match so you can plan around them
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Plan upgrades against the Harbor and Pulp release notes, including backup steps and breaking changes
- Quote follows from the written scope, so ask for each cost component to be itemized in the proposal
