Kiln Laravel Package

Product Decisions This Supports

• Deployment architecture and release process: Kiln's core value is making OPcache a first-class part of your deploy story. kiln:status and kiln:config give you the data to decide whether to warm caches on deploy, whether validate_timestamps should be off in production, and whether your FPM pool is actually benefiting from OPcache at all.
• Build vs. buy for deploy tooling: This is a narrow, well-scoped package that replaces a handful of hand-rolled shell scripts or ad-hoc opcache_reset() endpoints that teams typically accumulate. Adopting it is a low-cost way to standardize that logic rather than letting each service invent its own.
• Feature roadmap for internal platforms: If you run a platform or shared hosting layer, the signed HTTP route is the interesting primitive — it makes "invalidate a worker pool's shared memory" a supported, authenticated operation rather than a cron hack. That's a building block for zero-downtime deploy tooling, per-tenant cache invalidation, or a deploy webhook.
• Incident response and operational runbooks: kiln:status (hit rate, memory, cached script count) is exactly the telemetry you want in a post-deploy smoke check or a "why is this app slow" runbook. It supports decisions about whether a latency regression is an OPcache problem or something else.
• Risk/compliance review of production configuration: kiln:config flagging risky combinations (e.g. validate_timestamps on in prod) turns an invisible ini setting into a reviewable artifact — useful for pre-launch checklists and security/config audits.
• Use cases: post-deploy cache warming (compile without executing, so no side effects from bootstrapping the app), scheduled OPcache resets, and giving ops a safe remote lever into FPM's shared memory without shell access to the box.

When to Consider This Package

Adopt when:

• You run PHP under FPM in production and have ever been bitten by stale code after a deploy, or by a cold OPcache causing a latency spike on the first requests after release.
• Your deploy pipeline has a natural post-release hook (Envoyer, Deployer, GitHub Actions, a Kubernetes init/preStop hook) where kiln:warm or the HTTP route fits cleanly.
• You want visibility into OPcache without standing up APM — status and config are cheap wins for small teams.
• You need to invalidate OPcache from outside the box (CI, a deploy orchestrator, a control plane) and the CLI SAPI limitation is the obstacle — the signed FPM route is the reason to pick this over a one-line opcache_reset() script.
• You value no Guzzle / no extra HTTP client dependency — the route is self-served, which keeps the dependency surface small.

Look elsewhere or skip when:

• You're on non-FPM SAPIs (CLI-only workers, RoadRunner/Swoole, FrankenPHP) — the shared-memory-across-CLI insight that motivates the route doesn't apply the same way, and opcache_reset() semantics differ.
• You already have APM/observability (Datadog, New Relic, Tideways) covering OPcache metrics — kiln:status becomes redundant.
• Your platform forbids arbitrary HTTP routes into production, or you can't safely manage the signing secret — in that case use the artisan commands only.
• You're on shared hosting with no deploy hooks and no ability to run artisan post-deploy; the tooling has nowhere to live.
• You expect this to do more than OPcache — it is deliberately single-purpose. Don't mistake it for a general cache/queue/deploy orchestrator.

How to Pitch It (Stakeholders)

For executives: This is a small, dependency-free package that removes a well-known class of production incidents — stale code and cold caches after a deploy — and replaces the bespoke shell scripts teams write to work around them. Cost is near zero, and it gives us a supported, authenticated way to tell our web workers to refresh their compiled code, plus a quick readout of whether the PHP opcode cache is actually doing its job. It's operational hygiene, not a new platform.

For engineering: OPcache lives in each FPM worker pool's shared memory, so php artisan from the CLI can't touch it — Kiln solves that with a signed, disabled-by-default HTTP route that executes inside a real worker. Around that it gives us warm (compile without executing, so warming doesn't trigger side effects), clear, status, and a config linter that flags risky settings like validate_timestamps=On in prod. No Guzzle, no new client dependency, and the route is opt-in. It slots into a post-deploy hook or a scheduled job and replaces the one-off opcache_reset() scripts we keep rewriting. Caveats worth naming up front: it's a v1.0.0 with no prior track record, the signed-route threat model needs a review before we enable it in production, and it's FPM-centric — teams on Swoole/RoadRunner get much less out of it. Recommended next step: pilot on one service, wire kiln:config and kiln:status into the deploy checklist, and evaluate the route behind our existing auth perimeter.