Air-gapped Artifactory alternative

Air-gapped Artifactory alternative: what isolation requires

If your isolated network still needs container images, Helm charts and language packages, the short answer is that Harbor covers OCI content and Helm charts, and Pulp covers multi-format packages, with every artifact moved across the gap through a controlled, verified transfer. Self-managed Artifactory editions can also run without internet access, so the decision does not turn on whether offline operation is possible. It turns on two things: how long the version you run stays supported, and who on your side or your implementation partner's side performs and records each transfer.

Harbor's offline installer lets you bring the registry software itself into the enclave, and its replication rules can push images and charts from a staging Harbor in the connected zone into an isolated Harbor. Harbor's replication filters on repository name, tag, label and resource type let you limit each transfer to an approved list. For packages, Pulp syncs content from upstream repositories into a staging instance, and Skopeo can copy container images to a local directory for physical transfer. Confirm with each project's documentation which transfer mechanisms your security team will accept, because the chosen path determines what evidence you can keep at each step.

The version window is the other half of the decision. JFrog supports each self-managed minor version for 18 months, so an air-gapped Artifactory estate needs a scheduled upgrade path that also passes through the isolated boundary, which is slow to rehearse. Harbor and Pulp release patches on their own cycles, so the work shifts to tracking release notes and applying tested updates, including Harbor's v2.15.2 database and cache changes and v2.15.3 breaking changes for webhooks and content trust. NERC CIP-013-2 asks utilities to address verification of software integrity and authenticity for every package carried across an isolated boundary, so your procurement process should define how each artifact is checked before it enters.

What an air-gapped artifact registry must do

Isolation changes what a registry has to do on its own. Content has to arrive by a controlled transfer, be verified before it enters the enclave, and stay usable when no upstream can be reached. The cards below map those needs to specific Harbor and Pulp capabilities and to the checks your team should run.

Standard OCI pull and push

An internal registry must speak the OCI Distribution Specification, which requires every conforming registry to support pull. Confirm that every client in the enclave, including build agents and Kubernetes nodes, pulls and pushes through the same API version your Harbor release supports. Test with the images and Helm charts your teams actually use, since a registry can pass pull tests and still fail on a specific push path.

Referrers for signatures and SBOMs

In a closed network, signatures and SBOMs are often the only evidence that an image is what it claims to be. The OCI referrers API at /v2/<name>/referrers/<digest> lists manifests that point at an image, so attestations can travel with the image they describe. Ask whether your transfer tooling copies referrers along with the image, because a copy that drops them removes the evidence.

Offline installation from a downloaded installer

Harbor can be installed from an offline installer package downloaded in advance on a connected system, so the isolated network never needs to reach a public repository during setup. Plan the transfer of the installer, its container images and the Trivy vulnerability database as one controlled import. Record the exact release and checksum you imported, because that record is part of your change evidence.

Replication across the air gap

Harbor replication rules run push-based or pull-based and can be triggered manually or on a schedule, with an optional bandwidth limit. On the connected side, a push replication can stage content; on the isolated side, a pull rule can bring it in from a transfer point. Skopeo can also sync an external image repository to a local directory for carrying across the gap. Confirm the handoff format, who approves each transfer and where the staged copy is kept.

Cached content when upstreams are down

Harbor proxy cache projects serve the cached copy when the upstream is unreachable and check cached images with HEAD requests. That keeps builds running when a link to the upstream fails, but only for images already cached. Set retention deliberately, since the default policy for proxy cache is 7 days, and confirm which base images your teams need pre-cached before the network is closed.

Integrity checks before content enters

Each package or image that crosses the boundary should be scanned and its signature or checksum verified before it is published to an internal repository. Harbor runs Trivy scanning at install time with the --with-trivy option, and the vulnerability database must be refreshed by transfer as well. Note that Harbor 2.15.3 blocks webhooks to internal network addresses by default and fails signing of unsigned images in projects that enforce content trust, so review both settings before go-live.

Which self-hosted registry fits an air-gapped Artifactory alternative

This table compares Harbor, Pulp, the Distribution registry and self-managed Artifactory against the requirements of an isolated network. Read each row as a question to confirm in your own environment, because offline behavior depends on your install method, transfer process and plugin versions. The main takeaway is that Harbor covers OCI and Helm content with the strongest offline and access control story, while Pulp is needed for other package formats and carries more maturity risk.

Requirement	Harbor	Pulp	Self-managed Artifactory
OCI images and Helm charts	Native OCI registry; Helm charts served as OCI artifacts since v2.8.0	pulp_container hosts and syncs OCI images; Helm charts are not a listed plugin	Supports Docker and Helm repositories; confirm the version and tier you run
Other package formats	Not a general package manager; confirm scope for your formats	Plugins for Maven, npm, Python, RPM, Debian and more, with mixed maturity	Universal repository covering more than 60 package types per JFrog's pricing page
Offline installation	Offline installer is published; confirm bundled images and dependencies for your version	Offline image and package install depends on your deployment method; confirm with the Pulp project	Supported in self-managed editions; confirm offline activation and license workflow with JFrog
Transfer across the gap	Replication into an isolated registry, with bandwidth limits and filters	Sync content to a host, then publish from the isolated side; confirm the export format you need	Repository export and import exist for self-managed; confirm scope and metadata with JFrog
Pull-through or proxy caching	Proxy cache projects for Docker Hub, Harbor, ECR, ACR and others; serves cache if upstream is unreachable	pulp_maven and pulp_npm offer pull-through caching; container pull-through is tech preview	Remote repositories proxy upstream sources; confirm which remotes survive when the network is isolated
Authentication and access control	Role-based projects, LDAP/AD and OIDC single sign-on, audit logs	Authentication depends on plugin; pulp_maven deploy has no authentication, and pulp_rust lacks it	Mature access control with SSO; confirm features by tier
Vulnerability scanning	Trivy enabled with --with-trivy; Trivy 0.75.0 bundled in v2.15.4; feed updates need a plan offline	No general scanner; pulp_container reports are tech preview, so confirm before relying on them	Xray is a higher-tier or add-on product; confirm offline vulnerability database support
Plugin or feature maturity	Mature core; confirm the Harbor release line and upgrade notes before each cutover	pulp_rpm, pulp_python, pulp_container and pulp_deb are past 1.0; pulp_maven, pulp_npm and pulp_rust are 0.x or tech preview	Mature product with an 18-month support window per minor version
Distribution registry as minimal option	Distribution is the base Harbor extends; it lacks replication, access control and auditing	Not applicable	Not applicable

How Harbor replication and Skopeo carry content across the gap

The core pattern is two steps. In a connected zone, you sync the images, Helm charts and packages you need into a staging store. You then move that content across the boundary on approved media and push it into an internal Harbor or Pulp instance that has no route back out. Harbor covers the OCI side of this. Its replication endpoints can point at another Harbor or at Docker Hub and other registries, and replication rules can run push-based or pull-based. In the connected zone, a pull-based rule against a Harbor instance you control can stage content, while a push-based rule can write to a store that is later exported. Rules filter by repository name, tag, label and resource type, so you can limit each transfer to an approved list. Each rule can run manually, on a cron schedule or on push and retag events, and an optional bandwidth limit keeps large transfers from saturating the link.

For content that must be exported as files, Skopeo is the simpler tool. It copies images between registries without privileges and can sync an external repository to a local directory, which gives you an archive you can hash, scan and carry across the gap. Pulp covers the non-container formats in the same way, since its repositories can be synced from upstream and then published internally. Confirm with your security and accreditation owners how transfer media is verified and approved before anything crosses the boundary. That process should define who signs off on each batch, how checksums or signatures are recorded, which malware and vulnerability scans run on the staged content, and how rejected media is destroyed or quarantined. Harbor's Trivy scanning can help with the image side, but it does not replace your own approval gate, and the same check should apply to every package that crosses.

Choosing the transfer pattern for your network

In a fully disconnected enclave, nothing crosses the boundary except media that someone carries across on a schedule. Harbor and Pulp both run inside the enclave, and neither can reach upstream registries directly. Proxy cache projects therefore have no upstream to pull from, so the enclave runs as a set of stores that are filled in bulk. Pulp is the better fit for building the import set, because it can sync repositories in a connected staging environment and export the result to a directory for transfer. Harbor receives images through replication from a local Harbor or from files prepared outside the boundary.

Import set: Build a fixed manifest of images, Helm charts, and packages for each transfer window, and record the digest of every item before it leaves the staging side.
Approval: The security team approves the manifest and the data owner approves the import, with both sign-offs stored with the transfer record.
Verification after import: Recompute digests on the enclave side and compare them with the manifest before any content is published to a project or repository.
Rebuild: Re-run vulnerability scans in Harbor with Trivy using an offline vulnerability database that you update through the same controlled transfer, since the scanner cannot fetch updates on its own.
Signatures: Verify image signatures and package metadata again inside the enclave, because the signing keys and trust roots must also arrive through the approved path.

Confirm with your security team how media is handled, logged and destroyed, and whether the enclave accepts the transfer format your staging side produces.

How to deploy an air-gapped Artifactory alternative in phases

This sequence moves container images, Helm charts and selected packages into a self-hosted Harbor and Pulp stack inside an isolated network, with each phase closed by a check that the content and the team's access are in place before the next phase starts.

Confirm requirements and target release versions
The platform owner and the security lead list the artifact types in use, the upstream sources that must be mirrored, and the transfer method across the air gap. Then they check the Harbor release notes for the target line. Harbor v2.15.2 upgrades the bundled internal database from PostgreSQL 15 to PostgreSQL 18 on container startup and replaces Redis with Valkey as the cache backend, so any existing deployment on an older line needs that change in its plan. The release notes recommend a backup before upgrading and a reindexdb run if index problems appear. Confirm the pulpcore release and the plugin versions for each package format you need. Done when the requirements list and a written version pin for each component are approved by the change board.
Stage the Harbor offline installer and images
On the connected side, the platform engineer downloads the Harbor offline installer from the official install documentation and verifies its checksum. The same engineer pulls the container images that the Harbor and Pulp deployments depend on, including Trivy if vulnerability scanning is enabled with the install-time option. Everything is written to approved removable media or a one-way transfer channel that your security policy permits. Record the hash of each file in the change record so the isolated side can verify it. Done when every file in the transfer manifest has a matching hash on the import side.
Install and back up the internal Harbor instance
Inside the isolated network, the platform team installs Harbor from the offline bundle with its configuration file, integrates LDAP, AD or OIDC for single sign-on, and creates projects with role-based access control. Before any content is loaded, they take a backup of the database and the configuration and store it outside the cluster. Vulnerability scanning is validated against the bundled Trivy database that was staged earlier. Done when a test image can be pushed, pulled and scanned, and the backup restores into a scratch environment with the same results.
Prepare Kubernetes clusters from a private registry
For clusters built without internet access, the cluster engineers list the control plane images with kubeadm config images list, then pull them on the connected side and push them into the internal Harbor project. kubeadm init is run with the image repository flag so that it pulls from the private registry rather than from public sources. The platform team confirms that nodes and workloads resolve images only from the internal registry. Done when kubeadm init completes on the isolated network and a sample deployment starts with an image pulled from Harbor.
Set up Pulp syncs and storage
The package owner deploys pulpcore with the required content plugins, such as pulp_rpm, pulp_python, pulp_deb or pulp_npm, using the official container images that fit your orchestration. Storage is configured with the storage backend guide, and the database is set up in PostgreSQL. Content is synced from exported repositories or mirrored from a staging host so that every package carries its upstream source and checksum. Plugins still at 0.x, such as pulp_maven, pulp_npm and pulp_ansible, are tested against your real package set before they are relied on, and any tech-preview feature is kept out of production paths. Done when a sync completes, the content is served from the distribution, and a client installs a package from it.
Run replication and integrity checks
Harbor replication rules are configured with pull-based or push-based direction, filtered by repository name, tag or label, and set to manual or scheduled runs with a bandwidth limit suited to the transfer channel. The team compares image counts, tags and digests between the source set and the isolated registry, and verifies signatures where your policy requires them. Pulp content is compared by checksum against the transfer manifest. Note that Harbor 2.15.3 blocks webhooks to internal network addresses by default and fails signing of unsigned images in projects that enforce content trust, so test those paths. Done when the reconciliation report shows no missing or mismatched artifacts and the signed record is retained.
Cut over CI and image pull credentials
Build pipelines, Kubernetes image pull secrets and package manager configuration are repointed to the internal Harbor and Pulp endpoints. Old service account tokens are rotated, and the team confirms that no workload still references the external source. A rollback path is kept for a period set by the change board, using a proxy cache project pointed at the previous source during cutover. Done when a full build and deploy run completes with only internal endpoints and access logs show no calls to external registries.
Schedule upgrades and restore tests
The platform owner adds Harbor and pulpcore upgrades to a recurring calendar that follows the release lines and patch releases published for each series, and treats each upgrade as a change that starts with a backup. Each cycle includes restore tests, a review of the transfer manifest, and a check of the Trivy database update path. Ask the vendor or community for the support window of the line you run, and confirm it in your own change policy. Done when the first upgrade cycle is recorded with its backup, test results and sign-off.

When Artifactory's 18-month support window forces a decision

JFrog supports each self-managed Artifactory minor version for 18 months, and 7.111.x reaches end of life on October 23, 2026. If your air-gapped estate runs that line, the decision is no longer about features. It is about which path consumes less of your team's time before the window closes. Confirm the support dates and terms for your exact version directly with JFrog, in writing, because the end-of-life date governs what patches you can expect and when.

The first path is another upgrade cycle on the existing platform. For an isolated network, each release means building the offline bundle, moving it across the boundary, running the upgrade, and retesting the repositories your build and deployment pipelines depend on, including the offline Docker and Helm content and any remote repositories that were already disconnected from their upstreams. Each target version also needs its own validation of the transfer process, because the content you sync in on the outside must still match the signatures and checksums you verify on the inside. The cost is recurring: every support cycle repeats this work, and the staff time is spent on the platform rather than on the content.

The second path is a move to Harbor for OCI content and Pulp for multi-format packages. This is a one-time project with its own costs: designing the transfer workflow with Skopeo and Harbor replication, standing up the isolated registries, recreating the non-container repositories, and rewiring CI credentials and image pull secrets. Ask any implementation partner to price the migration, the staff training and the ongoing patch process as separate line items, so you can compare the one-time cost with the recurring cost of another Artifactory upgrade cycle over the period you plan to run the environment.

What assessors ask for from an offline registry

Assessors and regulators rarely accept a registry on its design alone. They ask what crossed the boundary, who approved it, how each item was checked, and whether the platform can be patched and restored. DeployOpen prepares this evidence, but auditors, certification bodies and the regulator decide what it proves.

Transfer records and approvals

Each import across the air gap needs a record: what was exported, from which source, when it moved, who approved it and who imported it. For Harbor replication or Pulp sync, keep the replication task history and the change ticket together. Ask the assessor which fields they expect, such as package name, digest, version and approver, and confirm your transfer log captures all of them before the first media move.

Integrity checks on each package

This is the control behind NERC CIP-013-2, which requires supply chain procurement processes to address verification of software integrity and authenticity of vendor software and patches. Record the digests or checksums computed on the source side and verified on the isolated side for every image, chart and package. Skopeo can copy images to a local directory for transfer, so confirm the digests survive that step and are compared, not just assumed.

Vulnerability scan records

Harbor can run static analysis of images with the open-source Trivy scanner, enabled at install time with the --with-trivy option. Keep scan reports with the image digest they describe, and note the scanner version and vulnerability database date, since results change as the database updates. An offline environment usually needs a locally updated database, so document how and when that database was refreshed and by whom.

Harbor access and audit logs

Assessors usually ask who pulled, pushed, deleted or changed a project, and when. Harbor's README lists role-based access control, LDAP, AD and OIDC single sign-on, audit logs and a REST API. Export audit logs to the site's central log store on a fixed schedule, keep the account roster linked to the identity provider, and test that a sample of entries can be traced to a named person and a change ticket.

Upgrade and backup procedures

Assessors want written, tested procedures for patching and restoring the registry. Harbor's v2.15.2 release notes recommend a backup before upgrading and a reindexdb run if index problems appear, and v2.15.3 introduced breaking changes for webhooks and content trust. Document the backup scope, the restore test result, the rollback steps and the release notes reviewed for each upgrade, and keep the offline installer for each version you run.

What does an air-gapped registry cost and take to run?

What cost components should I budget for an air-gapped Harbor or Pulp deployment?

Budget for five components: the servers or Kubernetes nodes that run Harbor or Pulp, the object storage that holds image layers and packages, the PostgreSQL database and its backups, the transfer media and staging hosts used to carry content across the gap, and the engineering time to operate upgrades. Harbor and Pulp are open source, so software licensing is usually zero, but the infrastructure and labor are real. For comparison, JFrog's pricing page counts storage and data transfer against 25 GB included on its Pro plan for SaaS, and its self-managed editions are priced by server count, so ask JFrog for the current figures for your topology. Get the vendor numbers directly from JFrog pricing.

Which costs are one-time and which recur every year in an isolated registry?

One-time costs include the initial architecture, the first build of the offline bundle pipeline, hardening, integration with your identity provider and the first documented runbook. Recurring costs include staff time for patching and upgrades, storage growth, backup testing, periodic transfer of new content across the boundary, and vulnerability scanning of what crosses it. Upgrades are the largest recurring item to plan for. Harbor v2.15.2 changed its bundled database from PostgreSQL 15 to PostgreSQL 18 and recommended a backup first, so each minor release is a planned change, not a copy. Agree in writing which of these items are inside a fixed-scope engagement and which fall under a retainer.

What makes the effort go up or down for an air-gapped registry?

Effort rises with the number of package formats, the number of upstream sources you must mirror, the size of your image catalog, how often your teams need new content, and how strict your transfer review must be. Mixed estates with Maven, npm, Python and RPM need more work than a Harbor-only container registry, because each Pulp plugin has its own maturity: some are past version 1.0, while pulp_maven, pulp_npm and pulp_gem are still 0.x. Effort falls when you standardize on fewer formats, use Harbor replication into an isolated registry, and automate the sync and scan steps. Ask the vendor or implementation partner to break the estimate down by format.

How long does an air-gapped registry deployment take?

The timeline depends on the scope agreed in writing, so no fixed duration applies to every network. A scope that covers only Harbor with an offline installer and one replication path is shorter than one that also builds Pulp mirrors, a transfer process with scanning and evidence collection, and an upgrade runbook. Ask for milestones tied to deliverables, such as a working offline install, a tested replication run across the gap, a restore test and a documented upgrade. Your change board and security review often set the longest steps, so include them in the plan from the start.

What does the work need from our own team?

Expect to supply a named owner for the registry, someone who can approve transfers across the boundary, access to your isolated network and hosts, storage and database capacity, and staff who can join acceptance tests and cutover. Your security team must define the transfer review and where scan results and signatures are checked. Your CI and Kubernetes teams must repoint image pull secrets and build pipelines to the internal registry. Confirm these roles early, because a missing approver often delays a transfer more than a technical fault does.

Can our team run an air-gapped registry without outside help?

Yes, if your team already runs Kubernetes or Linux services, PostgreSQL and object storage, and can follow Harbor and Pulp documentation. The harder parts are the offline transfer workflow, verification of content crossing the boundary, backup and restore testing, and keeping pace with each upgrade. Skopeo can copy images to a local directory for transfer, and Harbor offers an offline installer, but you must still design and document the process. Assess your staffing against those tasks and decide whether a retainer for upgrades and testing fits better than a one-time build.

What should a written quote for an air-gapped registry include?

A written quote should follow from a written scope and list the systems in scope, the package formats and upstream sources, the environments (for example, production and a test isolated network), the transfer process and its review steps, the handover documents, and any retainer for upgrades and continuous testing. Ask for the assumptions behind each line, including hardware or cloud capacity, who supplies it, and which upgrade windows are covered. Ask how the vendor will handle a Harbor or Pulp release that changes behavior, and whether the 18-month JFrog support window for your current Artifactory minor version affects your timeline. DeployOpen does not publish a price list, so the quote follows from the scope.

How DeployOpen works on this

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For an isolated Harbor and Pulp deployment, we scope the content flow across the boundary, build the registries inside the isolated network, and hand over runbooks the client's own team can operate.

How we scope

Inventory which container images, Helm charts and language packages the isolated network must receive, and from which upstream sources
Define the transfer path across the air gap, including who approves each import and how integrity checks are recorded
Agree the written scope, deliverables and timeline in writing before work starts, since most engagements are fixed-scope

How we build

Install Harbor from the offline installer and configure projects, role-based access, LDAP or OIDC single sign-on and audit logging
Deploy Pulp with the plugins your package formats need, and confirm each plugin's maturity against the version you intend to run
Test replication, sync and import steps end to end, including vulnerability scanning with Trivy and rejection of unexpected content

How we hand over

Document architecture, network boundary controls, the transfer procedure and evidence collected for each import batch
Provide backup and restore procedures, upgrade steps and a record of configuration changes for the client's operators
Run knowledge transfer sessions so the client's team can operate registries, rotate credentials and perform routine imports

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped separately from the build
Track Harbor and Pulp security releases and agree with the client how and when patches cross the isolation boundary
Prepare systems, controls and evidence for compliance assessments, while independent auditors and certification bodies issue any audit outcome

Self-hosted Artifactory alternative for air-gapped networks