Product Decisions This Supports
- Build vs. buy on registry automation. A thin PHP client for Harbor (the CNCF container/OCI artifact registry) removes the need to hand-roll Guzzle calls, auth (basic auth / robot accounts), and pagination. The decision this most directly informs: do we adopt this wrapper or write ~300 lines of bespoke client code we control?
- Feature work on supply-chain and artifact governance. Concrete capabilities this unlocks: listing and promoting artifacts across projects, wiring vulnerability scan results into CI/CD gates, automating retention policies and tag immutability, provisioning projects and robot accounts for teams, and triggering replication between registries.
- Roadmap: internal developer platform / self-service. If we expose image catalogs, promotion workflows, or per-team registry quotas to developers, a PHP-native client lets that live in the existing Laravel app rather than introducing a separate Go/Python service just to talk to Harbor.
- Roadmap: audit and compliance reporting. Project membership, robot-account inventory, and scan-status rollups can be pulled into existing admin tooling without a new runtime.
- Deprioritization signal. Adopting this raises the cost of any future registry migration — it deepens coupling to Harbor's API surface inside our PHP codebase. Treat it as a bet on Harbor staying our registry.
When to Consider This Package
Consider it when:
- Harbor is (or is about to become) the registry of record, and the automation you need lives in a PHP/Laravel codebase.
- Your needs are modest and well-scoped — project/artifact queries, scan-result retrieval, robot-account lifecycle — rather than a full reimplementation of Harbor's admin API.
- You want a dependency-light client rather than pulling in a large SDK or standing up a sidecar service.
Proceed with caution:
- Naming is a yellow flag. "…Bundle" is Symfony bundle convention, not Laravel. Before committing, verify it actually ships a Laravel service provider, facade, and publishable config; if not, budget adapter work and don't let anyone call it "drop-in."
- v1.0.0 with no substantive changelog. The release notes are a commit link and nothing else — no supported Harbor API version, no Laravel/Symfony support matrix, no documented endpoint coverage, no security posture. A 1.0.0 tag without a changelog is a version number, not a stability guarantee.
- Single-maintainer risk. Bus-factor of one on a dependency that touches infrastructure credentials deserves an explicit note in the risk register.
- Pin and wrap. Isolate it behind a narrow internal interface so a swap is a day's work, not a quarter's.
Look elsewhere when:
- You need broad or guaranteed API coverage, vendor-backed support, or an SLA — use Harbor's own REST API directly or the official Go client and expose it as a service.
- Your registry is a managed offering (ECR/GAR/ACR) where first-party SDKs are the safer path.
- You're on a non-PHP stack for this workload; the language affinity is the main reason to pick this up.
How to Pitch It (Stakeholders)
For executives: This is a small, low-cost PHP wrapper around Harbor, our container registry. It shortens the path to automated image governance — scan gating, retention, replication, team provisioning — inside the platform we already run, instead of standing up a new service. The trade-off is dependency risk: it's a v1.0.0 from a single maintainer with a changelog that tells us nothing. My recommendation is a one-week, time-boxed spike to validate fit, not a committed dependency decision.
For engineering: Assume the integration is straightforward but unproven. Validate three things before we build on it: (1) it works against our Harbor version and auth mode; (2) it plays correctly with Laravel's container and config publishing despite the Symfony-style packaging; (3) endpoint coverage matches what we actually need — no more, no less. Wrap it behind our own interface so a replacement is cheap. Flag: no visible CI, test, or security disclosure information at this release — check the repo before it touches credential-bearing code paths.
Ask: one engineer-week for the spike; a go/no-go decision gated on documented coverage, a real CHANGELOG, and a supported-version statement from the maintainer. If those don't materialize, we implement against Harbor's REST API directly and keep control.