Opcache Reset Bundle Laravel Package

Product Decisions This Supports

• Deploy pipeline design. The real decision this package sits inside is: does our release process need an explicit OPcache invalidation step, or do we rely on opcache.validate_timestamps=1? If we run production with timestamp validation off (the common performance tuning), every deploy needs a reset — this package is one (weak) candidate for that step.
• Infrastructure posture: validate_timestamps on vs. off. Choosing this package is effectively choosing the "off + explicit reset" model. That trade buys a few percent of request throughput at the cost of a deploy-time failure mode ("stale code after release") that must be owned by someone.
• Build vs. buy vs. one-liner. The capability is trivially small — a CLI entry point that calls opcache_reset(). The genuine product decision is whether cache invalidation is a first-class deploy stage (owned, logged, alerted on) or an ad-hoc shell command in a runbook. Only the former is worth engineering time.
• Zero-downtime / atomic release roadmap. With symlink-swap deploys, the reset must target the right PHP-FPM pool and the right release path. Any tooling choice here constrains how we do blue/green or rolling restarts later.
• Not a Laravel decision. Despite the "Laravel/PHP" framing, this is a Symfony bundle (a Bundle class, Symfony console wiring). It is not a Laravel package and gives Laravel teams no artisan command, no service provider, no config publishing. For a Laravel app, the equivalent is a 5–10 line artisan command or a deploy hook — there is nothing here to adopt.

When to Consider This Package

Consider it only if all of the following hold:

• The application is Symfony, not Laravel, and already standardizes on third-party bundles for ops tooling.
• Production runs with opcache.validate_timestamps=0 (or an immutable-release filesystem) and therefore genuinely needs an explicit reset on every deploy.
• The deploy environment is constrained: shared hosting or a managed host where you cannot install cachetool, cannot expose an authenticated HTTP reset endpoint, and cannot restart PHP-FPM. In that narrow case, a CLI wrapper is the only lever available.
• You are willing to vendor and own the code — fork it, pin it, review it. With 0 stars, 0 dependents and no visible release cadence, treat it as sample code, not a dependency.

Look elsewhere — or simply don't — when:

• You're on Laravel. Wrong ecosystem; the bundle won't register.
• validate_timestamps=1. Modern PHP with a sane opcache.revalidate_freq makes this tool unnecessary; resets add risk (a thundering herd of recompiles) for no gain.
• You have shell access on the app server. cachetool opcache:reset --fcgi=/run/php-fpm.sock is the mature, maintained, multi-SAPI-correct answer, and it resets the FPM pool — a CLI process calling opcache_reset() only clears its own CLI OPcache, which usually isn't the cache that's stale. This is the single biggest technical caveat and the reason to be skeptical of the whole approach.
• You use Deployer, Envoy, Ansible, Kamal, or a platform with release hooks. The reset belongs as one task in the existing pipeline, not as a new dependency.
• You need supply-chain assurance. An unmaintained package with no adoption is an audit finding, not a solution.

How to Pitch It (Stakeholders)

To executives: There's a real operational need hiding here — when we tune PHP for speed, deployed code can serve stale from cache, and someone has to invalidate it on every release. But this specific package is not the answer: zero adoption, no maintainers, and it's built for Symfony rather than our stack. I recommend we not adopt it. Instead we fold "cache invalidation" into the deploy pipeline we already own. Cost: roughly half a day of engineering. Risk avoided: an unmaintained third-party dependency in the release path, plus a class of "why is production running old code?" incidents that are expensive to diagnose.

To engineering: The capability is ~10 lines. The subtlety is SAPI scope: opcache_reset() executed from CLI does not clear the FPM worker pool, so a naive CLI command gives false confidence. We should either (a) hit an authenticated internal endpoint that runs in the FPM context, or (b) use cachetool against the FPM socket, wired as a post-deploy task with a health check that verifies the running release SHA. Decide validate_timestamps deliberately, document it, and make the reset step observable — log it and alert if it fails.

Recommendation: Reject as a dependency; keep the pattern (explicit, verified cache invalidation as a deploy stage) and implement it natively. Revisit only if we move to Symfony and are locked out of FPM restarts.