readystack/harbor repository overview

⁠Harbor

readystack/harbor:v2.15.4-CE-ubuntu24.04-r4

Source, recipe and records

• Source and build recipe: https://readystack.dev/products/harbor/recipe⁠
• Upstream source at this release's pinned commit (v2.15.4): https://github.com/goharbor/harbor/tree/0a6bf30d54e779962ad5b862fc67e3e9f6b010d8⁠
• Product page: https://readystack.dev/products/harbor⁠
• Hermetic Build Kit for this release (free with an account): https://readystack.dev/products/harbor⁠
• Release history (JSON): https://readystack.dev/api/releases/harbor⁠
• Defect record: https://readystack.dev/defects.html?product=harbor⁠
• Today's scan: https://readystack.dev/products/harbor#pp-grade⁠
• Report an issue: https://github.com/ReadyStackFree/readystack/issues/new?template=bug.yml&product=harbor⁠
• Signing key (cosign): https://readystack.dev/keys/cosign.pub⁠

A cosign-signed build of github.com/goharbor/harbor v2.15.4 (Apache-2.0); registry from goharbor/distribution v2.8.3-harbor.2, built clean-room from official upstream source by ReadyStack⁠.

⁠Who uses it and why

Who: Platform and DevOps teams who run their own container registry for Kubernetes and other container platforms.

Why: Harbor is an open-source registry that stores container images, scans them for vulnerabilities, signs them, controls access by role, and replicates images between registries.

Use case: A company wants every image its clusters run to come from a registry it controls. Teams push images to their projects in Harbor, each image is scanned for vulnerabilities, a policy check keeps vulnerable images from being deployed, and replication copies images to a second registry near another data centre.

About the upstream project, written from its own description: https://github.com/goharbor/harbor⁠ · https://goharbor.io/⁠

⁠What you get

Signature, user and attestations below were measured on the published digest sha256:36980e0177580698559fc2fa250cc8b78990b95e49ef894d2621cdbbeba45708 on 2026-10-29.

• Scan scores — we scan every image we publish every day (an SBOM made with syft, vulnerabilities matched with grype, scored with cerodeo-v1, the rubric ce.rodeo published until 2026-10-26) and record each scan with how its score was derived. This release's first and latest scan: https://readystack.dev/products/harbor⁠
• ReadyStack release check — passed at release on 2026-10-28: no fixable critical or high vulnerability (Docker Scout and OSV), a non-root user, SBOM and provenance attached. This is ReadyStack's own test, not a Docker grade; vulnerabilities published since then are in today's result at https://readystack.dev/queue⁠.
• Signed — cosign signature by the ReadyStack release key (fingerprint 04daa92344a52dbc) on this release's index digest sha256:36980e0177580698559fc2fa250cc8b78990b95e49ef894d2621cdbbeba45708; verify with cosign verify --key https://readystack.dev/keys/cosign.pub readystack/harbor:v2.15.4-CE-ubuntu24.04-r4.
• Attestations — An SPDX SBOM and SLSA v1 build provenance are attached to this digest.
• Runs as a non-root user (harbor).
• Built from source by ReadyStack.

⁠Which tag should I pull?

This image follows the ReadyStack release-tag convention:

• The current release is v2.15.4-CE-ubuntu24.04-r4 — the release listed at readystack.dev. Release tags use the pattern <upstream-version>-CE-<base-os>-r<N>; the current one is signed, attested (SBOM + provenance), and is provided under the ReadyStack Agreement⁠.

• Earlier release tags (an older version or revision in the same pattern) are superseded. They stay pullable so existing deployments can pin them, but they are no longer re-graded, and fixes appear only in newer releases: move to the current release. For a superseded release's build kit, ask support.

• Release tags never move, so pulling the same tag again never changes the image. To be offered each new release automatically (a new revision r<N+1>, or a new upstream version), use the ReadyStack Renovate preset: https://readystack.dev/updates.html⁠

• Any tag beginning with internal- is an engineering-pipeline artifact published for build observability. It is unsupported, may change or disappear without notice, and must not be used in production.

# ✓ current release
docker pull readystack/harbor:v2.15.4-CE-ubuntu24.04-r4

# ✗ unsupported (do not pull)
docker pull readystack/harbor:internal-...

This release is signed; verify it with cosign verify --key https://readystack.dev/keys/cosign.pub readystack/harbor:v2.15.4-CE-ubuntu24.04-r4 (the signature is recorded in the public Sigstore transparency log). Support: [email protected]⁠, as set out in the ReadyStack Agreement⁠.

⁠Deployment

One non-root container running Harbor's own processes under supervisord: core (API, auth, token service, /v2 proxy), jobservice (replication, garbage collection, retention and other jobs), registryctl, the registry, and nginx serving the web portal on port 8080. PostgreSQL and Redis are NOT inside the image: point it at your own PostgreSQL database and Redis server. No vulnerability scanner is bundled; register an external scanner (for example a Trivy adapter) in Administration > Interrogation Services if you want scanning.

Secrets go in env files that only you can read, not on the command line, and passwords that only set up the first start come out of them after setup. Create each file with install -m 600 /dev/null <file>, then write its lines into it with an editor, with your own values (a value typed into a shell stays in its history). Docker reads each line as written: no quotes around a value, no spaces around =.

harbor-db.env:

# First start only: the postgres image reads POSTGRES_PASSWORD only when it initialises its empty volume. You can remove this line after the first start and recreate the db container; the database keeps the password.
POSTGRES_PASSWORD=YOUR_DB_PASSWORD

harbor.env:

# Needed at every start: the same database password as POSTGRES_PASSWORD (no spaces or backslashes, and not beginning with a single quote).
POSTGRESQL_PASSWORD=YOUR_DB_PASSWORD
# Becomes admin's password only when Harbor first initialises its database, but this image does not start without it. After setup, replace HARBOR_ADMIN_PASSWORD's value with any other text and recreate the container; admin keeps the password.
HARBOR_ADMIN_PASSWORD=YOUR_ADMIN_PASSWORD

docker network create harbor-net
docker run -d --name harbor-db --network harbor-net -e POSTGRES_DB=registry -e POSTGRES_USER=harbor --env-file ./harbor-db.env -v harbor-db:/var/lib/postgresql/data postgres:16
docker run -d --name harbor-redis --network harbor-net -v harbor-redis:/data redis:7-alpine
docker run -d --name harbor --network harbor-net -p 8080:8080 -e POSTGRESQL_HOST=harbor-db -e POSTGRESQL_USERNAME=harbor -e POSTGRESQL_DATABASE=registry -e REDIS_HOST=harbor-redis -e EXT_ENDPOINT=http://localhost:8080 --env-file ./harbor.env -v harbor-data:/data readystack/harbor:v2.15.4-CE-ubuntu24.04-r4

Use a database password without spaces or backslashes that does not begin with a single quote (Harbor core puts POSTGRESQL_PASSWORD unquoted into its connection string, so the container stops at start with such a password), and set REDIS_PASSWORD only when your Redis requires one. Use the same database password for POSTGRES_PASSWORD in harbor-db.env and POSTGRESQL_PASSWORD in harbor.env. HARBOR_ADMIN_PASSWORD becomes admin's password when Harbor first initialises its database; this image refuses to start without the variable, so after setup replace its value in harbor.env with any other text and recreate the container on the same volume (docker rm -f harbor, then its docker run line again): admin keeps its password, which is then no longer in the container's environment (tested).

⁠The full ReadyStack Hermetic Build Kit

The complete --network=none build kit for this image — plus admin/DB/API handbooks, the build's validation records, and its build provenance records — is a free download for any registered account at readystack.dev/products/harbor⁠. A clean-room rebuild from this release's archive on an egress-blocked host reproduced its linux/amd64 digest sha256:de9ac3f2a6d3b26febe333400f1a1200a3b00500805310187c77769ab286bcee on 2026-10-29.

— ReadyStack · readystack.dev

⁠Tags no longer offered

These tags are on Docker Hub but ReadyStack does not offer them. They are kept so existing pulls do not break, but they are unsupported and receive no security updates; do not use them in production. Use the current release named on this page.

• v2.15.4-CE-ubuntu24.04-r1 — pushed to Docker Hub on 2026-10-20 before the final release gate, which then refused it (Ubuntu apache2-utils 2.4.58-1ubuntu8.17 security fix, published after it was built); never on sale; the fixed build will be v2.15.4-CE-ubuntu24.04-r2 (labelled 2026-10-20)