Managed Harbor hosting

Engineering and securityOn-prem or sovereign site

A private container registry that scans and replicates your images and caches Docker Hub, run in Switzerland, the EU or your own datacentre. Pilae runs it on your own servers, or in Zurich, Switzerland, and eleven other Pilae Cloud regions.

Talk to us about Harbor

Licence: Apache-2.0
Runs on: Your own hardware, or any of twelve Pilae regions — six of them in Switzerland and the EU
Upgrades: Pinned, tested against your configuration, applied in your window
Upstream: goharbor.io

Running Harbor in production: what it takes

Deploy on PostgreSQL and a bucket
A version we have run, installed with Trivy, on its own PostgreSQL and an S3-compatible bucket or local disk for the layers. The bundled database container is left out, so its major upgrades never arrive unannounced inside a Harbor release.
Choose sign-on before the first user
Harbor locks itself into local accounts as soon as any account other than admin exists, so OIDC through Keycloak or your own IdP, such as Microsoft Entra ID, is set on the first day, before anyone else signs in.
Scan images and reclaim space
Trivy scans on push, and a project can refuse pulls of images at or above the severity you choose. Retention rules delete old tags, and garbage collection, run outside the backup window, gives the space back.
Back up the database, the bucket and the key
Daily, encrypted, to an offsite location in your chosen country, as one set. Once a month we restore all three into a scratch environment and pull an image from it.
Upgrade with a snapshot, not a downgrade
Harbor does not support downgrades, so the snapshot taken before an upgrade is the way back. Every upgrade is rehearsed on a copy and approved by you before the Pilae Agent applies it in your window and records it in the console.

What Harbor is, and who runs it

Self-hosted Harbor as a private container registry

Harbor is a container registry. It extends the open-source Distribution registry with what an organisation needs around it: projects with role-based access, vulnerability scanning with Trivy, signatures from Cosign or Notation, replication between registries, quotas and retention rules. Helm charts, signatures and SBOMs are stored beside the images as OCI artifacts.

It is for teams that build their own software and want the registry next to where it is built and run: a platform team leaving Docker Hub, Amazon ECR or Azure Container Registry, or one that pulls every base image through a proxy cache so its builds depend less on someone else’s rate limit. It usually sits beside GitLab or Forgejo, which hold the code and run the pipelines that push to it. Both have registries of their own; Harbor earns its place when you want one registry for every forge and cluster, with scanning, a proxy cache and replication between sites. It runs on dedicated machines close to your pipelines, on your hardware or in one of 12 Pilae Cloud regions, six of them in Switzerland and the EU, and answers only on your private network.

Harbor in production: scanning, garbage collection and upgrades

Trivy scans every image on push and again on a schedule. Its vulnerability database is republished several times a day and fetched from the internet; in an air-gapped site it arrives as an offline bundle instead. Garbage collection is the only job that deletes layers from storage, and it never runs during the backup. The database is copied first and the bucket after it, so every layer the database names is in the copy.

Probes read Harbor’s health endpoint every 60 seconds, and an alert reaches an engineer. The PostgreSQL database, the bucket and the key in /data/secret are backed up daily as one set, and restored as one set in the monthly drill. Upgrades go through the Pilae Agent in two stages: harbor.yml is migrated with the upstream prepare tool, then the database schema migrates when the new version first starts.

Harbor licence and editions

Harbor is Apache-2.0 and a graduated project of the Cloud Native Computing Foundation. There is no paid edition, no enterprise-only code and no fee per user or per image, so every feature on this page is in the release we deploy. That includes sign-on: OIDC covers Keycloak and Microsoft Entra ID, and LDAP covers a directory without OIDC. Pricing for our operation is on request. Talk to us about the images you want off Docker Hub.

Harbor system requirements

Before anything is deployed, this is what has to exist. We size it with you in the first session, and we say so when your own hardware is already enough.

CPU and memory: 4 vCPU · 8 GBThe upstream recommendation; the minimum is 2 vCPU and 4 GB. Trivy scans on the same machine, and a burst of pushes after a release is what uses the headroom.
Database: PostgreSQL 12+The only database Harbor supports, holding projects, tags, policies and scan results. We run our own rather than the container Harbor bundles.
Cache and job queue: Redis or ValkeyQueues replication, scans and garbage collection, and holds sessions. Harbor does not support Redis Cluster, so it is one instance, or Sentinel for failover.
Image storage: S3-compatible bucket or diskLayers are content-addressed and shared between tags. Deleting a tag frees nothing; the space comes back only when garbage collection runs.
DNS and TLS: 1 hostname · trusted certificateDocker and containerd refuse a registry whose certificate they do not trust, so every build agent and cluster node trusts the issuer. Harbor answers on the private network, and the gate on port 443 publishes it only if you choose to.

Migrating from Docker Hub to Harbor

Your own images come across with Harbor's pull replication: a Docker Hub endpoint, a rule filtered by repository and tag, and a schedule that keeps copying until the day you switch. Teams and access tokens do not come across: teams are rebuilt from your directory groups, and tokens are replaced by robot accounts. Harbor does not build images, so automated builds move into your CI, and Trivy scans take the place of Docker Scout. Image references are the bulk of the work: every Dockerfile, pipeline, Helm values file and manifest that names docker.io changes to your registry's hostname. Public base images keep coming from Docker Hub, but through a proxy cache project, so each one is fetched when it changes rather than on every build.

List every image reference
We search Dockerfiles, pipelines, Helm values, Kubernetes manifests and compose files for docker.io and for bare names such as nginx, which default to it. Each reference is either one of your repositories, which moves, or a public image, which goes through the proxy cache.
Replicate your repositories
A pull replication rule per Docker Hub namespace copies images and tags on a schedule, filtered to what is still in use. The rule signs in with a Docker Hub account that can read your private repositories, and where that account has a pull limit, a large estate is spread over several runs.
Replace teams and tokens
Docker Hub teams become Harbor project members from your directory groups. Access tokens in pipelines become robot accounts limited to one project, with an expiry date and a secret shown once.
Repoint, then freeze Docker Hub
Pipelines push to Harbor and deployments pull from it. A last replication run picks up anything pushed on the day, and the Docker Hub repositories stay untouched until a full release cycle has shipped from Harbor.

What a Harbor restore needs

s3://acme-harbor-registrylayers and manifests, 1.8 TB
- docker/registry/v2/blobscontent-addressed, never rewritten
- docker/registry/v2/repositoriestag links per repository
postgres/registryHarbor database, 4 GB
- project, artifact, tag, blobwhat each tag points to
- registry, oidc_usercredentials, encrypted
- retention_policy, quotarules and limits
/data/secret/keys/secretkeydecrypts the credentials above
harbor.ymlin your repository, generates the compose file
redisnot backed up: sessions and job queue
trivy-adapter/trivynot backed up: scanner database, fetched again
s3://acme-backupsoffsite, daily, encrypted

An example for acme. Layers sit in a bucket, PostgreSQL records which layers make up which tag, and a 16-character key in /data/secret decrypts the credentials Harbor stores in that database, such as replication endpoint passwords and CLI secrets. The three are backed up together: a database restored without its key comes back with every stored credential unreadable.

What Pilae is responsible for

A pinned version

A version we have run, not whatever latest resolves to that day.

A runbook

What it depends on, how it fails, what to do about it. In your repository.

A restore drill

Backups restored on a schedule. A backup nobody has restored is a file.

A patch window

Security updates in a window you agreed, with a rollback ready.

Someone watching

Every endpoint probed on the minute. An alert reaches a person, not a dashboard nobody opens.

Where it runs: zur1, fra1, fal1, gra1, ams1, hel1, lon1, ash1, hil1, sin1, tok1, syd1, on-premZurich, Frankfurt, Falkenstein, Gravelines, Amsterdam, Helsinki, London, Ashburn, Hillsboro, Singapore, Tokyo, Sydney, Your own hardware
Who holds the credentials: You do. Ours are separate, named, logged and revocable with one command. We ask before anything changes outside an agreed window.
If you leave: The machine, the data, the compose files and the runbook are already yours. Nothing stops when our access does.

What drives the price of running Harbor

Pricing is on request: a fixed price for onboarding, then a monthly price for Harbor, quoted in writing within five business days. The plans set what every deployment includes; these are the inputs the quote is built from.

Instance size: The CPU, memory and, where a model runs, the GPUs the app needs for your users and your data.
High availability: One machine with tested restores, or a replicated setup that keeps serving when a node fails.
Storage and backups: How much data it holds, how long backups are kept, and point-in-time recovery for its database.
Plan and support: Essential, Business or Enterprise: support hours, response times in the contract and how often we review the service with you.
Region: Your own hardware, where the infrastructure is already yours, or a Pilae Cloud region, where it is passed through at cost plus a fixed margin.
Sign-on and integrations: Single sign-on, directory sync, mail relays and the other systems the app has to reach.

Harbor: common questions

Is Harbor open source?

Yes. Harbor is Apache-2.0 and a graduated project of the Cloud Native Computing Foundation. There is no paid edition and no enterprise build: scanning, signing, replication, proxy caching and OIDC sign-on are all in the release we deploy.

What does Docker Hub do that Harbor does not?

Docker Hub builds images and is a public catalogue for distributing them to anyone on the internet. Harbor does neither. It holds your organisation's own images for your own pipelines and clusters, so builds run in your CI and public base images still come from Docker Hub, through the proxy cache.

Can Harbor run in an air-gapped site?

Yes. Harbor ships an offline installer, and images that have crossed the gap through your transfer process are pushed into it on the inside. Trivy normally downloads its vulnerability database, so in a gapped site the database arrives as an offline bundle and scans run in offline mode. Upstream notes that offline mode can find fewer issues in Java dependencies.

How do people and pipelines sign in?

People sign in through OIDC, with Keycloak or your own IdP such as Microsoft Entra ID, or through LDAP. The docker CLI cannot follow a browser sign-in, so each person uses a CLI secret from their Harbor profile. Pipelines and clusters use robot accounts scoped to a project, which expire after 30 days unless set otherwise.

Where do our images live?

Close to the pipelines that push them: on your own hardware, or on dedicated machines in the Pilae region you choose, in ISO 27001-certified datacentres. Layers sit in a bucket in the same place, and images go to a second registry only where you have set up a replication rule.

Back to apps

Bring us your Harbor. We will tell you what it takes.

Thirty minutes on the deployment you already have, or the one you are about to start.

Start with one workload Book a 30-minute briefing