Why your PHP version 'didn't change' (and how CLI and FPM lie to each other)

Note

**TL;DR — `php -v` shows the CLI version. Your website doesn't use CLI.** The web stack uses PHP-FPM, which is a separate binary with its own config and its own version. Run `php -v` and `php-fpm -v`. If they disagree, your site is loading the FPM version, not the CLI one. Pointing your shell at the new PHP binary doesn't change what FPM is running. Use `update-alternatives` (Ubuntu/Debian) or restart the right FPM service.

This one comes up so often I have a canned answer for it. Someone upgrades PHP on their server, runs `php -v`, sees the new version, and then refreshes their site to find it still loading on the old version. Often they also see the old version in `phpinfo()` or in WordPress's Site Health screen. They're convinced something is broken, or there's a cache somewhere, or the upgrade didn't take. Usually none of those are true.

PHP CLI and PHP-FPM are two completely separate binaries. They share a name and a project, but on a typical Ubuntu or Debian server they're installed by different packages, run as different processes, read different config files, and can be different versions at the same time without anyone complaining about it. "Upgrading PHP" almost always means "upgrading the CLI binary," which has zero effect on what your web server is actually using.

Confirming you have two different versions

Run both:

bash

php -v
php-fpm -v

On a server where this is the issue, you'll see something like:

text

$ php -v
PHP 8.3.7 (cli) (built: May 13 2024 16:11:22) (NTS)

$ php-fpm -v
PHP 7.4.33 (fpm-fcgi) (built: Jan 31 2023 12:34:56)

There it is. The CLI is on 8.3, FPM is still on 7.4, and your website is using 7.4 because Nginx is talking to whichever FPM service you have configured (probably `php7.4-fpm.service`). The fact that your shell prompt shows 8.3 is irrelevant to what the web stack is doing.

Why this happens by design

This is the part that catches people. It's not a bug. On Debian-derived systems, you can have multiple PHP versions installed side by side intentionally — `php7.4-fpm`, `php8.1-fpm`, `php8.2-fpm`, `php8.3-fpm` can all be running at the same time on different sockets. Different vhosts in Nginx point at different sockets. One server can host one site on PHP 7.4 and another on PHP 8.3 simultaneously, which is exactly what shared hosts do.

The CLI binary, on the other hand, is set by `update-alternatives` and only one version can be active in your shell at a time. Running `apt install php8.3-cli` doesn't touch any of the FPM services. It just installs the new CLI binary and (if you ask it to) makes it the default for `php` on the command line. Your shell sees the new version. Nginx and PHP-FPM continue serving the old one because nothing told them to do anything different.

Finding what your site actually uses

The easiest way to know what version a particular site is loading is to check what FPM socket Nginx is pointing at. Find the vhost config:

bash

grep -rn fastcgi_pass /etc/nginx/sites-enabled/

You'll see something like:

text

/etc/nginx/sites-enabled/example.com.conf:42:    fastcgi_pass unix:/run/php/php7.4-fpm.sock;

Now you know: this site is using `php7.4-fpm.sock`, which is served by `php7.4-fpm.service`. To upgrade *this site* to PHP 8.3, you need to either change the `fastcgi_pass` line to point at `php8.3-fpm.sock` (assuming `php8.3-fpm` is installed and running) or upgrade the 7.4 FPM service to 8.3. The latter is harder than it sounds because of API breakage between PHP versions.

The clean way to upgrade

Don't try to replace one version in place. Install the new version side-by-side and switch traffic over once you've confirmed nothing breaks. On Ubuntu with the Ondrej PHP repository:

bash

sudo apt install php8.3-fpm php8.3-mysql php8.3-curl php8.3-gd \
  php8.3-mbstring php8.3-xml php8.3-zip php8.3-intl
sudo systemctl enable --now php8.3-fpm

Now you have `php8.3-fpm.service` running on its own socket (`/run/php/php8.3-fpm.sock`) alongside the existing 7.4. Update the Nginx vhost to point at the new socket and reload Nginx:

bash

sudo sed -i 's|php7.4-fpm.sock|php8.3-fpm.sock|' /etc/nginx/sites-enabled/example.com.conf
sudo nginx -t && sudo systemctl reload nginx

Reload, not restart. The reload re-reads the vhost config without dropping in-flight requests. If something breaks, change the `fastcgi_pass` back and reload again — that's the rollback. After a few days of confirming everything works, you can `apt purge php7.4-fpm` and reclaim the disk space.

Don't forget WP-CLI

WP-CLI runs through the CLI binary, not FPM. So if your site is on PHP 8.3 (FPM) but your CLI is still on PHP 7.4, every WP-CLI command you run is executing against PHP 7.4. Most of the time this doesn't matter. Occasionally it does — some plugins do version-specific behavior on activation, some database migrations care which PHP version they ran under, and some debugging scenarios require CLI and FPM to match exactly.

To make CLI use the new version on Ubuntu/Debian:

bash

sudo update-alternatives --set php /usr/bin/php8.3

Now `php -v` matches `php-fpm -v` and life is consistent again.

Tip

If you're using a managed host (cPanel, Plesk, hosting panels in general), this whole thing usually has a UI for it. Look for "PHP version selector" or "MultiPHP Manager." The control panel handles the FPM service installation and the vhost rewrite for you. The trap is that those tools change the FPM version but leave the CLI alone, so you can still get into the "php -v shows the new version, site loads the old version" state if you've also messed with the CLI separately.

What this really comes down to

The mental model that fixes this for good is: there's no such thing as "the PHP version on this server." There are PHP CLI versions, PHP-FPM versions, PHP-Apache module versions, and possibly PHP-CGI versions, and they're all independent. The version your website runs is the one configured in the vhost that handles requests for that website. Anything else is a different program that happens to share a name.