OPcache is a PHP bytecode cache that stores compiled scripts in memory. By avoiding repeated parsing and compilation on each request, it reduces execution overhead and can change how code is served from shared web servers, so cache invalidation and file update handling matter for application reliability and exposure.
What OPcache Changes in PHP Delivery
OPcache changes the runtime profile of a PHP application by keeping compiled bytecode in memory, which reduces repeated parsing and compilation. That performance gain also makes code freshness, cache coherence, and deployment discipline part of normal application reliability.
How OPcache Behaves Across Requests
With OPcache enabled, a PHP worker can reuse precompiled scripts instead of rebuilding them on every request. The practical effect is lower CPU overhead and faster response times, but it also means the server may continue serving cached code until invalidation or refresh occurs.
This is why OPcache is not just a speed setting. It changes the relationship between file updates and request handling, especially on shared web servers where multiple processes may read the same application files and expect changes to appear predictably.
Why Cache Invalidation Matters
The main operational question with OPcache is not whether it improves performance, but when cached bytecode should be considered stale. If deployment tooling, file replacement, or rollback procedures do not align with cache refresh behaviour, the application can serve an older version of code than the filesystem now contains.
- Delayed invalidation can create confusing inconsistencies between source files and live execution.
- Misaligned deploys can expose partial releases, rollback drift, or intermittent failures.
- Shared hosting or multi-tenant environments can make file update handling more sensitive because several requests may depend on the same cached state.
Security and Exposure Considerations
OPcache itself is a performance feature, but its persistence model can affect exposure when code is changed after a compromise or during emergency remediation. If a malicious change, injected web shell, or unintended modification has been cached, the active runtime may not reflect the latest filesystem state until the cache is flushed or the process is recycled.
That makes cache invalidation, restart behaviour, and file integrity monitoring part of the security picture, especially for applications that depend on rapid code replacement during incident response.
For broader control alignment, teams often map this kind of runtime integrity concern to NIST SP 800-53 Rev 5 Security and Privacy Controls, NIST Cybersecurity Framework 2.0, and CIS Controls where configuration management and integrity monitoring are in scope.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | OPcache affects code update handling and runtime configuration state. |
| SI-7 — Software, Firmware, and Information Integrity | Cached bytecode can keep serving stale or altered code after updates or compromise. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | OPcache-related inconsistencies are detected by reviewing runtime and deployment evidence. | |
| Recommendation — Control PHP code and cache-setting changes through approved change management. Verify application and cache integrity after deployment or incident response. Correlate deploy logs, cache events, and application behaviour for drift. | ||
| NIST CSF 2.0 | PR.DS-1 — Data-at-rest is protected | OPcache stores compiled scripts in memory, creating runtime-resident code state to protect. |
| Recommendation — Protect cached application code from unauthorized modification or exposure. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | OPcache requires disciplined configuration and lifecycle handling to avoid stale or inconsistent execution. |
| Recommendation — Standardize OPcache settings and deployment refresh steps across servers. | ||
Practitioner Guidance
Why practitioners should care: Treat OPcache as part of the deployment and recovery path, not only as a performance optimisation. The cache can make a clean code change look incomplete if invalidation, service restarts, or file replacement are not coordinated.
What to watch for: Investigate cases where a file has changed on disk but the application still behaves as if the previous version is running. That mismatch is often the first sign that OPcache refresh timing, deployment ordering, or worker reuse needs attention.
Practitioner takeaway: The safer way to use OPcache is to make cache refresh behaviour explicit in release and incident-response procedures, so performance gains do not outlive code integrity.