Php Runtime Eol Opcache Fpm Review

---
name: php-runtime-eol-opcache-fpm-review
description: Use this skill to review PHP runtime upgrade readiness — whether the target or running PHP version is past php.net's published four-year support window (active support, then security-only, then EOL) — and to review production OPcache (enable, validate_timestamps, memory sizing) and PHP-FPM (pm, max_children, max_requests) hardening. Use when production PHP could be running an EOL or soon-security-only-EOL version, or when OPcache/FPM configuration could serve stale code or let a traffic spike exhaust workers. An EOL runtime is always a blocking finding. Static review only; it never installs, upgrades, or restarts a PHP runtime.
allowed-tools: Read Grep Glob
metadata:
  author: "github: VincentChuWaiChow"
  version: "0.1.0"
  updated: "2026-07-16"
  category: operational
  lifecycle: experimental
---

# PHP Runtime EOL, OPcache & PHP-FPM Review

## Purpose

Review a PHP service's runtime lifecycle status and production hardening so a service does not run on an unsupported PHP version or an unhardened OPcache/PHP-FPM configuration without the team knowing. The dominant failure modes are a PHP version past php.net's published support window (EOL, or security-only and approaching its own EOL), OPcache left disabled or misconfigured for the deployment model, and PHP-FPM pool settings that leave worker concurrency and recycling unbounded.

## When to use

Use this skill when the user asks to:

- review whether a service's target or running PHP version is EOL, security-only, or actively supported per php.net,
- assess an upgrade path and timeline against php.net's published support-window dates,
- review production `opcache.enable`, `opcache.validate_timestamps`, `opcache.memory_consumption`, and `opcache.max_accelerated_files` configuration,
- review production PHP-FPM `pm`, `pm.max_children`, and `pm.max_requests` configuration for resource-exhaustion and worker-leak exposure.

## When not to use

Do not use this skill for:

- performing the PHP version upgrade, editing application code for compatibility, or installing/restarting any PHP, OPcache, or PHP-FPM process — this skill is static review only; it recommends the path and hands implementation to the owning team.
- reviewing application-level vulnerabilities, Composer dependency supply chain, or WordPress-specific hardening — those belong to other PHP-domain skills in this catalog.
- asserting a PHP version's support status from memory or estimation; if php.net's supported-versions page does not list the version, say so rather than guessing a date.
- judging lifecycle status against the wall clock; judgment is based on the target/committed version and the published dates only, so findings stay reproducible.

## Preconditions

- The PHP version actually targeted or running in production (`composer.json` `require.php`, Dockerfile/base-image tag, CI runtime matrix, or deployment manifest).
- The production `php.ini` OPcache directives in scope: `opcache.enable`, `opcache.validate_timestamps`, `opcache.revalidate_freq`, `opcache.memory_consumption`, `opcache.max_accelerated_files`.
- The production PHP-FPM pool configuration: `pm`, `pm.max_children`, `pm.max_requests`, and the `pm.start_servers`/`pm.min_spare_servers`/`pm.max_spare_servers` triad if `pm` is `dynamic`.
- The deployment model (immutable container image replaced per deploy vs. in-place file sync), since it determines whether `opcache.validate_timestamps=0` is safe without a compensating invalidation step.
- Approximate available memory per worker host/container, if `pm.max_children` sizing guidance is requested.

## Lean operating rules

- Resolve the exact PHP version from the strongest available evidence and state that evidence tier before classifying its lifecycle status.
- Classify status precisely as active support, security-only (with the published end date), or EOL — never collapse these into "outdated."
- Treat any EOL classification as blocking, regardless of code quality elsewhere; EOL means no fixes are published, including for actively exploited vulnerabilities.
- Treat a security-only classification as blocking only when its published security-support end date falls within the stated release horizon with no tracked upgrade plan; otherwise report it as dated advisory guidance.
- Confirm `opcache.enable=1` in production, and check `opcache.validate_timestamps` against the actual deployment model rather than assuming one universally correct value.
- Confirm `pm.max_children` is evidently bounded by available memory and `pm.max_requests` is nonzero (or has a documented rationale for `0`).
- Never fabricate a PHP version, support date, or CVE; encode lifecycle dates only from php.net's supported-versions page.
- Label every claim `repo evidence`, `documentation-based`, or `inference`.

## Context7 documentation protocol

This skill's allowed tools are Read, Grep, and Glob only — it does not call Context7 or any live documentation lookup at review time. Every PHP-lifecycle, OPcache, or PHP-FPM behavioral claim must instead be grounded in the bundled reference files, which are sourced directly from php.net and dated at authoring time. If a claim cannot be traced to a bundled reference or to evidence in the repository, label it an assumption rather than asserting it as documented behavior. See [PHP version lifecycle](references/php-version-lifecycle.md), [OPcache production configuration](references/opcache-production-config.md), and [PHP-FPM pool tuning](references/php-fpm-pool-tuning.md).

## Workflow

Follow the review in this order: (1) resolve the exact PHP version targeted or running, and its evidence tier; (2) classify that version against php.net's current supported-versions table as active-support, security-only, or EOL, citing the exact dates; (3) if security-only, compare its security-support end date against the stated release horizon; (4) read production OPcache directives and check `enable`/`validate_timestamps` against the deployment model, and `memory_consumption`/`max_accelerated_files` against the actual codebase size; (5) read production PHP-FPM pool configuration and check `pm.max_children` sizing and `pm.max_requests` recycling; (6) emit findings with evidence tiers, concrete remediation, and ownership handoffs.

## Decision gates

- Block on any EOL PHP version, unconditionally.
- Block on a security-only version whose published security-support end date falls within the stated release horizon with no tracked upgrade plan.
- Block on production OPcache disabled, or `validate_timestamps` inconsistent with the deployment model with no compensating invalidation step.
- Block on PHP-FPM with no evidently bounded `pm.max_children` or an unbounded `pm.max_requests` with no documented rationale.
- Every lifecycle and directive claim traces to a bundled reference file or explicit repository evidence, never memory.
- The PHP version upgrade and any application-code compatibility work are handed to the owning engineering team, never performed here.

## Evidence classification

Label each finding `repo evidence` (seen directly in `php.ini`, FPM pool config, Dockerfile, CI, or a version banner), `documentation-based` (a php.net-published support date or directive default from the bundled references), or `inference` (a reasonable conclusion not directly observed, e.g. estimated memory footprint per worker). A documented default never proves what a specific deployment's actual configuration is — check the file before asserting it.

## Security and privacy constraints

Static review only. Never install, upgrade, downgrade, or restart any PHP, OPcache, or PHP-FPM process, and never make any network call to php.net or any other service. Never fabricate a PHP version, support date, or CVE — report missing evidence instead of guessing. Treat any credential found in configuration files as a redact-and-flag finding, never echoed in output.

## Escalation conditions

Escalate to incident response on any evidence the failure is already live — an EOL PHP version confirmed serving production traffic, or a PHP-FPM pool observed exhausting workers under load. Escalate a confirmed EOL or approaching-security-only-EOL finding to the owning engineering team as a tracked upgrade item, with the recommended target version and the exact php.net-published dates driving the timeline.

## References

Load these only when needed:

- [PHP version lifecycle](references/php-version-lifecycle.md) — the php.net support-policy definitions and the current per-branch active-support/security-support/EOL dates.
- [OPcache production configuration](references/opcache-production-config.md) — `opcache.enable`, `opcache.validate_timestamps`, and sizing directives, and how to review them against a deployment model.
- [PHP-FPM pool tuning](references/php-fpm-pool-tuning.md) — `pm`, `pm.max_children`, and `pm.max_requests` review criteria for resource-exhaustion and worker-leak exposure.

## Response minimum

Return, at minimum:

- the resolved PHP version, its evidence tier, and its lifecycle classification (active support / security-only with end date / EOL) with the exact php.net-published dates;
- the production OPcache hardening state (`enable`, `validate_timestamps` versus deployment model, sizing);
- the production PHP-FPM hardening state (`pm.max_children` sizing, `pm.max_requests` recycling);
- concrete remediation and an exact verification step for each finding;
- ownership handoffs and any incident-response escalation.

## Anti-goals

- Never fabricate or guess a PHP version's support-window dates; encode them only from php.net's supported-versions page.
- Never judge lifecycle status against the wall clock; use the target/committed version and the published dates only.
- Do not rewrite application code or perform the PHP version upgrade; recommend the path and hand implementation to the owning team.
- Do not execute, restart, or reload any PHP, OPcache, or PHP-FPM process, and do not contact php.net or any other service.
- Do not treat a version absent from the current supported-versions table as EOL by assumption; say the evidence is missing instead.