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
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.

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.
| Version | PHP it supports | Bug fixes until | Security fixes until | Status on 29 Oct 2026 |
|---|---|---|---|---|
| Laravel 10 | 8.1 to 8.3 | 6 Aug 2024 | 4 Feb 2025 | End of life |
| Laravel 11 | 8.2 to 8.4 | 3 Sep 2025 | 12 Mar 2026 | End of life |
| Laravel 12 | 8.2 to 8.5 | 13 Aug 2026 | 24 Feb 2027 | Security fixes only |
| Laravel 13 | 8.3 to 8.5 | Q3 2027 | 17 Mar 2028 | Fully 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:
| Step | Change | Why it matters |
|---|---|---|
| 11 to 12 | Carbon 2 support removed; Carbon 3 required | Date handling code and packages pinned to Carbon 2 fail to install |
| 11 to 12 | HasUuids now generates UUIDv7 (ordered) | Models using UUID keys change ID format. Use HasVersion4Uuids to keep the old behaviour |
| 12 to 13 | Cache config gains serializable_classes, set to false by default | Apps that store PHP objects in cache must list those classes, or cached values stop loading |
| 12 to 13 | PHP 8.3 minimum | Hosting 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
- Laravel 13 release notes and support policy, checked 29 Oct 2026
- Laravel upgrade guide, 11.x to 12.0, checked 29 Oct 2026
- Laravel upgrade guide, 12.x to 13.0, checked 29 Oct 2026
- PHP supported versions, checked 29 Oct 2026
- Composer CLI: audit
- Our Laravel and PHP version support dates
- How much does Laravel maintenance cost?