PHP 8.2 end of life: 31 December 2026, for Laravel teams

On Laravel 12 you face two dates close together: PHP 8.2 ends on 31 December 2026, and Laravel 12 security fixes end on February 24, 2027. The fix for the second depends on the first, because Laravel 13 won’t install on PHP 8.2. Leave PHP until January and you’ll have about eight weeks left to do both.

PHP 8.3 is accepted on every Laravel version in that table. So you can always move to it first, even on a Laravel version that’s already out of support, and leave the framework for a separate release.

Dates are from php.net’s supported versions page, checked on 30 October 2026.

• PHP 8.3 is the smallest step, with about a year of support left. It suits you if a dependency or your host rules out anything newer, but expect to repeat this project in 2027.
• PHP 8.4 is what we’d pick for most applications on Laravel 11, 12 or 13. Some current package releases now require it, including spatie/laravel-activitylog 5.1.3, spatie/laravel-query-builder 7.3.7, spatie/laravel-translatable 6.15.0, pestphp/pest-plugin-laravel v5.0.1. The next framework major looks likely to need it too: Laravel’s master branch requires PHP 8.4 today, though that can change before release.
• PHP 8.5 gives the longest window, and works on Laravel 12 and 13. It has more deprecations to clear, so read what PHP 8.5 changes for Laravel first. It also rules out older lines of some packages: inertiajs/inertia-laravel 1.x, for example, stops at PHP 8.4.

PHP 8.3 is a gentle release for most web applications. These are the items from php.net’s incompatible changes and deprecations lists that we’d look for in Laravel code.

• Negative array keys. Assigning index -5 to an empty array now makes the next key -4, not 0. Code that builds arrays from offsets can change shape without any error.
• Date exceptions. The Date extension now throws DateError and DateException where it used to raise warnings. A try block that catches something narrow, or code that checks for warnings, needs another look.
• Empty string increments. Using ++ on an empty or non-alphanumeric string is deprecated, as is -- on an empty or non-numeric string.
• Class helpers. Calling get_class() or get_parent_class() with no argument is deprecated. It’s common in older base classes.
• Assertions and reflection. assert_options() and calling ReflectionProperty::setValue() with one argument are both deprecated. Test helpers are the likely place to find them.

If you’re going on to 8.4, also sweep for implicitly nullable parameters. Our PHP 8.1 guide shows the fix, along with the 8.2 changes that may still be in your logs.

The code changes are often the easy part. These environment problems are harder to spot:

• Web and CLI on different versions. Hosting panels often change the version for the website but not for cron or queue workers. Check php -v in the same context your scheduler uses.
• A pinned platform. If composer.json sets config.platform.php to 8.2, Composer keeps resolving for 8.2 after the server has moved. Update or remove it.
• Missing extensions. Each PHP version has its own set of extensions on many servers. Run composer check-platform-reqs on the new version before you switch traffic.
• Workers still on the old code. Long-running queue workers and Octane keep the old process until restarted, so restart them as part of the release.

PHP’s last security releases show what you’d lose. On 21 October 2026, the PHP project published security releases, including PHP 8.2.35. Our write-up of those vulnerabilities has the checklist we used. Teams on 8.2 could simply update. After 31 December, php.net won’t publish a release like that for 8.2.

A Linux distribution or hosting vendor may keep backporting fixes for its own PHP packages, so read their notice if you rely on one. Those fixes cover the runtime only. Composer packages will keep raising their PHP floors whatever your vendor does, and you’ll slowly lose access to new releases.

A PHP move on its own is usually a small piece of work, and your team may well handle it with the steps above. If you’d like it done along with the framework, our Laravel upgrade service covers both for one fixed price, and Laravel maintenance keeps PHP current afterwards. For the framework and package side, use the package compatibility matrix and Laravel and PHP matrix.