How to enable PHP OPcache on Ubuntu or Debian

Enabling OPcache lets the PHP runtime keep compiled bytecode in shared memory instead of parsing and compiling the same scripts on every request. That reduces repeated CPU work and helps steady response time for applications that execute the same code paths throughout the day.

On Ubuntu and Debian, packaged PHP builds expose OPcache through the version-matched phpX.Y-opcache module definition under /etc/php/<version>/mods-available and load it per SAPI through runtime-specific /conf.d links. The decisive enable check is therefore the SAPI that serves the application, such as apache2 or fpm, not the CLI interpreter alone.

Current distro runtime packages commonly pull in the matching OPcache package automatically, so the practical job is often confirming package presence or re-enabling a SAPI that was disabled locally. The CLI runtime also keeps opcache.enable_cli off by default on current PHP builds, so a CLI status command can still look inactive even while the web-facing runtime is ready to cache requests.

Steps to enable PHP OPcache on Ubuntu or Debian:

List the installed PHP version and available SAPIs before changing the module state.
```
$ phpquery -V
8.3

$ phpquery -S -v 8.3
apache2
cli
```
Replace 8.3 with the version reported by phpquery -V throughout the remaining steps. If the site runs through PHP-FPM, the same query shows fpm when that runtime is installed. If only cli appears, install the web-facing SAPI first because enabling OPcache for CLI alone does not speed up web requests.

Related: How to check PHP version
Check whether the target SAPI already has OPcache enabled before changing packages or links.
```
$ phpquery -v 8.3 -s apache2 -m opcache
opcache (Enabled for apache2 by maintainer script)
```
Replace apache2 with fpm when the site runs through PHP-FPM. If the output says No module matches opcache (Disabled for apache2 by local administrator) or the module is missing, continue with the next steps.

Related: How to show loaded PHP extensions
Install or confirm the matching OPcache package for the active PHP version.
```
$ sudo apt-get install --yes php8.3-opcache
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
php8.3-opcache is already the newest version (8.3.6-0ubuntu0.24.04.5).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
```
Use the explicit versioned package such as php8.2-opcache or php8.4-opcache when the host runs a different branch. On current package-managed hosts, this step often confirms a dependency that was installed automatically with the matching CLI, PHP-FPM, or Apache runtime package.
Enable OPcache for the selected PHP version and SAPI when the previous check reports it as disabled.
```
$ sudo phpenmod -v 8.3 -s apache2 opcache

$ phpquery -v 8.3 -s apache2 -m opcache
opcache (Enabled for apache2 by local administrator)
```
Keep the -v and -s flags explicit on hosts with multiple PHP versions or more than one installed SAPI so one command does not change every runtime at once.

Related: How to enable a PHP extension on Ubuntu or Debian
Reload the web-facing runtime so the active workers read the new module state.
```
$ sudo systemctl reload apache2
```
Use sudo systemctl reload php8.3-fpm instead when PHP-FPM serves the site. The CLI SAPI does not need a reload, and PHP-FPM unit names are usually versioned on Ubuntu and Debian.

Related: How to manage the Apache web server service
Related: How to manage the PHP-FPM service in Linux
Verify that the target SAPI still reports OPcache enabled and that its runtime-specific link points to the shared module definition.
```
$ phpquery -v 8.3 -s apache2 -m opcache
opcache (Enabled for apache2 by local administrator)

$ ls -l /etc/php/8.3/apache2/conf.d/*opcache.ini
lrwxrwxrwx 1 root root 39 Mar 26 02:10 /etc/php/8.3/apache2/conf.d/10-opcache.ini -> /etc/php/8.3/mods-available/opcache.ini
```
For PHP-FPM, replace the path with /etc/php/8.3/fpm/conf.d/*opcache.ini. If the application still behaves as if OPcache is off, verify through a short-lived request handled by the same site or pool because a CLI probe does not prove the web-facing runtime was reloaded.