Php Helm Laravel Package

Getting Started

renoki-co/php-helm generates Helm charts from PHP instead of hand-maintaining YAML trees. In a Laravel app you get a service provider, a publishable config/helm.php (chart paths, Helm binary/version expectations), and a Helm facade, so the first thing to do is confirm the package installs against your framework version at all.

Check the constraints before anything else. This release is the compatibility line in the sand:

• 1.11.0 drops Illuminate 8.x — you need Laravel 9+ (and the PHP version that implies). If you are still on Laravel 8, pin to 1.10.x and treat this as your upgrade blocker.
• It adds Kubernetes 1.24 and drops 1.21. In practice that means the generated manifests and the bundled/apiVersion assumptions target the 1.22–1.24 window. If any of your clusters are still on 1.21, do not take this release.

Minimal first steps:

1. composer require renoki-co/php-helm and verify composer why-not / composer update --dry-run resolves against your Laravel and PHP constraint.
2. php artisan vendor:publish --provider="RenokiCo\PhpHelm\PhpHelmServiceProvider" and read config/helm.php — chart path, default namespace, Helm binary location, and any version pinning live here.
3. Build one throwaway chart: a class extending the package's chart base, returning a small values array and a couple of templates (Deployment + Service). Render it and diff against a chart you already deploy.

First real use case: replace your most static Helm chart — typically an internal service with a Deployment, Service, and ConfigMap — and keep it in resources/helm (or wherever config points) so it lives and is reviewed alongside the application it deploys.

Implementation Patterns

Chart-per-service, values-per-environment. The package's sweet spot is generating values dynamically from Laravel config/env instead of checking in values-staging.yaml / values-prod.yaml. Resolve image tags, replica counts, resource limits, and hostnames from config, then hand the chart to Helm. That keeps a single source of truth with the app's own configuration.

Render in CI, apply via your existing pipeline. Do not let php artisan shell out to helm upgrade in production. Render (helm template equivalent) in CI, run helm lint and a kubectl --dry-run=server diff against the target cluster, and let Argo CD / Flux / your existing release job apply the artifact. This keeps the package as a generator, not a deployer, which is the role it is good at.

Test the output, not the PHP. Snapshot the rendered YAML and assert on it — golden-file tests catch accidental drift when you bump the package (exactly the kind of drift 1.11.0 can introduce via apiVersion changes). Add a schema/version assertion that every generated manifest's apiVersion is served by your target cluster.

Keep the K8s version explicit. Because 1.11.0 moved the supported window to 1.22–1.24, record the target cluster version in config or in your chart classes and have a test assert it. When 1.25 lands in a future release you will want that knob already in place — policy/v1 PodDisruptionBudget, batch/v1 CronJob, and the removal candidates around PSP and autoscaling/v2beta2 are the usual breakage points.

Multi-chart and subchart composition. Use one chart class per deployable, composed at the top level, rather than one giant chart with conditionals. values overrides then flow naturally per environment.

Gotchas and Tips

• The Laravel 8 drop is the headline. Nothing in the release notes mentions a major-version bump, so a loose ^1.10 constraint will silently jump you across a framework-support boundary. Pin deliberately and let Dependabot/ Renovate open the PR so you see the constraint diff.
• Dropping K8s 1.21 is not cosmetic. If you upgraded the package but your cluster is at 1.21, or vice versa, you can emit a manifest your API server does not serve and only find out at apply time. Validate in CI with kubectl --dry-run=server against each target cluster version you run.
• Config caching will bite you. Anything you resolve at render time from env() breaks under php artisan config:cache in CI containers. Read from config(), and make sure the Helm-related config is populated from real env vars at deploy time or baked into cached config intentionally.
• Rendered YAML is whitespace-sensitive in places (block scalars, multi-line annotations). When a chart renders "correctly" but Helm rejects it, diff the raw output with | cat -A before blaming the package.
• Secrets do not belong in values. Values end up in Helm release metadata and helm get values. Reference existing Secrets (secretKeyRef) or an external secret operator; never interpolate a password into the chart values from config().
• Artisan command exit codes and output are your debugging surface. Capture stdout/stderr in CI rather than parsing rendered files after the fact; Helm's own errors are usually clearer than a PHP exception wrapped around them.
• Extension points: the chart base class (values, template discovery, metadata) and the facade are the stable seams. Prefer subclassing or a small internal wrapper over editing published config or vendor files — this release shows how quickly upstream constraints move.
• Watch the changelog for the next K8s cut. This package tracks Kubernetes API deprecations release by release; being one minor version behind on your clusters is fine, being one behind on the package's supported matrix is where surprises come from.