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

> PHP 8.2 loses security support on December 31, 2026. What end of life means, PHP 8.4 vs 8.5, what breaks, and a safe upgrade on Ubuntu with Apache or Nginx.

Source: https://hanoo.io/blog/php-8-2-end-of-life · Published 2026-11-12 · Updated 2026-11-12 · By the Hanoo team

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.

> **In short:** PHP 8.2 reaches end of life on December 31, 2026. Move to **PHP 8.4** (security fixes until December 2028) if you want the version with the widest plugin and extension support. Move to **PHP 8.5** (until December 2029) if your framework and plugins already support it. Install the new version next to 8.2, give the site its own PHP-FPM pool, switch the web server over, and keep 8.2 installed until you're sure you won't need to roll back.

## 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:

| Version | Released | Active support until | Security fixes until |
| --- | --- | --- | --- |
| PHP 8.1 | Nov 2021 | Ended | **Ended Dec 31, 2025** |
| PHP 8.2 | Dec 2022 | Ended | **Dec 31, 2026** |
| PHP 8.3 | Nov 2023 | Ended | Dec 31, 2027 |
| PHP 8.4 | Nov 2024 | Dec 31, 2026 | Dec 31, 2028 |
| PHP 8.5 | Nov 2025 | Dec 31, 2027 | Dec 31, 2029 |
| PHP 8.6 | Due Nov 19, 2026 | — | — |

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:

```bash
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:

```bash
# 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:

| | PHP 8.4 | PHP 8.5 |
| --- | --- | --- |
| Security fixes until | Dec 31, 2028 | Dec 31, 2029 |
| WordPress | Fully supported since 6.8 | Fully supported in 6.9 and 7.0 |
| Laravel 13 | Supported | Supported |
| Magento 2.4.9 | Supported | Supported (the version new stores are installed with) |
| Extensions and older plugins | Widest support | Most, but check older plugins |
| Upgrade effort from 8.2 | Smaller | A few more deprecations |

**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:

```bash
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](https://github.com/PHPCompatibility/PHPCompatibility) for PHP_CodeSniffer scans code for features removed or deprecated in a target version. [Rector](https://getrector.com/) 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](/blog/install-php-8-5-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:

```bash
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:

```bash
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`:

```bash
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:

```bash
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](/blog/secure-ubuntu-24-04-server-hardening) 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:

```apache
<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:

```bash
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:

```bash
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](/blog/laravel-queue-workers-production) covers the Supervisor side.

### 5. Watch, then clean up

Watch the logs for the first day:

```bash
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:

```bash
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.