PHP 8.2 End of Life (December 31, 2026): How to Upgrade to PHP 8.4 or 8.5

PHP 8.2 gets its last security fix on December 31, 2026. After that date, the PHP project stops patching it, and every new vulnerability found in PHP 8.2 stays open on your server. PHP 8.2 is still one of the most common versions on LAMP and LEMP servers, because it was the safe choice for WordPress, Laravel and Magento sites set up in 2023 and 2024.

This guide explains what end of life means in practice, whether to move to PHP 8.4 or PHP 8.5, what breaks on the way, and how to upgrade a live Ubuntu server without downtime, with Apache or Nginx.

When does PHP 8.2 reach end of life?

Each PHP version gets two years of active support (bug and security fixes), then two years of security fixes only. The dates, from php.net:

PHP 8.6 is scheduled for November 19, 2026, with additions such as a built-in clamp() function. Don't plan your PHP 8.2 migration around it. New PHP versions usually need a few point releases, and your plugins and frameworks need time to declare support.

What "end of life" actually means

On January 1, 2027, nothing on your server stops working. PHP 8.2 keeps running. What changes:

• No more security releases from php.net. Vulnerabilities found in PHP 8.2 after that date won't be fixed upstream. PHP regularly fixes security issues in areas a web server can't avoid, such as file uploads, URL and header parsing, and the FPM process manager.
• Scanners start flagging it. Vulnerability scanners and PCI compliance scans typically report an end-of-life PHP version as a finding on their own, whether or not a specific vulnerability is known.
• Libraries move on. Composer packages, WordPress plugins and Laravel releases drop old PHP versions. Over time you can't install updates, including security updates for your own app's dependencies.

There are exceptions. Ubuntu and Debian backport security fixes into the PHP version they ship: PHP 8.1 on Ubuntu 22.04 and PHP 8.3 on Ubuntu 24.04. No Ubuntu LTS release ships PHP 8.2, so if you run it, it came from a third-party source, most likely the Ondřej Surý PPA. That PPA backports fixes to end-of-life versions on a best-effort basis, with no guarantee. Paid extended-support vendors also sell patched builds of old versions. That buys you time, but it isn't a plan.

Check which PHP versions your sites use

php -v only tells you the command-line version. The version a website runs on is decided by your web server. To see everything installed and running:

ls /etc/php/                                  # installed versions, e.g. 8.2 8.3
systemctl list-units --type=service 'php*-fpm*'
ls /etc/php/*/fpm/pool.d/                     # PHP-FPM pools per version

To see which version each site is using:

# Apache with PHP-FPM: which socket each site hands PHP to
grep -rn "proxy:unix\|php.*fpm" /etc/apache2/sites-enabled/ /etc/apache2/conf-enabled/

# Apache with mod_php (the classic LAMP setup)
apache2ctl -M 2>/dev/null | grep -i php

# Nginx
grep -rn "fastcgi_pass" /etc/nginx/sites-enabled/

A socket path such as /run/php/php8.2-fpm.sock tells you the version. For certainty, put a file with <?php echo PHP_VERSION; in the site's web root, load it in a browser, then delete it. Don't forget cron jobs and queue workers: crontab -l and grep -rn php /etc/cron.d/ /etc/supervisor/conf.d/ show which PHP binary they call.

PHP 8.4 or PHP 8.5?

Skipping PHP 8.3 is normal. It only has a year of security fixes left. Choose between 8.4 and 8.5:

Our recommendation: PHP 8.4 is the safe default for a site you want to move once and forget for two years. Choose PHP 8.5 if your framework and every plugin you rely on already list support for it, so you get an extra year before the next upgrade. In WordPress, check each plugin's "Tested up to" note and changelog. For Composer projects, ask Composer directly:

composer why-not php 8.5.0

If nothing is listed, your dependencies allow PHP 8.5. Otherwise Composer names the packages that block it.

What changes between PHP 8.2 and PHP 8.4 or 8.5

Most code written for PHP 8.2 runs unchanged on 8.4 and 8.5. The changes are mostly deprecations: the code still works but logs a "Deprecated" notice. A few changes do break things.

Changes that can break a site:

• Removed extensions (8.4). IMAP, Pspell, OCI8 and PDO_OCI are no longer part of PHP. They moved to PECL. Help desks, mail-importing plugins and some CRMs use imap_* functions. Check whether a php8.4-imap package is available from your PHP source, or replace the plugin.
• Higher bcrypt cost (8.4). password_hash() with the default bcrypt algorithm now uses cost 12 instead of 10 (8.4). Existing hashes still verify. New hashes just take a little longer.

Deprecations you'll see in your logs:

• Implicitly nullable parameters (8.4). function find(User $user = null) must become function find(?User $user = null). This is the most common notice in older plugins and libraries.
• E_STRICT constant (8.4) and trigger_error() with E_USER_ERROR (8.4).
• mysqli_ping(), mysqli_kill() and mysqli_refresh() (8.4).
• Using null as an array key (8.5), as in $data[null] or array_key_exists(null, $data). Common in old code that reads unset request values.
• Non-standard casts (8.5): (integer), (boolean), (double) and (binary). Use (int), (bool), (float) and (string).
• The backtick operator (8.5) as a shortcut for shell_exec().
• MySQL constants on the PDO class (8.5), such as PDO::MYSQL_ATTR_SSL_CA. Use Pdo\Mysql::ATTR_SSL_CA. Look in your database configuration, for example Laravel's config/database.php.

Deprecation notices don't stop a site. They do fill logs, and if display_errors is on in production, visitors can see them. Make sure it's off.

Find problems before you switch

Test before the switch, not after it:

1. Static analysis. PHPCompatibility for PHP_CodeSniffer scans code for features removed or deprecated in a target version. Rector can rewrite many deprecations automatically, such as nullable parameters and casts, if you maintain the code yourself.
2. Your test suite. Run it on the new PHP version with error_reporting=E_ALL, and treat new "Deprecated" lines as a to-do list.
3. A staging copy. Run a copy of the site on the new version and click through the important paths: log in, checkout, contact forms, the admin area, scheduled tasks. For WordPress, turn on WP_DEBUG_LOG on the copy and read wp-content/debug.log afterwards.

Upgrade PHP 8.2 to 8.4 on Ubuntu, step by step

The safe way is to install the new version next to PHP 8.2, move one site at a time, and keep 8.2 installed until everything is confirmed. These steps use PHP 8.4. Replace 8.4 with 8.5 if you chose 8.5. Our guide to installing PHP 8.5 on Ubuntu 24.04 covers running several versions side by side in more detail.

1. Install the new version with the same extensions

On Ubuntu 22.04 and 24.04, PHP 8.4 comes from the Ondřej Surý PPA. You probably already have it, since that's where PHP 8.2 came from:

sudo add-apt-repository ppa:ondrej/php
sudo apt update

Install PHP 8.4-FPM with every extension your 8.2 install has, by renaming the installed 8.2 packages:

dpkg -l 'php8.2-*' | awk '/^ii/ {print $2}' | sed 's/^php8\.2-/php8.4-/' | xargs sudo apt install -y

If apt says it can't find a package, it's usually an extension that was removed or renamed. Install the rest, then decide whether you still need it. Compare the result with php8.2 -m and php8.4 -m.

2. Carry over your settings and pool

Copy your own changes, not the whole file. Compare the two php.ini files and copy over the lines you changed, such as memory_limit, upload_max_filesize or max_execution_time:

diff /etc/php/8.2/fpm/php.ini /etc/php/8.4/fpm/php.ini

Then copy the site's pool to PHP 8.4 and give it a new socket path, so both versions can run at the same time:

sudo cp /etc/php/8.2/fpm/pool.d/shop.conf /etc/php/8.4/fpm/pool.d/shop.conf
sudo sed -i 's#/run/php/php8.2-fpm-shop.sock#/run/php/php8.4-fpm-shop.sock#' /etc/php/8.4/fpm/pool.d/shop.conf
sudo php-fpm8.4 -t && sudo systemctl restart php8.4-fpm

Use your pool and socket names in place of shop. If the site uses the default www pool on /run/php/php8.2-fpm.sock, this is a good moment to give it a pool of its own, running as its own Linux user. Our Ubuntu server hardening checklist explains why.

3. Point the web server at PHP 8.4

Apache with PHP-FPM. In the site's virtual host, change the socket in the PHP handler:

<FilesMatch "\.php$">
    SetHandler "proxy:unix:/run/php/php8.4-fpm-shop.sock|fcgi://localhost"
</FilesMatch>

If all your sites share the global PHP handler instead, swap the config snippet with sudo a2disconf php8.2-fpm && sudo a2enconf php8.4-fpm. Then test and reload. A reload keeps open connections alive:

sudo apache2ctl configtest && sudo systemctl reload apache2

Apache with mod_php. sudo a2dismod php8.2 && sudo a2enmod php8.4, then restart Apache. mod_php upgrades all sites at once and needs the slower prefork MPM. Moving to PHP-FPM with the event MPM is worth doing at the same time: it lets you upgrade one site at a time and gives each site its own process pool and user.

Nginx. Change fastcgi_pass unix:/run/php/php8.2-fpm-shop.sock; to the 8.4 socket, then sudo nginx -t && sudo systemctl reload nginx.

4. Switch the command line, cron jobs and workers

The website is only half of it. Scheduled tasks, Composer, WP-CLI, Artisan and queue workers use the CLI version:

sudo update-alternatives --set php /usr/bin/php8.4
php -v

Then update cron entries and Supervisor programs that name php8.2 or /usr/bin/php8.2 explicitly, and restart long-running workers so they load the new version. On Laravel, php artisan queue:restart does it. Our guide to Laravel queue workers in production covers the Supervisor side.

5. Watch, then clean up

Watch the logs for the first day:

sudo tail -f /var/log/php8.4-fpm.log /var/log/apache2/error.log

If something breaks, rolling back takes seconds: point the handler back at the 8.2 socket and reload the web server. Once every site has run on the new version for a week or two without problems, stop PHP 8.2 and remove it:

sudo systemctl disable --now php8.2-fpm
sudo apt purge 'php8.2*'

How Hanoo handles PHP versions

Hanoo manages Ubuntu servers you own, with PHP-FPM and Caddy. Its PHP handling is built around the steps above:

• PHP 8.0 to 8.5 side by side on Ubuntu 22.04, 24.04 and 26.04. Each application picks its PHP version when it's created and gets its own PHP-FPM pool running as its own Linux user, so sites never share a pool and you can run 8.4 and 8.5 on one server.
• Support status shown up front. When you install a PHP version, Hanoo shows its upstream support status. PHP 8.0 and 8.1 need an explicit acknowledgement because they are past end of life, and PHP 8.2 is flagged with its December 31, 2026 cutoff.
• Patched automatically. PHP comes from Ondřej Surý's repositories (the PPA on 22.04 and 24.04, packages.sury.org on 26.04), and Hanoo adds them to the server's unattended upgrades, which by default only patch Ubuntu's own packages.

To move an app to a newer PHP, create a new application on PHP 8.4 or 8.5, deploy the same code to it and test it on its own address before you move your domain. The old application keeps running until you delete it.

Frequently asked questions

When is PHP 8.2 end of life?

PHP 8.2 receives its last security fixes on December 31, 2026. Active support, with bug fixes, already ended on December 31, 2024. From January 1, 2027, the PHP project won't release fixes for it.

Will my site stop working when PHP 8.2 reaches end of life?

No. PHP 8.2 keeps running exactly as before. The risk is that new vulnerabilities won't be patched, and that plugins and libraries gradually stop supporting it, so you can't install their updates either.

Should I upgrade from PHP 8.2 to 8.3, 8.4 or 8.5?

Go to PHP 8.4 or 8.5. PHP 8.3 only receives security fixes until the end of 2027, so you would be upgrading again within a year. PHP 8.4 has the widest support from plugins and extensions. PHP 8.5 has the longest support, until the end of 2029.

Is PHP 8.4 compatible with WordPress?

Yes. WordPress 6.8 and later fully support PHP 8.4, and WordPress 6.9 and 7.0 fully support PHP 8.5. Individual plugins and themes are the usual source of problems, so test on a staging copy and check your logs for deprecation notices.

How do I check which PHP version my website uses?

php -v only shows the command-line version. Check which PHP-FPM socket your Apache or Nginx site configuration points to, or check apache2ctl -M for mod_php. To be certain, load a temporary file containing <?php echo PHP_VERSION; in the browser, then delete it.

Can I run PHP 8.2 and PHP 8.4 on the same server?

Yes. On Ubuntu, each version installs into its own /etc/php/<version>/ directory with its own PHP-FPM service and sockets. Each site's web server configuration decides which version it uses, so you can move sites one at a time.