php-runtime-eol-opcache-fpm-review

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, OPcache production configuration, and PHP-FPM pool tuning.

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 — the php.net support-policy definitions and the current per-branch active-support/security-support/EOL dates.
• OPcache production configuration — opcache.enable, opcache.validate_timestamps, and sizing directives, and how to review them against a deployment model.
• PHP-FPM pool tuning — 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.