PHP 8.2 End of Life: What Laravel App Owners Should Do

If your Laravel application runs on PHP 8.2, its security support ends on 31 December 2026. After that date the PHP project releases no more fixes for 8.2, including for security vulnerabilities. The safest plan is to move to PHP 8.3 or 8.4 now and, if your app is on Laravel 11 or older, upgrade the framework at the same time, because those Laravel versions no longer get security fixes either.

This guide is for owners and CTOs of businesses that depend on a Laravel app. It explains what end of life means in practice, how to find out where you stand, which upgrade path fits your version, and what to do in the weeks left.

When does PHP 8.2 reach end of life?

According to the official PHP supported versions page, PHP 8.2 was released on 8 December 2022, its active support ended on 31 December 2024, and its security support ends on 31 December 2026. Since January 2025 it has only received security fixes; from January 2027 it receives nothing.

Here is where each PHP version stands today:

Sources: php.net supported versions and php.net unsupported branches. If you are still on PHP 8.1 or older, you are already past end of life.

What does end of life mean for a Laravel app?

Your app will not stop working on 1 January. End of life is about risk, not an off switch. In practice it means:

• No more security patches. When a new vulnerability is found in PHP, versions that are still supported get a fix. PHP 8.2 won't.
• Packages move on. Laravel, its first-party packages and popular third-party packages drop old PHP versions over time. On an old PHP version you can get stuck on old package releases, including old releases of the packages that handle payments, authentication or file uploads.
• Hosting gets harder. Hosting providers and server tools tend to retire end-of-life PHP versions. If your PHP comes from your Linux distribution's packages, check that distribution's own support policy, because it follows its own timeline.
• Audits get harder. If customers, partners or auditors ask you to confirm that your software is supported and patched, an end-of-life PHP version makes that answer harder to give.

The longer an app stays on an unsupported version, the bigger the eventual upgrade, because more versions of PHP, Laravel and packages pile up between where you are and where you need to be.

Which Laravel versions are affected?

PHP is only half the picture. Laravel gives each major release bug fixes for 18 months and security fixes for 2 years, and each release supports a specific range of PHP versions:

Sources: Laravel 13 release notes and Laravel 10 release notes.

Three things stand out:

1. Laravel 11 and older are already out of security support. Laravel 11's security fixes ended on 12 March 2026.
2. Laravel 12 is on borrowed time. Its bug fixes ended on 13 August 2026 and its security fixes end on 24 February 2027, less than two months after PHP 8.2.
3. Laravel 13 needs PHP 8.3 or newer. The release notes state that "Laravel 13.x requires a minimum PHP version of 8.3", so moving off PHP 8.2 is also the step that unlocks the current Laravel release.

How do you check which PHP and Laravel versions your app runs?

Ask your developer or hosting provider, or run these commands on the production server from the app's folder:

php -v
php artisan --version
composer show laravel/framework

Check the PHP version that serves web requests too, not only the command line one. On many servers PHP-FPM and the CLI can be different versions. Your hosting control panel or server tool usually shows which PHP version each site uses.

Then look at composer.json:

• The require section shows which PHP versions the app declares (for example "php": "^8.2").
• config.platform.php, if present, pins the PHP version Composer resolves packages for. It must be updated when you change PHP, or Composer will keep choosing packages for the old version.

Two more commands help size the job:

composer outdated --direct
composer audit

The first lists the packages your app depends on directly that have newer versions. The second checks your installed packages against known security advisories.

Should you upgrade PHP first or Laravel first?

It depends on your Laravel version, because each Laravel release only runs on certain PHP versions.

A good target for most apps today is Laravel 13 on PHP 8.4, which gives PHP security support until 31 December 2028 and Laravel security fixes until 17 March 2028. PHP 8.5 is also supported by Laravel 12 and 13; choose it if all your packages support it.

Upgrade Laravel one major version at a time. Each version has its own upgrade guide, and skipping versions makes it hard to tell which change broke what.

What does the upgrade work involve?

Laravel's own upgrade guides list small estimated times for the framework steps (15 minutes from 10 to 11, 5 from 11 to 12, 10 from 12 to 13), and say that only some of the documented changes will affect a given app. In real applications most of the work is around the framework:

• Packages. Every Composer package must have a release that supports your target PHP and Laravel versions. Abandoned packages need replacing. This is often the largest part of the job.
• Breaking changes per version. Examples from the official guides:
  • Laravel 11 requires PHP 8.2, needs new major versions of Sanctum, Passport, Cashier and Telescope if you use them, and changes how column modifications in migrations behave. It also states that apps upgrading from Laravel 10 do not need to adopt the new, slimmer application structure.
  • Laravel 12 moves to Carbon 3 and to PHPUnit 11 or Pest 3 for tests.
  • Laravel 13 renames the CSRF middleware to PreventRequestForgery and adds origin checks, hardens cache unserialization, and changes the default session serialization to JSON in new apps; switching an existing app to it logs out every active user.
• PHP changes. Each PHP release deprecates or changes some behaviour. The official migration guides for PHP 8.3 and PHP 8.4 list them.
• Servers and deployment. Installing the new PHP version and its extensions on every server that runs the app: web servers, queue workers, scheduled tasks and CI.
• Tooling. Laravel Shift automates much of each upgrade, and the official upgrade guide points to Laravel Boost for an AI-assisted upgrade from 12 to 13. Both still need a developer to review and test the result.

What are the risks, and how do you reduce them?

Most upgrade problems come from code that has no tests and from changes that reach production all at once. To reduce the risk:

1. Add tests around what earns money first. Sign-up, login, checkout, invoicing, reports, integrations. Even a small set of feature tests catches the most expensive breakages.
2. Work on a copy. Upgrade on a branch and a staging server with a recent copy of production data, never directly on production.
3. Watch background work. Queued jobs, scheduled commands and webhooks often break silently. Check logs and failed jobs after each step.
4. Read the deprecation warnings. Enable deprecation logging before moving to a new PHP version; the warnings show what will break next.
5. Plan the switchover. Take a backup, deploy at a quiet time, and keep the previous release ready to roll back.

A checklist for the weeks before 31 December

• This week: confirm the PHP and Laravel versions on every server, and run composer outdated --direct and composer audit.
• Next: list packages with no release for your target versions and decide how to replace them.
• Then: add tests for critical flows, set up staging with the target PHP version, and upgrade there.
• Before go-live: test with real data, check queues and scheduled tasks, update CI and every server, and agree a rollback plan.
• After go-live: monitor errors and failed jobs, then schedule the next step (for Laravel 12 apps, the move to Laravel 13 before 24 February 2027).

What if you can't finish the upgrade by 31 December?

Don't panic, and don't freeze. Start with what lowers risk most: get the PHP version change done first if your Laravel version allows it, because that is usually the smaller step. Make sure the app's dependencies have no known advisories, keep the server operating system patched, and put the full plan on a timeline with dates. An app that is a few weeks past the deadline with a plan is in a far better position than one that is left for another year.

If your app is much older, or nobody on the team knows it well anymore, read our guide on migrating legacy web applications to Laravel. And once you are current, staying current is cheaper than catching up; see why Laravel maintenance and support matter.

Need a hand with the upgrade?

CodeBrisk was founded in 2014 and our team lead has worked with Laravel since 2015. We are a Top Rated agency on Upwork with a 100% Job Success score across 87 jobs. Our Laravel upgrade and migration service moves PHP, Laravel and every package to supported versions one step at a time, with tests around your critical features first. If you prefer to build an in-house team instead, our guide on how to hire Laravel developers covers what to look for.

Tell us which versions you are on through Launch your project or contact us, and we will suggest the safest path for your app.