Kong Laravel Package

Product Decisions This Supports

• Build vs. buy for gateway tooling. This package answers a scoping question: "how much of a Laravel-native Kong Admin API client do we have to write ourselves?" Even if we never install it, reading it produces a credible estimate and a working entity model (services, routes, consumers, plugins, upstreams, targets, certificates).
• Where API-gateway operations live. Informs whether gateway administration becomes a screen in our existing Laravel back office or a separate ops console with its own stack, auth, and deploy pipeline. Keeping it in-app is cheaper to staff; keeping it separate is cheaper to secure.
• Feature and roadmap calls. Concretely gates decisions on: self-service API publishing, per-consumer API keys and credential rotation, plugin toggles (rate limiting, key-auth, CORS), and whether tenants map 1:1 to Kong consumers.
• Multi-tenancy and provisioning model. Whether tenant onboarding provisions gateway config synchronously at request time or via queued jobs with retries and reconciliation. This is a product-visible latency and reliability decision, not just an architecture one.
• Risk acceptance, explicitly. Kong's Admin API is a control plane with no meaningful end-user auth model. Deciding that our application talks to it is a product-level security decision requiring sign-off, not a detail to be absorbed by engineering.
• Vendor/exit planning. The Kong-specific entity model is a commitment cost. Adopting it makes a later move to AWS API Gateway, Traefik, Envoy, or Apigee a rewrite of the control plane, not a config change.
• The actual decision this repo supports is "fork or reimplement," not "composer require." Last release May 2023, 26 stars, zero dependents, no vendor backing, no published security or support policy. v1.5.0 (Laravel 10 support, one community contributor) is a real but narrow signal: it removes the framework-upgrade chore from a fork and proves the code still accepts external patches, but it does not constitute maintenance. Treat this as reference material and a scaffold, not a dependency.

When to Consider This Package

Consider it when:

• You already run Kong (OSS or Enterprise) and your control plane is Laravel/PHP — a PHP-native client avoids introducing a second language runtime just for ops tooling.
• You are on Laravel 10 (or close to it). v1.5.0 added Laravel 10 support, which is the single most useful thing about this release: the fork no longer starts with a framework compatibility port.
• You want a reference implementation to read through: Kong's Admin API as modeled in idiomatic Laravel resources, useful for informing an in-house integration.
• You want a scaffold for an internal admin UI, artisan command suite, or scheduled config jobs, and you are prepared to fork and own the code.
• Your team accepts vendor-and-patch as the maintenance model.

Look elsewhere when:

• You need a maintained dependency with security patches and a supported upgrade path. One community PR for Laravel 10 does not change the underlying picture: no vendor backing, no release cadence, no security process.
• You are on Laravel 11 or newer. v1.5.0 stops at Laravel 10; you inherit the framework-upgrade work anyway, so the "head start" argument weakens considerably.
• Your gateway config is declarative / infra-as-code — use decK, the Kong Terraform provider, or the Kubernetes Ingress Controller instead of an admin-API CRUD client.
• You need Kong Enterprise features: RBAC, workspaces, or audit trails the package doesn't model.
• You cannot guarantee the Admin API stays on a private network. Do not ship an admin client in an app that can reach an internet-exposed admin port.
• You need multi-cluster reconciliation, drift detection, or config sync at volume — a CRUD wrapper is the wrong abstraction.
• You're on a Kong version materially newer than mid-2023 and need endpoints or fields added since. Note that v1.5.0 touched Laravel compatibility only — nothing in the Kong entity model was updated.

How to Pitch It (Stakeholders)

Executives. This is still not a "buy." It is a 26-star, MIT-licensed Laravel wrapper with zero downstream dependents and no vendor backing — free reference code, not a supported product. The v1.5.0 release is worth exactly one sentence: a community contributor added Laravel 10 support, which trims some modernization work from a fork but does not create a support relationship. The honest proposal remains fork-and-own: budget roughly a sprint to vendor, audit, and align against our Kong version — marginally less if we are already on Laravel 10, unchanged if we are not. The value delivered is time-to-first-working-admin-surface. The cost we accept is that we inherit all maintenance, security review, and upgrade work, permanently. It buys speed, not support.

Engineering. The package gives us an idiomatic Laravel client for Kong's Admin API — services, routes, consumers, plugins, upstreams — which keeps control-plane code in PHP and lets ops tooling ship inside the existing application instead of as a separate Go or Python service with its own auth and deploy story. As of v1.5.0 it supports Laravel 10, so a fork starts from a compatible base rather than a port. Everything above Laravel 10 is still ours to do. We fork it, pin the fork, and add integration tests against our Kong version.

One guardrail is non-negotiable: the Kong Admin API is a control plane and must never be reachable from the public internet, and our credentials must be least-privilege and rotatable. No exceptions, no "temporarily exposed for testing."

Recommendation. Proceed with the timeboxed spike — one engineer, one sprint — evaluating the fork strictly for internal admin and ops use, now scoped against the v1.5.0 / Laravel 10 baseline. Do not expose it to customer-facing self-service until auth, audit logging, and idempotent provisioning are validated. If our strategic direction is declarative gateway config, skip the fork entirely and invest in decK or Terraform; the CRUD-client abstraction will fight us. If our stack has moved past Laravel 10, re-run the build-vs-fork math rather than assuming the head start still applies.