Php Helm Laravel Package

Product Decisions This Supports

• Kubernetes deployment strategy: If your product ships to K8s (self-hosted, on-prem, or multi-cloud), this package lets you generate Helm charts programmatically from PHP/Laravel — useful when deciding whether deployment manifests live in PHP code (owned by app engineers) versus a separate Helm repo (owned by platform/DevOps).
• Build vs. buy for deployment tooling: Informs the call between (a) writing/curating raw Helm charts by hand, (b) adopting a PHP-native chart generator like this, or (c) standardizing on a platform team's existing chart library. This is an internal-tooling build-vs-buy decision, not a customer-facing one.
• Support matrix and upgrade planning: Release 1.11.0 adds K8s 1.24 support and drops both K8s 1.21 and Laravel 8.x (Illuminate 8.x). This directly maps to a roadmap item: when you upgrade the platform's Kubernetes baseline and Laravel baseline, you must be on this release (or later). It sets a floor for the minimum supported K8s and Laravel versions your deployment artifacts target.
• Onboarding / developer experience: Enables "deployment as PHP code" — engineers familiar with Laravel can author charts without deep Helm/Gotemplate fluency. Supports a DX roadmap bet on reducing the barrier to shipping K8s workloads.
• Feature flag / multi-environment releases: Programmatic chart generation supports templating per-environment configurations (dev/staging/prod), relevant if the roadmap includes environment parity or configurable enterprise deployments.

When to Consider This Package

Adopt when all of the following hold:

• The product is a Laravel/PHP application (or PHP service) that is already deployed to Kubernetes or is scheduled to be.
• You want to generate Helm charts from PHP — e.g., your team is PHP-first and you'd rather not maintain a parallel Go/Gotemplate chart repository.
• You need programmatic, repeatable chart generation (versioned, testable, colocated with the app) rather than hand-edited YAML.
• Your baseline is Kubernetes 1.22+ and Laravel 9+ — 1.11.0 dropped K8s 1.21 and Illuminate 8.x, so anyone on those must stay on an older release or upgrade first.

Look elsewhere when:

• K8s 1.21 or Laravel 8.x support is a hard requirement — 1.11.0 is a breaking platform bump. Pin to the prior minor line, or plan the upgrade and treat this release as the forcing function.
• The team is not on Kubernetes (e.g., PaaS, serverless, or plain VM deployments) — Helm is irrelevant.
• Your platform/DevOps team already owns a canonical chart library; generating charts in PHP creates a second source of truth and drift risk.
• The deployment surface is trivial (single container, no env-specific tuning) — raw manifests or a managed platform may be simpler than a chart-generation layer.
• You need advanced Helm ecosystem features (dependency management, chart repos, OCI distribution) that are more mature in native Helm tooling.

Migration note for PMs: Because this release is a breaking platform-support change (dropped K8s 1.21 and Laravel 8), sequence it against your infrastructure upgrade roadmap. If you're still on K8s 1.21 or Laravel 8, upgrading this package is blocked until you upgrade the platform — treat the two as a coupled workstream, not independent tickets.

How to Pitch It (Stakeholders)

For executives: This is an internal developer-tooling package that lets our Laravel engineers define Kubernetes deployment charts directly in PHP. The business value is faster, lower-friction shipping to Kubernetes and reduced dependence on specialized Helm/DevOps skills for routine releases — it makes deployment configuration a first-class, versioned part of the application codebase. It carries no customer-facing risk; the main consideration is an operational one: the newest release (1.11.0) requires us to be on Kubernetes 1.22+ and Laravel 9+, so adoption should be sequenced with our platform-upgrade plan.

For engineering: Version 1.11.0 adds support for Kubernetes 1.24 and drops K8s 1.21 and Laravel 8.x. It's a routine forward-compatibility release, but the drops are breaking for anyone still on the older baselines — upgrade the platform first, then bump this dependency. It's worth adopting if we want deployment charts generated and versioned alongside the app rather than maintained in a separate Helm repo; otherwise, we should confirm with platform/DevOps that we're not creating a duplicate source of truth for chart definitions.