Why an air-gapped network needs a self-hosted Docker Hub alternative
An air-gapped cluster has no Internet route, so every image it runs must already sit inside the isolated network before a pod is scheduled. Pulls from Docker Hub either fail outright or depend on a proxy that has a route out, and that proxy becomes a control point the security team must approve, monitor and keep patched. The main option is a self-hosted Harbor registry installed from the offline installer, which bundles pre-built images for hosts with no connection to the Internet, and loaded with images through a controlled transfer host. Harbor's documentation for the offline installer covers the installation step itself.
A common shortcut is Docker's registry mirror, but it does not solve the isolation problem by itself. The mirror is a pull-through cache that fetches the first pull of each image from registry-1.docker.io, so it needs a network route to Docker Hub and cannot serve a fully isolated network on its own. Confirm this with your network team before assuming a mirror is acceptable, because even a mirror on a DMZ host extends the trust boundary toward Docker's servers.
The practical design is a one-way transfer. A connected host pulls the approved images and writes them to removable media or an approved transfer path, using Skopeo's skopeo sync to copy images into a local directory, and the isolated side imports them into Harbor. Decide before the first transfer who approves each image, how digests are recorded, and how signatures and vulnerability scan results travel with the content, because those checks are the evidence that a control such as the supply chain requirement in NERC CIP-013-2 is working.
What an air-gapped registry must do
An isolated network needs a registry that holds everything it pulls, admits content only through a checked import path, and records every decision inside the enclave. The cards below cover those requirements in the order a registry team meets them, from the removal of upstream dependencies to the audit trail that proves what ran.
No runtime dependency on upstream
A cluster on an isolated network cannot reach Docker Hub, and a Docker Hub mirror still needs a route to registry-1.docker.io for first pulls. The registry must therefore serve every image from local storage, with no proxy fallback that depends on an outside host. Confirm that no node, base image or Helm chart in your clusters references an external registry hostname, because one missed reference causes a failed pull at 2 a.m.
Controlled import across the boundary
Every image crossing the boundary should arrive through one transfer host or removable media with a recorded digest, scan result and approval. Skopeo can sync an external repository to a local directory or to an internal registry, which gives you a single, repeatable import step. Under NERC CIP-013-2, procurement processes must address verification of software integrity and authenticity, so keep the digest manifest with the transferred content.
Offline installation and updates
Harbor's offline installer bundles the pre-built images it needs, so the registry itself can be installed on a host with no Internet connection. Plan the same offline path for every later upgrade, because each release brings its own images and database changes. Read the release notes before importing a new version, since v2.15.2 moved the bundled database to PostgreSQL 18 and recommends a backup first.
Pulls served to isolated clusters
The OCI Distribution Specification requires every conforming registry to support pull, so clusters only need the registry's API and a trusted certificate, not an Internet route. Point kubeadm at the internal registry with its image repository flag, and pre-pull the control plane images while the transfer host still has access. Test a pull from a node with its default route removed before cutover.
Signatures and SBOMs in the enclave
The OCI referrers API at /v2/<name>/referrers/<digest> lists manifests such as signatures and SBOMs that point at an image. Imported signatures and attestations are only useful if they travel with the image digest and remain queryable inside the enclave. Confirm that your transfer process copies referrers, not just tags, and test a lookup on the internal registry before relying on it.
Access control, scanning and audit
Harbor adds projects with role-based access control, LDAP, AD or OIDC sign-on, vulnerability scanning through Trivy, garbage collection and audit logs. Trivy must be enabled at install time with the --with-trivy option or connected to an external scanner, and its vulnerability database must also be updated through the transfer path. Ask who owns the scanner feed and how audit logs leave the enclave for review.
Which open-source options fit an isolated network
This table compares four self-hosted options for an isolated network: Harbor installed from the offline installer, the bare Distribution registry, Pulp for non-container packages, and Gitea or Forgejo package registries. Read each row against your own constraint, such as image signing, package types and who must approve imports across the boundary.
| Option | How it meets the air-gap constraint | Trade-offs to weigh |
|---|---|---|
| Harbor (offline installer) | The offline installer bundles pre-built images for hosts with no Internet connection. Images arrive by Skopeo sync to removable media or by replication from a transfer host. | Adds RBAC, LDAP/AD and OIDC sign-in, Trivy scanning, garbage collection and audit logs. Requires PostgreSQL and Redis or Valkey upkeep and offline patch cycles. |
| Distribution registry alone | The Apache-2.0 registry runs with no external dependencies, so it can sit on a fully isolated segment. | A bare registry with no built-in projects, access control UI, scanning or replication. Your team builds those controls, audit trail and retention itself. |
| Pulp (non-container packages) | Pulp serves Maven, npm, Python, RPM and Debian content through plugins, and can be loaded from exported content. | Covers packages but not OCI images. Pair it with Harbor, and confirm each plugin's offline sync path in your environment before go-live. |
| Gitea or Forgejo package registries | Both host Container, Helm, Maven, npm, PyPI and other formats for private hosting, so packages can live beside source code. | Their documentation does not describe proxying or caching upstream registries such as Docker Hub or Maven Central, so every artifact must be imported by hand. |
| Nexus Repository Community Edition | Can host and proxy several formats, so it may cover a mixed estate on one server. | Usage is capped at 40,000 components and 100,000 requests per day, and the EULA must be accepted. Confirm the caps fit your estate before you rely on it. |
| Vendor air-gapped editions | Air-gapped deployment is offered by several vendors, including Mattermost Enterprise Advanced and Metabase Enterprise. | Often a paid-tier feature. Ask each vendor in writing which edition includes offline installation, and what it costs, before you plan around it. |
How to load and serve Harbor across the air gap
This sequence moves a vetted set of images and Helm charts from a connected staging host into an isolated Harbor registry, so clusters with no Internet route can pull everything they need from inside the network.
Stage the offline installer on the connected side
On a connected staging host, download the Harbor offline installer, which bundles pre-built images, and verify its checksum against the release page before copying it to removable media. Harbor's documentation says the offline installer is the path to use when the target host has no Internet connection. The step is done when the bundle and its checksum are stored in the transfer folder with the version recorded, for example the release tag you chose from the Harbor releases page.
Copy images and charts into a transfer directory
Use Skopeo sync to copy the approved image repositories and tags from their upstream registries into a local directory on the staging host. Skopeo's README lists this as a standard air-gap workflow, and it can write to a directory that can later be placed on removable media. Include Helm charts as OCI artifacts in the same run. The step is done when the directory holds every tag in the approved list and the manifest count matches your inventory.
Verify digests and scan before transfer
Before anything crosses the boundary, record the digest of each image and chart, compare them against the upstream values, and run a static scan on the staged content. Security reviewers should confirm the approved list and check the findings against your policy. Your change control or NERC CIP-013-2 supply chain procedure should define who signs off. The step is done when a signed manifest of digests and scan results exists for the batch.
Carry the batch across approved media
Move the installer bundle, the image directory and the verification manifest across the boundary using the media and transfer process your security policy approves. Keep the transfer under the same custody record used for other controlled imports. The step is done when the destination host confirms the file counts and checksums match the staging record, which gives you an audit point before any data is loaded.
Install Harbor and import the content
On the isolated host, run the offline installer with the --with-trivy option so Trivy is enabled at install time. Then use Skopeo to copy the images and charts from the transfer directory into the local Harbor projects. Confirm that Harbor's Trivy database is loaded from the offline source, since scanning must not depend on an Internet connection. The step is done when a test pull from a node in the isolated network succeeds and a scan report appears for the imported images.
Configure projects, RBAC and cluster pull configuration
Create Harbor projects that match your approved sources, assign roles through your LDAP, AD or OIDC identity source, and set the access policy for each project. On each Kubernetes node, point the container runtime at the internal registry and create pull secrets in each namespace. For new control plane builds, use kubeadm config images list and pull to stage the images, then pass --image-repository to kubeadm init so it reads from the internal registry. The step is done when a cluster creates pods from the internal registry without any external route.
Repeat the transfer cycle and log each batch
For each update, repeat the staging, verification and transfer steps with a new batch, then import it into Harbor and keep the previous batch available for rollback. Record every batch with its source date, digests, scan results, transfer custody and import result, so auditors can trace each image in production. The step is done when every batch has a closed record and the registry's audit logs show the import activity.
Evidence assessors ask for under this constraint
An assessor reviewing an isolated Harbor registry will ask how content got across the boundary, who controls what enters, and whether the platform stayed patched and scanned. The cards below list the records your own assessor is likely to request. DeployOpen prepares evidence and documentation for your assessment, but it does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work.
Transfer logs and hash records
Each batch carried across the isolated boundary needs a log showing what moved, when, by whom and through which transfer host. Record a digest for every image and chart in the batch, taken before and after transfer, so the receiving side can prove nothing changed in transit. When Skopeo syncs to a local directory on removable media, keep the directory listing and digests with the media record. Confirm with your assessor which hash algorithm and log format they accept.
Harbor configuration and RBAC exports
Export the Harbor project list, role assignments per project, replication rules, proxy cache settings and the authentication source, whether local accounts, LDAP/AD or OIDC. Assessors use these exports to confirm that only defined roles can push, pull or change retention. Store exports from each change window so you can show the configuration in effect on any given date, not only today.
Trivy scan results and finding handling
Harbor's vulnerability scanning uses Trivy, enabled at install time with --with-trivy, and Harbor v2.15.4 bundles Trivy 0.75.0. Keep scan reports for every image promoted into the isolated registry, plus a record of how each high-severity finding was accepted, fixed or deferred and by whom. Note the Trivy database version used, because an offline scanner only knows what its database was last updated with. Confirm how your team refreshes that database across the boundary.
Installer version and upgrade records
Record the offline installer version in use and every upgrade applied. 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. The release notes recommend a backup before upgrading and a reindexdb run if index problems appear, so keep the pre-upgrade backup, the restore test result and the post-upgrade check for that change. Also track v2.15.3, which blocks webhooks to internal addresses by default.
Who can approve imports
Write down the named roles allowed to approve content entering the isolated network, the approver for each batch and the second reviewer who checks the hashes and scan results. Assessors compare this list against the transfer logs to confirm that no batch moved without approval. Keep the approval record separate from the people who perform the transfer, and review the list whenever staff change roles.
Boundary and supply chain controls
Map each import step to the supply chain control in NERC CIP-013-2, which addresses verifying the integrity and authenticity of software and patches from vendors. Show how a package is verified before it crosses the boundary and how the verification record links to the transfer log. If your environment is also subject to NERC CIP-005-7, document how the transfer host connects to the electronic security perimeter. Confirm the exact requirements with your compliance lead, since applicability depends on your impact classification.
Questions teams ask before an air-gapped registry project
Can our team run an air-gapped Harbor registry ourselves?
Often yes, if you already operate Kubernetes or Linux servers, PostgreSQL and a backup process, and you have someone who can own the registry after go-live. The Harbor offline installer bundles the images it needs, so the install itself is not the hard part. The harder parts are the transfer process across the boundary, certificates and DNS inside the isolated network, identity integration, and keeping a tested upgrade path. Ask whether your staff have run a service that receives external content through a controlled transfer host. If not, budget for that learning curve or bring in outside help under a written scope.
What drives the effort and cost of an air-gapped registry?
The main drivers are the number of upstream sources you replicate or proxy, how many images and tags you carry, how often you move content across the boundary, whether you scan images, and whether the registry must be highly available. Each upstream adds rules to maintain and more content to verify. A larger tag history means more storage and longer transfers. Scanning needs a vulnerability database that must also be refreshed across the gap. High availability adds replicas, shared storage and a load balancer. Ask any provider to price each of these drivers separately so you can see which ones you can reduce.
Which costs are one-time and which recur?
One-time costs usually cover architecture, the initial installation, the first bulk transfer, identity and certificate setup, and documentation of the transfer procedure. Recurring costs cover staff time for each transfer cycle, patching and upgrading Harbor and its database, rotating certificates, reviewing scan results, restoring test backups and keeping the runbook current. Infrastructure such as servers and storage is paid on a cycle as well. Ask a quote to separate these lines and state who pays for each, your staff, your cloud or hardware budget, or a DeployOpen retainer if you choose one.
How long does an air-gapped registry project take?
The duration depends on scope rather than on a single standard number. A single cluster pulling a short list of base images is a different project from a multi-site estate with several upstreams, scanning, high availability and an audit trail. Timing is also shaped by change approvals, hardware lead times and how quickly your security team can review the transfer process. Ask for a written timeline tied to named deliverables and dependencies, and check which milestones require your approval before the next phase starts.
What skills and staff time does the work need?
Plan for people who understand Linux administration, container runtimes, Kubernetes image pull configuration, DNS and TLS, PostgreSQL backups and your identity provider. Someone must own transfer approvals and the evidence that each imported artifact was checked, which often falls to a security engineer. A platform owner needs time for upgrades and incident response. Harbor's upgrade notes for recent releases call for backups before upgrading and can require database reindexing, so these tasks need a named owner and a rehearsed window, not ad hoc effort.
How do Harbor and image updates cross the air gap?
Updates move in a controlled batch. On the connected side, you pull or sync the images and the Harbor offline installer package, then copy them to removable media or a transfer host approved for the boundary. Skopeo can sync an external repository to a local directory, and that directory can be carried across. On the isolated side, you load the content into Harbor, through push or replication, and verify digests and scan results before clusters can use it. Some Harbor releases contain breaking changes, so read release notes before each upgrade and test in a non-production instance first. Your procedure should also cover the signed or verified status of each artifact, which supports the software integrity checks expected under NERC CIP-013-2 for utilities and similar regulated environments.
Does a paid Docker plan remove the need for this work?
A paid Docker plan can raise pull allowances and add access controls, but it does not give an isolated network a route to Docker Hub. Docker's registry mirror still fetches images from Docker Hub, so it needs connectivity that an air-gapped network does not have. If your constraint is the boundary itself, a paid plan does not solve the problem. If your constraint is only pull limits on connected systems, a plan may be cheaper than a registry. Confirm the current plan limits and network requirements with Docker before you decide, and compare them with the transfer and operating costs described above.
Keeping an isolated Harbor current
Harbor upgrades in an isolated network are a transfer job, not a download. The connected side has to fetch the release, verify it, and carry it across the boundary before the air-gapped registry can change. Harbor's latest stable line is v2.15.4, published on October 9, 2026, and the 2.14 and 2.13 lines still receive patch releases (v2.14.5 and v2.13.6 on October 6, 2026). Decide which line the isolated registry will follow, then stage the matching offline installer from the Harbor installer documentation rather than letting the air-gapped host drift across major lines.
Read the release notes before any package crosses the boundary. Harbor v2.15.3 fixed a batch of security advisories but also introduced two breaking changes: webhooks to internal network addresses are blocked by default, and signing unsigned images now fails in projects that enforce content trust. Any internal webhook used for CI notifications or scanner callbacks needs an explicit allowance, and any project with content trust enforcement needs its signing workflow tested in a staging instance first. Also note that v2.15.2 moves the bundled database from PostgreSQL 15 to PostgreSQL 18 on container startup and replaces Redis with Valkey, so the database change happens without a separate migration step.
Back up before every upgrade, and treat the backup as part of the transfer package. The v2.15.2 release notes recommend a backup before upgrading and a reindexdb run if index problems appear, so confirm the database dump and registry storage snapshot restore on a test host before the production upgrade. Ask your team to verify that the signed installer and images match the checksums published on the connected side, since NERC CIP-013-2 expects software integrity checks on vendor software crossing into controlled networks. Schedule upgrades only after the staging restore succeeds, and keep the previous installer on the isolated side until the new version has run cleanly.
How DeployOpen deploys Harbor under an air-gap constraint
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 Docker Hub replacement, we scope the image transfer path, build the Harbor registry from the offline installer, and hand over the procedures your teams need to keep it current.
How we scope
- Written scope listing which upstream images, Helm charts and projects move into the isolated network
- Agreed inventory of clusters, CI runners and hosts that will pull from the internal registry
- Defined transfer method, whether Skopeo sync to removable media or replication through a transfer host
- Fixed-scope engagement with deliverables and timelines agreed in writing before work starts
How we build
- Harbor installed from the offline installer on hosts with no Internet route, with prerequisites checked first
- Trivy scanning enabled at install time and configured for the isolated network
- Role-based access control, LDAP or OIDC single sign-on and audit logging wired to your identity systems
- Integrity checks on every image and chart carried across the boundary before it reaches production clusters
How we hand over
- Runbook for the transfer cycle, from export on the connected side to import and verification inside
- Configuration and architecture documentation covering backup, garbage collection and upgrade steps
- Test evidence showing that clusters pull successfully with no external route, ready for your assessors
- Knowledge transfer sessions so your platform team can run the registry without us
How we support
- Ongoing support, upgrades and continuous testing available as a retainer after handover
- Review of each Harbor patch release and its breaking changes before it reaches the isolated network
- Confirmation of backup and restore steps ahead of every major upgrade
- Retainer scope agreed in writing, with the quote following from the written scope
