PHP 8.2 stops getting security fixes on 31 December 2026. Laravel 10, 11 and 12 can move to a newer PHP on their own. Laravel 9 can't, and that changes the plan.
Will anything happen to your Laravel site on 1 January 2027? On the day, no. PHP 8.2 gets its last security release by 31 December 2026, and after that the PHP project stops patching it, so the next flaw found in 8.2 stays open on every server that runs it. That leaves about eleven weeks. What you need to do depends on one number: your Laravel version. Laravel 10, 11 and 12 can move to a newer PHP on their own. Laravel 9 can't, because it was never supported above PHP 8.2, so for those apps the PHP deadline is also a framework deadline.
What does end of life mean for PHP 8.2?
PHP 8.2 came out on 8 December 2022. Under the schedule on php.net's supported versions page, each branch gets two years of bug and security fixes, then two more years of security fixes only. For 8.2, active support ended on 31 December 2024. Security support ends on 31 December 2026.
Nothing switches off after that. The risk arrives quietly: a flaw gets published in February, the fix ships for 8.3, 8.4 and 8.5, and your server never gets it.
Here's what keeps getting fixes after New Year: 8.3 until 31 December 2027, 8.4 until 31 December 2028, 8.5 until 31 December 2029. PHP 8.1 is no longer on the list.
Will my host switch PHP for me?
Maybe, and probably not on a day you'd pick. A post on Plesk's blog about legacy PHP, from March 2026, says end-of-life versions stop receiving official security updates and offers paid Extended Lifecycle Support through TuxCare for versions 5.6 to 8.1. 8.2 wasn't on that list when it was written. For a Laravel app that takes orders every day, paying to keep an old PHP alive only moves the job down the road.
So ask your host two things this month: which PHP versions they'll offer on 1 January, and whether they plan to move sites off 8.2 themselves. A host that moves a Laravel 9 app to 8.4 overnight puts it on a PHP that Laravel 9 was never supported on, and you find out what breaks in production.
Which Laravel versions run on which PHP
The PHP ranges and dates below come from the support policy in Laravel's own release notes.
| Laravel | PHP it supports | Laravel security fixes until | Can it leave 8.2 without a Laravel upgrade? |
|---|---|---|---|
| 8 | 7.3 to 8.1 | 24 Jan 2023 | Never supported 8.2 at all |
| 9 | 8.0 to 8.2 | 6 Feb 2024 | No |
| 10 | 8.1 to 8.3 | 4 Feb 2025 | Yes, to 8.3 |
| 11 | 8.2 to 8.4 | 12 Mar 2026 | Yes, to 8.3 or 8.4 |
| 12 | 8.2 to 8.5 | 24 Feb 2027 | Yes, to 8.3, 8.4 or 8.5 |
| 13 | 8.3 to 8.5 | 17 Mar 2028 | Can't run on 8.2 |
Two things stand out. Every Laravel below 12 is out of security fixes today, whatever PHP sits under it. And Laravel 9 is the only release where 8.2 is the ceiling.
Stuck on Laravel 9?
If composer.lock says laravel/framework 9.x, the server can't move to PHP 8.3 unless the framework moves too. Laravel 9 lost its own security fixes on 6 February 2024, so from January the app would have neither a patched framework nor a patched language under it.
The way out is up the ladder, one major version at a time, with PHP moving at the right rung: on Laravel 10 the app can run 8.3, on 11 it can run 8.4. That's how the Laravel and PHP upgrade service works, one major version per commit, with logins, payments and the admin tested on staging. You can jump straight to 13 instead. When something breaks, though, you won't know which of four releases caused it.
Laravel 10 and 11: PHP first, framework soon after
These apps can leave 8.2 without touching Laravel. A Laravel 10 app can go to PHP 8.3, which is patched until the end of 2027. Laravel 11 can go as far as 8.4, patched until the end of 2028.
We'd do that move before Christmas, because it's the smaller job and it takes the PHP date off the table. Be clear about what it buys, though. Laravel 10 stopped getting security fixes in February 2025 and Laravel 11 in March 2026, so the framework stays unpatched afterwards. Treat the PHP change as a way through the winter, then book the framework work. What that costs, and why two apps on the same version can be priced differently, is in our breakdown of Laravel upgrade costs.
Laravel 12: the easy case, with a second date
Laravel 12 runs on anything from 8.2 to 8.5, so moving the server is often a PHP setting plus a test pass. Pick 8.4 or 8.5 rather than 8.3. Laravel 13 needs PHP 8.3 at minimum, and 8.3 runs out of security fixes at the end of 2027, so stopping there means another PHP move in a year.
Then put 24 February 2027 in the diary. That's when Laravel 12's own security fixes end, and the 12 to 13 step is due before it.
What breaks when PHP moves up from 8.2?
Less than people fear, in most apps. Most changes between 8.2 and 8.5 are deprecations, which log a notice and carry on. They matter anyway: a log full of notices buries the line you need, and some packages cap PHP in their composer.json and refuse to install above it.
The one you'll meet most in older code comes from PHP 8.4. A typed parameter with a default of null used to become nullable without saying so. In 8.4 that's deprecated, so function find(User $user = null) should become function find(?User $user = null). The fix is mechanical. In an app with a few hundred classes, it's also everywhere.
PHP 8.5 deprecates a couple more, according to its migration guide in the PHP manual: the backtick operator as a shortcut for shell_exec(), and the old cast names (boolean), (integer), (double) and (binary). Neither is common in Laravel code, but old helper files are where they hide.
What about Debian 12, which ships PHP 8.2?
This is the one real exception. Debian 12, bookworm, packages its own php8.2 and keeps backporting security fixes into it. The Debian LTS wiki shows bookworm handed to the long-term support team on 11 June 2026 and covered until 30 June 2028, and Debian's security tracker lists php8.2 updates issued under that programme.
So a stock Debian 12 server using that package is less exposed in January than the calendar suggests. Two limits: it covers Debian's package only, not PHP installed through a control panel or another repository. And a Laravel 9 app on a patched PHP remains a Laravel 9 app.
The order we'd do it in
Write down the two numbers: Laravel from composer.lock, PHP from the hosting panel. The table above tells you which route you're on.
Next, copy the site to staging and move that copy to the new PHP, or up one Laravel version if you're on 9. Run it with deprecation notices switched on and read the log, not just the pages. Then click through everything that takes money or locks people out: login, password reset, checkout, the admin.
If those hold, the production switch is a small, ordinary deploy. If they don't, you found out in October, with eleven weeks left, rather than in January with none.
Five questions about the PHP 8.2 deadline
When does PHP 8.2 reach end of life?
Security support ends on 31 December 2026, per php.net. Active support, meaning ordinary bug fixes, ended on 31 December 2024.
Can I keep running PHP 8.2 after December?
It will keep running. It just won't get fixes from the PHP project. The exception is Debian 12's own php8.2 package, which Debian's LTS team supports until 30 June 2028.
Which PHP should a Laravel 12 app move to?
8.4 or 8.5. Both run Laravel 12 and 13, and they're patched until the end of 2028 and 2029. 8.3 works too, but its support ends a year sooner.
Does Laravel 9 run on PHP 8.3?
Not officially. Laravel's support table lists PHP 8.0 to 8.2 for Laravel 9, so it has to move to Laravel 10 or later before the server leaves 8.2.
What does it cost to move a Laravel 9 app to a supported version?
Our fixed price for a full upgrade from Laravel 8 or later is $3,500, and one major version up is $1,500. Both come after a free written audit, and the price is agreed before work starts.
