PHP 8.2 stops receiving security fixes on 31 December 2026. That calendar is not the Laravel 13 upgrade question. Teams keep folding them together, then either freeze both or bump both in one weekend.
This is the runtime decision. The framework decision already has its own article.
What ends in December
The PHP project publishes the dates on supported versions. Active support is bug fixes. After that, a branch gets security fixes only, and then nothing.
| Branch | Active support | Security fixes until |
|---|---|---|
| 8.2 | Ended 31 Dec 2024 | 31 Dec 2026 |
| 8.3 | Ended 31 Dec 2025 | 31 Dec 2027 |
| 8.4 | Until 31 Dec 2026 | 31 Dec 2028 |
| 8.5 | Until 31 Dec 2027 | 31 Dec 2029 |
After 31 December 2026, PHP 8.2 is not “a bit behind.” The PHP project will not patch it. A Laravel security release does not fill that hole.
This is not the Laravel 13 decision
Should Philippine teams upgrade to Laravel 13 is about the framework major. Laravel 12 still receives security fixes until 24 February 2027, and it runs on PHP 8.2 through 8.5. Laravel 13 requires PHP 8.3 or newer. Those facts are on the Laravel 13 release notes.
You can move the runtime and stay on Laravel 12. You should not stay on PHP 8.2 past December and call the app supported because the framework line has not ended.
PHP 8.3 is already in security-only support, through 2027. PHP 8.4 is in active support until the end of 2026, then security fixes through 2028. PHP 8.5 is current if the host and extensions are ready. “Newest” is not the requirement. Still receiving fixes after December is.
What we change first
- Read
php -von the web box, the queue workers, and CI. They drift apart more often than thecomposer.jsonplatform line admits. - Move staging to 8.3 or 8.4 and re-run the paths that take money, create bookings, or send mail. Extension and signature changes show up there, not in a homepage refresh.
- Ship the runtime by itself. Do not combine it with a Laravel major and a new feature.
- Decide the framework upgrade after production has been on the new PHP long enough to trust it. The sequence in the Laravel 13 article is the same: runtime first.
Where the process actually runs is a hosting question. Philippine data centers vs APAC cloud is that choice. A region does not pick your PHP version. The image you deploy does.
What we will not pretend
- Framework support is not language support.
- A shared host that cannot leave 8.2 is a hosting constraint, not a reason to skip the date.
- “We will get to it in January” means you plan to run an unpatched language. Write the date or move the date up.
Straight next step
If you have a production Laravel app and you are not sure which PHP is actually running, send the version from the server and the workers. We will say whether December is a runtime change only, or whether the framework major has to travel with it.
