PHP End of Life Schedule Going Into 2027: Which Version to Actually Run

PHP 8.2 reaches end of life on December 31, 2026. As I write this, that is roughly three months away. If any of your projects, or a client's, are still running it, this is the actual planning window, not a someday problem. I want to lay out the full picture going into 2027, since the official schedule holds a second detail most people miss entirely, and it affects PHP 8.4 too, not just the version everyone already knows is old.

The official PHP support schedule

PHP moved to a predictable four-year lifecycle in 2024. Two years of active support, covering bug fixes and security patches, followed by two more years of security-only support, then end of life. Every branch's dates now land on December 31, which makes planning genuinely simple once you know the pattern. This table reflects the official schedule from php.net's own supported versions page.

The detail almost everyone misses: PHP 8.4 changes status on the same date as 8.2's death

Here is what I think deserves more attention than it gets. December 31, 2026 is not just the day PHP 8.2 dies. It is also the exact day PHP 8.4 drops out of active support and becomes security-only. If you are running 8.4 today assuming it is the safely current choice, that assumption quietly changes at the start of 2027. You will still get critical security patches through the end of 2028, but no more bug fixes, no more of the small improvements that come with active support. Going into 2027, PHP 8.4 moves into the same maintenance category PHP 8.3 is already in right now.

That leaves PHP 8.5, released in November 2025, as the only branch that carries full active support into 2027. If you are starting a brand new project today, or planning one for early 2027, 8.5 is the version actually receiving both bug fixes and security patches during that window, not just security patches.

What this means for your actual projects

If you or a client is still on PHP 8.2, treat the December 31, 2026 date as a real deadline, the same way we covered when PHP 8.1 reached its own end of life. Test the upgrade on staging first, check plugin and package compatibility, and do not wait until the date has already passed to start.

If you are on PHP 8.3 or 8.4, there is no fire to put out immediately. Both remain fully supported for security patches well into 2027 and beyond. I would still put an upgrade to 8.5 on your actual roadmap rather than treating "still receiving security patches" as equivalent to "nothing to plan for," since 8.3 in particular is already past active support today.

The catch: your dependencies will drop an old PHP version before php.net does

The official end of life date is not usually the first deadline you actually hit. Framework and package maintainers tend to drop support for an aging PHP version well ahead of its official death, on their own separate schedule. You will typically notice this first as a Composer update quietly refusing to pull in a newer package version, or a plugin's own requirements page listing a higher PHP minimum than what php.net itself still calls supported. We saw this exact pattern play out when WordPress 7.0 raised its own minimum PHP version, ahead of any php.net deadline forcing the issue.

I would check your specific framework's PHP requirements, and your hosting provider's actual PHP selector options, rather than assuming php.net's calendar is the only clock running.

FAQ

Should I skip PHP 8.4 entirely and go straight to 8.5?
Not necessarily. If you are already comfortably running 8.4 with no compatibility issues, there is no urgency to jump versions again immediately just because active support ends. Security patches continue through 2028. I would plan the move to 8.5 as your next natural upgrade cycle, not as an emergency.

What actually stops working when a PHP version reaches true end of life?
Nothing stops running on its own. Your existing code keeps executing exactly as before. What stops is any future patch for a newly discovered vulnerability, which means your exposure only grows over time with no fix coming, the same risk we covered in detail with PHP 8.1.

Is PHP 8.5 stable enough for a production app right now?
It is a full stable release with the same support commitment as any other branch, but I would still verify your specific framework version, any compiled extensions, and your hosting provider all officially support it before moving a live production app over, rather than assuming compatibility.

How do I check which PHP version my hosting actually offers?
Most hosting control panels have a PHP version selector, often under a section called "PHP Configuration" or similar. If you cannot find one, or your host caps out below a current version, that is worth raising with them directly, since it is increasingly common for hosts to lag behind the official schedule.

Does this schedule apply to PHP-FPM the same way as CLI PHP?
Yes, the version lifecycle applies to the PHP runtime itself, regardless of whether you are running it through FPM, as a CLI script, or embedded another way. The security exposure is the same either way.

Bottom line

PHP 8.2 has a real deadline three months out as I write this. PHP 8.4 quietly loses active support on that exact same date, which is the detail most 2027 planning conversations skip entirely. Check where your actual projects sit against this table, and remember that your framework or host will very likely ask you to move before php.net's own calendar does.

Sources: PHP.net, Supported Versions; PHP.net, Unsupported Branches. Verified directly against php.net's official schedule on September 21, 2026.