PHP 8.1 end of life: moving up safely
PHP 8.1 stopped getting security fixes from the PHP project on 31 December 2025. Whether that matters today depends on where your PHP comes from. Here is how to tell, and how to upgrade without breaking sites.
- Security support
- Ended 31 Dec 2025, 310 days ago
- On Ubuntu 22.04
- Patched by Canonical to May 2027
- Move to
- PHP 8.4 (to Dec 2028) or 8.5 (to Dec 2029)
- Path
- Straight to the new version, site by site
Who still patches your PHP 8.1
That depends on where it came from. Run php -v, then check which package provides it: dpkg -S $(which php) on Debian or Ubuntu, rpm -qf $(which php) on RHEL-style systems.
Ubuntu 22.04's own package: still patched by Canonical, to May 2027, and to 2032 with Ubuntu Pro. You have time, but not much, and the version number still shows up in every scan.
A third-party repository (the popular PHP PPA, Remi, or a control panel's builds): these follow PHP's own dates. The packages may still install, but they get no more security fixes.
A Docker image or a build from source: the official images stopped at 8.1's last release. Nothing new is coming.
Either way, the questions customers ask are about version numbers, and "8.1" is now an answer that needs explaining.
What breaks on the way up
Most of the work is clearing deprecations, which turn into errors a version or two later. These are the ones that catch most sites.
| Step | Supported to | What to watch |
|---|---|---|
| 8.1 → 8.2 | 31 Dec 2026 | Dynamic properties (setting a property a class never declared) are deprecated, which floods the logs of older WordPress plugins and frameworks. ${var} inside strings and utf8_encode() / utf8_decode() are deprecated too. |
| 8.2 → 8.3 | 31 Dec 2027 | The smallest step. A few deprecations (calling get_class() with no argument, for one) and stricter behaviour in some date and range functions. |
| 8.3 → 8.4 | 31 Dec 2028 | A default of null on a typed parameter without ? (function f(Foo $x = null)) is deprecated, and older code is full of it. The IMAP, OCI8 and Pspell extensions leave core for PECL, so code using imap_* needs the extension installed separately or a library instead. |
| 8.4 → 8.5 | 31 Dec 2029 | The backtick shell operator and old cast names such as (integer) and (boolean) are deprecated. Check your framework and main plugins support 8.5 before choosing it. |
Dates from php.net, read 6 November 2026. PHP 8.6 is at its fifth release candidate and due later this month.
WordPress and Laravel
WordPress core runs on PHP 8.4, but plugins and themes are where upgrades fail. Update everything first, then test on a copy with WP_DEBUG logging on and read the log. Abandoned plugins are the usual problem, and the fix is often a replacement rather than a patch.
Laravel versions and PHP versions move together: each Laravel release supports a range of PHP versions, and newer Laravel releases drop the older ones. An app on an old Laravel may need its framework upgraded before it can move to PHP 8.4, which makes it a development job as well as a server job.
For anything else, run the test suite on the new version. If there isn't one, a static check such as PHPCompatibility for PHP_CodeSniffer finds most problems before they reach a live site.
How to upgrade a server
Install the new version alongside the old one. On Debian and Ubuntu, a supported PHP repository gives you several versions side by side, each with its own PHP-FPM service.
Copy each site's settings across. Compare the php.ini and FPM pool settings (memory limits, upload sizes, extensions) and install the same extensions for the new version. A missing extension is the most common cause of a blank page after an upgrade.
Move one site at a time. Point the site's web server configuration at the new FPM socket, reload, and check it. If anything is wrong, point it back.
Don't forget the command line. Cron jobs, queue workers and Composer use the CLI version, set with update-alternatives --config php. They often stay on the old version by mistake.
Remove the old version once every site and job has run on the new one for a couple of weeks.
How I run the move
- 01Inventory and a fixed quote
Every site and job on the server, the PHP version each one needs, and which of the changes above will bite. Then a fixed quote.
- 02Rehearsal on staging
A copy upgraded or rebuilt first, every site and job tested, every problem fixed there.
- 03The window, with a way back
The real move at a time you agree, the old server or a snapshot kept ready, then two weeks' stabilisation.
Upgrades and migrations →
Questions
When did PHP 8.1 reach end of life?
On 31 December 2025, when its security support ended. The PHP project no longer releases fixes for 8.1.
Is PHP 8.1 on Ubuntu 22.04 still patched?
Yes, by Ubuntu rather than by PHP. Canonical backports security fixes into the PHP 8.1 package that ships with 22.04 until standard support ends in May 2027, and to 2032 with Ubuntu Pro. Scanners and customers still see "8.1" and flag it.
Which PHP version should I upgrade to?
PHP 8.4, supported to the end of 2028, is the safe target for most sites today. 8.5 runs to the end of 2029 if your framework and plugins support it. PHP 8.6 is due in late November 2026.
Can I skip straight from 8.1 to 8.4?
Yes. There is no need to stop at each version: the work is fixing what each step deprecated or removed, and you can do it in one go. The table on this page lists what to look for.
Can I run two PHP versions on one server?
Yes, with PHP-FPM. Install the new version beside the old one and move sites across one at a time, each with its own pool. It is the lowest-risk way to upgrade a server with many sites.
Is there paid support for PHP 8.1?
Yes. Commercial vendors such as Zend and TuxCare sell security fixes for end-of-life PHP versions. It costs more each year than the upgrade, and buys time rather than solving anything.
Still on PHP 8.1?
Tell me what runs on it. I'll tell you what will break on 8.4, and give you a fixed quote for the move.