# Running Harbor in Production on Kubernetes: HA, Storage, and Supply-Chain Guardrails

- Link: https://thestackobserver.com/running-harbor-in-production-on-kubernetes-ha-storage-and-supply-chain-guardrails/
- Published: 2026-02-24T11:04:32-05:00
- Author: Stackxx

Most teams adopt Harbor for one simple reason: “we need a private registry we control.”
In practice, Harbor quickly becomes far more than a Docker image cache. It turns
into an artifact control plane: a single place to push, scan, sign, replicate, and
gate what actually runs in production. That change in importance is why “it runs”
is not the same as “it’s production-ready.”

This article is a pragmatic guide to hardening Harbor on Kubernetes. It focuses 
on the operational choices that tend to bite teams later: availability and upgrades,
storage and performance, security controls (RBAC, scanning, signing), and the day‑
2 work of keeping the registry trustworthy when it is on the critical path for every
deploy.

## 1) Start with the reliability model: Harbor is a system, not a pod

Harbor’s Helm install makes it look like a single product, but production Harbor
is a set of services that must fail independently without breaking the whole experience:
the UI and API (“core”), job service, registry, database, cache, and optional scanners.
A production design begins with a reliability target (RTO/RPO) and a dependency 
map: “What happens if Postgres is down?” “What happens if object storage is slow?”“
What happens if one AZ is gone?”

Two patterns show up most often:

 * **Single region, multi-AZ HA** (most common): multiple replicas of stateless 
   services plus HA database and highly available storage.
 * **Multi-region**: a primary Harbor plus replication to a secondary registry, 
   often with region-local read access for CI/CD.

## 2) HA is a set of boring decisions—make them explicitly

The CNCF guidance on Harbor production readiness emphasizes the unglamorous but 
essential knobs: replicas for key components, an ingress front door, and removing
single points of failure in storage and the database tier. Don’t treat these as “
future optimizations.” If Harbor is on your deploy path, it’s a tier‑0 service.

Concrete actions that matter:

 * **Ingress + TLS**: terminate TLS correctly, automate certificates (e.g., cert-
   manager), and standardize hostnames early so clients and automation don’t embed
   temporary URLs.
 * **Replica counts for stateless components**: core/jobservice/portal/registry 
   and scanners can scale horizontally, but only if they share the right backend
   dependencies.
 * **PodDisruptionBudgets and topology spread**: prevent a rolling node drain from
   evicting all replicas at once; spread across zones when possible.
 * **Health checks that reflect reality**: a “ready” Harbor core that can’t reach
   Postgres is not ready.

## 3) Treat storage as a performance product (and pick your failure domain)

Registry performance is usually limited by storage behavior under concurrency, not
CPU. Decide whether you are comfortable with shared block/file storage in-cluster,
or whether you want an object-storage backend. In Kubernetes, the operational question
is less “Can I mount a volume?” and more “How does it behave during load spikes,
node failures, and upgrades?”

Key storage considerations:

 * **Latency and tail behavior**: image pulls in a large cluster amplify p95 and
   p99 latencies. A small regression becomes widespread deployment slowness.
 * **Consistency and failure recovery**: how do you detect partial writes, and how
   do you repair?
 * **Backup/restore**: you need a tested restore plan for metadata and artifacts,
   not just snapshots.

If you keep storage “inside” the cluster, your failure domain often becomes the 
cluster itself. If you externalize to object storage, your failure domain shifts
to the storage service—often a better trade if that service already has stronger
durability and operational maturity.

## 4) Fix the database story before you have a bad day

Harbor can ship with an embedded database option, but production usually means running
Postgres with HA and clear operational ownership. The database is where Harbor’s
metadata lives: projects, RBAC bindings, robot accounts, replication policies, and
artifact bookkeeping. A registry with corrupted or unavailable metadata is effectively
down.

Production DB checklist:

 * **HA Postgres** (operator-managed, or managed service): define failover, backups,
   and maintenance windows.
 * **Connection pooling**: Harbor components can generate noisy connection patterns;
   pooling can be the difference between stability and a cascading failure.
 * **Schema upgrades**: practice Harbor upgrades in staging with production-like
   data volumes.

## 5) Security controls: make Harbor your policy boundary

Harbor’s value is not only hosting images; it is giving you a policy boundary that
aligns with how clusters actually run software. Three controls are worth treating
as first-class features, not “nice to have” toggles:

 * **Vulnerability scanning**: scanning isn’t useful unless it drives a workflow.
   Decide which severities block promotion, how exceptions are tracked, and how 
   often re-scans happen as CVE databases update.
 * **Artifact signing**: signing gives you provenance, but only if your runtime 
   enforces it. Pair Harbor signing with admission controls in Kubernetes so unsigned/
   untrusted images can’t deploy.
 * **Least-privilege access**: use projects, teams, robot accounts, and short-lived
   credentials where possible. Audit who can push vs who can pull.

In practice, the strongest pattern is a multi-stage promotion flow: build artifacts
into a “build” project, scan and sign them, then replicate/promote into a “release”
project used by production clusters. That creates a clean line between “things we
made” and “things we run.”

## 6) Day‑2 ops: observability, quotas, and predictable upgrades

A production registry without telemetry is an outage waiting to happen. Harbor needs
metrics and logs that answer a few operational questions quickly: “Are pulls failing?”“
Is storage saturated?” “Which projects are generating load?” “Are scanners backed
up?”

Day‑2 practices to institutionalize:

 * **SLOs for pull success rate and latency**: treat CI/CD and cluster pulls as 
   customer traffic.
 * **Quotas and retention policies**: storage grows forever unless you design lifecycle
   rules.
 * **Replication as resilience**: even without multi-region requirements, replication
   can be a recovery tool.
 * **Upgrade drills**: test Harbor upgrades, database migrations, and rollback procedures
   in a staging environment that mirrors production.

## 7) The bottom line: Harbor is your supply-chain backbone

As Kubernetes becomes the default platform for everything—from web services to ML
training pipelines—the artifact registry becomes the most leveraged security and
reliability control point in the stack. Making Harbor “production-ready” is less
about tuning a Helm chart and more about accepting that the registry is critical
infrastructure. Build it like one: define failure modes, invest in HA dependencies,
and wire scanning/signing into a promotion workflow that your cluster actually enforces.

## Sources

 * [CNCF: Making Harbor production-ready: Essential considerations for deployment](https://www.cncf.io/blog/2026/02/24/making-harbor-production-ready-essential-considerations-for-deployment/)
 * [Harbor project site](https://goharbor.io/)