Laravel Php K8S Laravel Package

Product Decisions This Supports

• In-app Kubernetes orchestration as a product capability. This package wraps the renoki-co/php-k8s client in Laravel service providers, facades, and config, so our application code can create, read, scale, and delete cluster resources (deployments, pods, services, namespaces, config maps) without shelling out to kubectl or hand-rolling HTTP calls against the API server. That unlocks features like self-service environment provisioning, per-tenant namespace creation, in-dashboard deployment status and log surfacing, and one-click scale/restart actions for internal platform users.
• Build vs. buy for internal platform tooling. The realistic alternative is a third-party platform (Rancher, Port, Backstage plugins, a managed internal developer portal) or a bespoke Go/Node control-plane service. For a Laravel-centric team with modest cluster surface area, adopting this package is the cheapest path to a working feature; for org-wide developer portals with RBAC, audit, and CRD-heavy workflows, it is the wrong layer and should not displace a real IDP decision.
• Roadmap sequencing for ops-facing features. Because the package gives us cluster access inside the app, we can sequence: (1) read-only visibility (list deployments, show pod health), (2) safe mutations (scale, restart, rollback), (3) provisioning workflows (namespace + quota + secrets bootstrap). Each stage is a shippable increment on the same dependency rather than a new integration.
• Multi-cluster and multi-tenant architecture choices. The package supports named connections, which directly informs whether we model tenancy as one cluster/namespace-per-tenant or cluster-per-environment. That is a product/architecture decision this dependency makes cheap to prototype and expensive to reverse, so it should be settled before committing.
• Buy-in cost for a new runtime dependency. 3.4.0 is a breaking release on the platform floor (drops PHP 7.3/7.4 and Laravel 7.x, adds Laravel 9.x). That is a concrete input to the platform-upgrade roadmap: adopting this package now implicitly ties our ops features to a Laravel 9+/PHP 8+ baseline.
• Not a deployment pipeline decision. This is a runtime API client, not a CI/CD or GitOps tool. It does not replace Helm, Argo CD, or GitHub Actions, and should not be scoped as if it does.

When to Consider This Package

Adopt when:

• We are on Laravel 9.x or later and PHP 8.0+ (required as of 3.4.0; 3.3.x is the last line supporting Laravel 7.x and PHP 7.3/7.4).
• The product genuinely needs to read or mutate cluster state from application code at request time — status dashboards, self-service provisioning, tenant isolation workflows, admin actions.
• We want the cluster interaction to live in the Laravel app we already operate (same auth, same audit log, same job queue, same config/secrets handling) rather than in a separate control-plane service.
• The team is PHP-first and the alternative is a new Go/Node service that nobody owns.
• Workloads are conventional Kubernetes objects (deployments, services, pods, config maps, secrets, namespaces, jobs, ingresses). The underlying client covers these well; exotic CRDs are where it thins out.
• We want a small, MIT-licensed, single-maintainer dependency whose blast radius is confined behind a facade we can swap.

Look elsewhere when:

• We are pinned to Laravel 7.x or PHP 7.3/7.4 — 3.4.0 will not install, and staying on 3.3.x means carrying an unmaintained branch. This is a blocker, not a tradeoff.
• The need is deploying our own application — that is CI/CD (Helm, Argo CD, GitHub Actions) and belongs outside the app. Using an in-app K8s client for release management is an anti-pattern: the app becomes a dependency of its own deployment.
• The need is a full internal developer portal with SSO, policy enforcement, cost attribution, and cross-team catalog — buy or build on Backstage/Port rather than growing this into one.
• We require guaranteed enterprise support, SLAs, or a security review of the supply chain — this is a small OSS package. We would need to accept the maintenance risk, vendor the code, or choose a commercially supported platform.
• CRD-heavy or controller-pattern work is central; writing a real Kubernetes controller in PHP is the wrong tool, and the operational model (reconcile loops, informers) does not map onto a request/response web app.
• Cluster credentials would need to sit in the web application's runtime in a way our security posture forbids. In that case, isolate cluster access in a separate service and expose an internal API instead.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can add self-service Kubernetes capabilities — environment provisioning, deployment visibility, one-click scale and restart — directly into the Laravel product we already run, using a small open-source package instead of buying a platform or standing up a new service. That means no new vendor contract, no new language or runtime for the team to own, and the fastest credible path to shipping ops-facing features. The cost is a modest platform dependency and an upgrade prerequisite: this release requires Laravel 9 and PHP 8, so it locks those features to our platform-modernization timeline. It is a runtime integration, not a replacement for our deployment pipeline, and it should be scoped as product capability rather than as a reason to defer the platform upgrade.

For engineering (summary):

• Release 3.4.0 adds Laravel 9.x support and is a breaking release: it drops PHP 7.3 and 7.4 and drops Laravel 7.x. Anyone on 3.3.x stays there until the PHP 8 / Laravel 9 upgrade lands — plan that migration before committing ops features to this dependency.
• It is a Laravel-flavored wrapper over renoki-co/php-k8s: service provider, publishable config, facades, named connections. Cluster calls are ordinary PHP from the app's runtime, so they inherit our existing auth, logging, queues, and secret handling.
• Confine usage behind our own interface (a small service class or repository per resource type) so the package is swappable and so tests can fake it. Do not let facades leak into controllers or domain code.
• Treat cluster credentials as production secrets with least-privilege service accounts and namespace-scoped RBAC. The app's blast radius equals the token's permissions — scope accordingly.
• Main risks: single-maintainer OSS dependency, thin coverage for CRDs and controller-style workloads, and the fact that long-running or watch-based operations do not fit a request/response web app. Use queued jobs for anything slow, and keep mutation paths behind explicit user intent plus audit logging.
• Not the right tool for deploying our own app or for GitOps; keep that in Helm/Argo.