Harbor v2.15.2 adds policy to OCI artifact storage
Harbor v2.15.2 sits between OCI clients and stored artifacts, adding controls that a bare registry leaves to other systems. Projects divide repositories and permissions. OIDC, LDAP, or the local database handles people, while robot accounts serve automation. Replication policies move artifacts between registries, Trivy can scan them, and retention plus garbage collection manage storage. The portal and REST API expose the same administrative surface to humans and platform code.
Release installers are easier than building the 3,258-file checkout
Harbor v2.15.2 is distributed through online and offline installer archives for Docker Compose, with Kubernetes deployments handled by the separate Helm chart. The online package downloads service images, while the offline package carries them for disconnected hosts. This distinction matters because the README warns that main may be unstable and tells operators to use releases. Building a Git checkout is a contributor path, not the shortest route to a supported registry.
The runtime still needs deliberate configuration. harbor.yml requires a reachable hostname, and production deployments need HTTPS certificates because Harbor ships without them. Administrators must replace the initial admin and database passwords, choose local or external storage, and preserve the installer directory for later reconfiguration. Trivy is opt-in on the Compose installer. Private networks may also need proxy allowances for its vulnerability database downloads.
What happened when we ran it
Our fresh Debian sandbox installed 697 Go packages in 88 seconds for commit 3a88243, using golang:1.24-bookworm with 3 CPUs and 8 GB of RAM. The project lives under ./src/, and its build succeeded in 8 seconds. That proves the checked-out source could resolve its Go dependencies and compile in the stated unprivileged container without secrets. It does not prove that the release installer or a running registry works.
The test command failed with exit code 1 after 511 seconds. Go test recorded 252 passes and 136 failures out of 388. The supplied tail showed successful middleware packages beside failures in server/middleware/security, server/middleware/subject, and server/middleware/v2auth, followed by the overall FAIL. Those lines do not identify a missing service, assertion, or environmental cause, so assigning one would be guesswork.
Our checkout scan counted 3,258 files, about 323,721 lines of source, and 19.4 MB before installed dependencies. It found 11 CI workflow files and a tests directory, but no Dockerfile.
OIDC and scanning add policy with sharp configuration edges
OIDC has one especially important sequencing rule. Harbor allows a switch from local database authentication to OIDC only when no local user other than admin exists. Docker and Helm CLIs cannot follow the browser redirect, so each OIDC user receives a CLI secret. Generating a new secret invalidates the old one. Teams should settle identity architecture before onboarding users and treat CLI secrets as registry credentials, not as disposable portal preferences.
The v2.15.2 database upgrade needs a maintenance plan
Release v2.15.2 automatically upgrades the bundled PostgreSQL database from 15 to 18 when its container starts. The release notes call for a backup and warn that startup can take longer according to database size. They also describe reindexing for deployments with non-ASCII data if collation changes leave indexes stale. An image registry is often on the critical path for deployments, so this upgrade deserves a tested rollback and an announced window.
High availability shifts more work to the operator. Harbor's Helm guidance expects a highly available ingress, PostgreSQL, Redis-compatible service, and storage shared across replicas. Shared volumes or object storage hold artifacts and job output. Those pieces are normal in a platform stack, though Harbor does not operate their availability for you. A team without database and storage recovery drills will gain registry features while creating a new failure domain.
Two open v2.15.2 reports deserve reproduction before rollout
Open issue 23803 reports that Harbor v2.15.2 garbage collection can mark shared blobs for deletion after one copy of an identical artifact is untagged in another project. The report includes a dry-run reproduction and says surviving images become unpullable after deletion. Issue 23862 separately reports missing page-size limits on two retention history endpoints. Both are reports awaiting resolution, so reproduce the relevant path on copied data instead of treating either report as a universal result.
The project is plainly active. GitHub recorded the last push on 2026-09-06, with current issue and pull request updates on the preceding days. The repository had 29,317 stars and 872 combined open issues and pull requests when fetched, while v2.15.2 was published on 2026-07-02. The large queue needs triage by area and release, but the push and discussion dates rule out calling Harbor dormant.
Distribution and Zot cost less attention when policy is external
A 697-package source install is a clue to Harbor's breadth, even before its runtime services arrive. Distribution is the best alternative when another layer already provides authentication and scanning. Zot is a more focused OCI-native registry for teams that do not need Harbor's full management surface. Project Quay is the closer comparison when identity, access controls, replication, a web interface, and vulnerability analysis still belong inside the registry product.
Harbor earns a trial only after its 388-test result is explained
Our 388-test Go run left 136 failures, so the source checkout does not earn a production recommendation from this sandbox alone. Harbor still fits a staffed platform team that needs one place for artifacts, access rules, scans, replication, and audit history. Use a signed release, reproduce the failing areas, stage the PostgreSQL 18 upgrade, and dry-run garbage collection against a restored copy. A small team needing private push and pull should choose the smaller registry and keep the operational budget.