PHP 8.2 reaches end of life on December 31, 2026. After that date, the PHP team stops shipping releases for the 8.2 branch, including fixes for security bugs. That's a little over two months from now, and the official supported versions page lists the date for every branch.
Releases and RFCs get most of the attention, but this is the date that matters to a lot of production apps. If you're still running 8.2, here's what the deadline means and how to plan the move.
What End of Life Means
Each PHP branch gets two years of active support, followed by two years of security fixes only. php.net describes that second stage like this:
Releases during this period are made on an as-needed basis: there may be multiple point releases, or none, depending on the number of reports.
PHP 8.2 has been in that security-only stage since December 31, 2024. The most recent release is PHP 8.2.35, a security release from October 21, 2026.
Once the branch is end of life, a new vulnerability that affects 8.2 doesn't get a patch from the PHP team. PHP 8.1 shows how this plays out. It reached end of life on December 31, 2025, and the unsupported branches page lists 8.1.34 as its last release.
Last week shows why the date matters. On October 21, the PHP team shipped fixes for two critical remote code execution bugs, both rated CVSS v4.0 9.2, and 8.2.35 was one of those releases. Fixes like these reach 8.2 until the end of the year, and stop after that.
If you get PHP from an operating system distribution or a hosting provider, check their policy too. Vendors set their own support dates, and they don't always match php.net.
Support Dates for Every Branch
Here are the current dates from php.net:
| Branch | Released | Active support until | Security support until |
|---|---|---|---|
| 8.2 | Dec 8, 2022 | Dec 31, 2024 | Dec 31, 2026 |
| 8.3 | Nov 23, 2023 | Dec 31, 2025 | Dec 31, 2027 |
| 8.4 | Nov 21, 2024 | Dec 31, 2026 | Dec 31, 2028 |
| 8.5 | Nov 20, 2025 | Dec 31, 2027 | Dec 31, 2029 |
PHP 8.6 is in release candidates right now. The PHP 8.6 release schedule targets general availability on November 19, 2026.
Picking a Target Version
The target you pick decides how soon you'll be doing this again.
- PHP 8.3 is the smallest jump, but it's already security-only and reaches end of life on December 31, 2027. You'd be back here in about a year.
- PHP 8.4 buys you security fixes until the end of 2028. Its active support ends on the same day as 8.2's security support, so from January 1, 2027 it only gets security fixes.
- PHP 8.5 is the newest stable release. It's in active support until the end of 2027 and gets security fixes until the end of 2029.
Upgrading two or three versions at once is normal. The work is the same either way: you read the changes for every version you skip.
PHP 8.6 is a fine target if your launch date is a few months out, but don't put a release candidate in production. Wait for the stable release, and for your dependencies to declare support for it.
An Upgrade Checklist
Find Every PHP Install
Run php -v everywhere PHP runs, not only on the web servers. The CLI and PHP-FPM can be different builds on the same machine. Check cron jobs, queue workers, Docker base images, and the images your CI jobs use.
Check Your Dependencies
Composer can tell you which installed packages block a PHP version. The prohibits command (also called why-not) accepts platform packages like php:
composer prohibits php 8.4
Each line of output names a package and the PHP constraint that rules out 8.4. Update those packages first, while you're still on 8.2, so the PHP upgrade itself stays small.
Read the Migration Guides
The PHP manual has a migration guide for every version. Each one lists backward incompatible changes and new deprecations. Read the guide for every version between where you are and where you're going:
Let Rector Do the Mechanical Work
Rector can apply many syntax and deprecation changes for you. With an empty withPhpSets() call, it reads the PHP version from the require section of your composer.json:
use Rector\Config\RectorConfig; return RectorConfig::configure() ->withPaths([__DIR__ . '/src']) ->withPhpSets();
Bump the php constraint in composer.json to your target, then do a dry run. Since Rector 2.6.2, the --php flag limits the run to rules tied to a PHP version, which keeps the upgrade diff separate from other refactoring:
vendor/bin/rector process src --php --dry-run
Review the diff before you run it for real. Rector covers code it can rewrite safely. It won't catch behavior changes in a function you call, so the migration guides still matter.
Test on the New Version
Add the target version to your CI matrix next to 8.2, and keep both green until the switch. Turn on E_ALL error reporting in development and CI so deprecation notices show up. Deprecated features are on their way out, and the notice points you to the exact line while it's cheap to fix.
Run your static analysis with its PHP version set to the target too.
Roll Out in Stages
On the new servers, composer check-platform-reqs confirms the PHP version and extensions match what your installed packages need. It checks the real platform, not the config.platform override.
Move one server, one worker pool, or a slice of traffic first. Watch the error logs for warnings and deprecations you didn't see in testing. Keep the old image around until you're confident you won't need to roll back.
Read More
The supported versions page on php.net always has the current dates. The PHP News security tag collects the security releases as they ship, and the PHP 8.5.11 release shows what a typical one fixes. Start the upgrade now, while 8.2 still gets security patches, and happy updating!
Updates
- October 28, 2026: Corrected the most recent 8.2 release to PHP 8.2.35 from October 21, and updated the paragraph on the critical vulnerabilities, which had described the advance notice instead of the release.
