Skip to main content
Blog

Laravel/

Laravel 11 is end of life: what to do with your app now

Laravel 11 stopped getting security fixes on 12 March 2026, and PHP 8.2 follows on 31 Dec 2026. What that means for your app and why we'd go to Laravel 13.

Nitish Trivedi

Nitish Trivedi

Web Developer

Laravel 11 no longer gets security fixes, and the PHP version many Laravel 11 apps run on loses its own support at the end of this year. Your app keeps working. What changes is who fixes the next security problem.

In short

  • Laravel 11 stopped receiving security fixes on 12 March 2026. Bug fixes ended on 3 September 2025. Any vulnerability found in the framework since March will not be patched for version 11.
  • A second deadline is close. Many Laravel 11 apps run on PHP 8.2, and PHP 8.2 loses security support on 31 December 2026.
  • Our recommendation: upgrade to Laravel 13 on PHP 8.3 or newer, passing through 12 on the same branch. Stopping at Laravel 12 buys you security fixes only until 24 February 2027, about four months from now.
  • Your app will not stop working on any of these dates. The risk is that the next problem has no official fix.

Dates checked against the Laravel 13 support policy and PHP supported versions on 29 Oct 2026.

A cracked Laravel 11 tile marked with a cross, and an arrow leading to a glowing Laravel 13 tile

Who this is for

You run a business on a Laravel app that someone built in 2024 or early 2025. It works, so nobody has touched the framework since launch. Then a security scanner, a new developer or an insurance questionnaire tells you the version is "end of life", and you want to know how worried to be and what the fix costs.

What end of life means for a Laravel 11 app

End of life means the Laravel team no longer ships fixes for that major version. Nothing switches off. The site keeps serving pages, the queue keeps running, and customers notice nothing.

The change is in what happens next time a security problem is found. A Laravel 12 or 13 app gets a patch release and a composer update. A Laravel 11 app gets nothing, and someone has to back-port the fix by hand or upgrade under pressure.

VersionPHP it supportsBug fixes untilSecurity fixes untilStatus on 29 Oct 2026
Laravel 108.1 to 8.36 Aug 20244 Feb 2025End of life
Laravel 118.2 to 8.43 Sep 202512 Mar 2026End of life
Laravel 128.2 to 8.513 Aug 202624 Feb 2027Security fixes only
Laravel 138.3 to 8.5Q3 202717 Mar 2028Fully supported

Source: Laravel support policy. Our Laravel and PHP version support dates page keeps the full table current.

The PHP 8.2 deadline is the one most owners miss

Laravel 11 runs on PHP 8.2, 8.3 or 8.4. If your server runs 8.2, the language itself stops getting security fixes on 31 December 2026 (php.net). After that, both layers under your app are unpatched.

You can check both in a minute on the server, or ask whoever hosts it to run:

php artisan --version
php -v
composer audit

The first line shows the framework version, the second the PHP version. composer audit lists known security advisories against the packages your app has installed (Composer docs). An empty audit today does not mean the app is safe next month. It means nobody has published an advisory yet.

Should you upgrade to Laravel 12 or go straight to 13?

Go to 13. Laravel 12 is already past its bug-fix window and has about four months of security fixes left. Upgrading to 12 now means paying for another upgrade project in early 2027.

You cannot skip a major version in one jump, though. Laravel publishes one upgrade guide per major, so the work goes 11 to 12, then 12 to 13. We do both on one branch, test after each step, and ship once. On our Laravel upgrade service that is the standard order: PHP first, then the framework one major at a time, then packages.

Laravel 13 needs PHP 8.3 or newer. If your host cannot run PHP 8.3, the server move becomes part of the upgrade, not an afterthought.

What would change our mind: if a package your app depends on has no Laravel 13 release yet, stopping at 12 for a few weeks is reasonable. Plan the second step before February 2027, not after.

How much work is an 11 to 13 upgrade?

The official guides are optimistic by design. Laravel estimates 5 minutes for 11 to 12 (upgrade guide) and 10 minutes for 12 to 13 (upgrade guide). Those numbers describe a fresh app with no third-party packages. Real business apps take longer for reasons that have little to do with the framework:

  • Third-party packages that have not released a compatible version, or were abandoned.
  • Test tooling. Laravel 12 moves to PHPUnit 11 and Pest 3, and Laravel 13 to PHPUnit 12 and Pest 4, so an app with a test suite gets two rounds of test-runner changes.
  • The PHP upgrade and the server it runs on.
  • Code with no tests around the parts that make money, such as checkout or billing.

What tends to break when you leave Laravel 11

A few changes in the official guides catch real apps. These are the ones worth checking before you start:

StepChangeWhy it matters
11 to 12Carbon 2 support removed; Carbon 3 requiredDate handling code and packages pinned to Carbon 2 fail to install
11 to 12HasUuids now generates UUIDv7 (ordered)Models using UUID keys change ID format. Use HasVersion4Uuids to keep the old behaviour
12 to 13Cache config gains serializable_classes, set to false by defaultApps that store PHP objects in cache must list those classes, or cached values stop loading
12 to 13PHP 8.3 minimumHosting has to move before the framework can

Source: Laravel's 12.x and 13.x upgrade guides, checked 29 Oct 2026.

What it costs

At Spectivis an upgrade starts with a free assessment. We read the code, the lock file, the PHP version, the tests and the hosting, list every blocker, and send a fixed written quote with a timeline. No work starts until you sign it off.

After the upgrade, minor and patch releases are covered by our $49 a month care plan, so the app stays on a supported version without another project. Our managed Laravel hosting starts at $99 a month and includes that care plan. Major upgrades change your code, so they are always quoted separately.

When we would not recommend upgrading now

If the app is being retired or replaced within the next few months, an upgrade is wasted money. Keep it patched at the server level, restrict who can reach it, and put the budget into the replacement.

If the app depends on an abandoned package for something central, like payments or authentication, the upgrade is really a replacement project for that package. Scope that first, because it decides the price more than the framework does.

And if the app is small, barely used and has no tests, ask whether a rebuild on Laravel 13 costs less than catching it up. Sometimes it does. We say so in the assessment when that is our view.

What to do next

Run the three commands above, or ask your developer or host for the output. If you are on Laravel 11 with PHP 8.2, put the upgrade in this quarter's plan rather than next year's. If you want a second opinion, send us the versions and the audit output and we will tell you what the upgrade involves before quoting anything.

Sources and further reading