Laravel 11 is out of support, and Laravel 12 has until February. Is your application covered?
Laravel 11 stopped receiving security fixes in March 2026, and Laravel 12 follows in February 2027. How to tell whether your application is affected, and how to keep it supported without the yearly scramble.
Laravel releases a new major version every year, and each one is supported for a fixed window. That rhythm is one of the framework’s strengths, but it also catches organisations out. An application that was built, launched and then left alone can drift out of support without anyone noticing.
Two dates matter right now. Laravel 11 stopped receiving security fixes on 12 March 2026, and Laravel 12 stops on 24 February 2027. If your application runs on either, this post covers what that means and how to get ahead of it.
How Laravel support works
Every Laravel release gets 18 months of bug fixes and two years of security fixes. There are no long-term support releases any more, so every application is on the same yearly clock.
| Version | Released | Bug fixes until | Security fixes until |
|---|---|---|---|
| Laravel 10 | 14 February 2023 | 6 August 2024 | 4 February 2025 |
| Laravel 11 | 12 March 2024 | 3 September 2025 | 12 March 2026 |
| Laravel 12 | 24 February 2025 | 13 August 2026 | 24 February 2027 |
| Laravel 13 | 17 March 2026 | Q3 2027 | 17 March 2028 |
Source: Laravel release notes.
Put simply, an application built in 2024 or early 2025 and untouched since is probably already unsupported. One built from spring 2025 onwards is likely on Laravel 12, which has been receiving security fixes only since August, and has a few months left.
Why this catches people out
Unlike a CMS with an “update” button in its control panel, a Laravel application is bespoke software. Upgrades are a developer’s job, and they only happen if someone plans for them. That tends to slip in a few familiar ways:
- The project ended at launch. The application was built as a fixed-price project, it went live, and the ongoing care was never scoped.
- The developer moved on. A freelancer took on other work, an in-house developer left, or an agency changed focus. The application kept running, so nobody noticed.
- Upgrades lost out to features. Each year the upgrade felt less urgent than the next feature, until the gap became two or three versions.
None of these are unusual, and an out-of-date application isn’t a sign that anyone did anything wrong. But the longer it’s left, the harder the climb back.
It’s not just Laravel’s clock
The framework is one of three clocks ticking at once.
PHP has its own support window. PHP 8.1 lost security support at the end of 2025, and PHP 8.2 follows on 31 December 2026. Laravel 11 and 12 both support PHP 8.2 as their minimum, so any Laravel 12 application still on 8.2 will lose PHP security support before Laravel’s own deadline arrives. Laravel 13 needs PHP 8.3 or later.
Your packages move on too. A typical Laravel application relies on dozens of Composer packages for payments, PDFs, admin panels, search and APIs, plus a JavaScript toolchain for the front end. Many only support recent Laravel versions, and some get abandoned altogether. Falling behind on Laravel usually means falling behind on all of them.
Your hosting may force the issue. Hosting providers and managed platforms retire old PHP versions on their own schedules. When that happens, an application that can’t run on a newer PHP version becomes an emergency rather than a plan.
The good news: the upgrade is getting easier
Laravel’s stated aim is that you can move to a new major release “in one day or less”, and Laravel 13 leans into that. The release notes describe it as a relatively minor upgrade, after a year spent shipping improvements that don’t break existing applications. The headline requirement is PHP 8.3, and there are a handful of changes worth checking, such as the CSRF middleware being formalised as PreventRequestForgery.
In return, you get access to everything Laravel 13 brings, including the first-party AI SDK we wrote about recently, JSON:API resources and native vector search.
Upgrading from Laravel 12 to 13 is often a small, well-defined piece of work. The applications that need more care are the ones several versions behind.
Several versions behind?
If your application is on Laravel 10 or earlier, the upgrade happens one major version at a time, each with its own upgrade guide. Tools such as Laravel Shift automate a lot of the mechanical changes, but the real question is how you know nothing has broken.
That’s where automated tests earn their keep. If the application has a good test suite, each step can be verified quickly. If it doesn’t, we start by writing tests around the parts that matter most, such as checkout, sign-up, invoicing and integrations, before changing the framework underneath them. When we took over TDI Tuning’s Laravel platform, we grew the test suite to nearly four times its size at handover, which is what makes every upgrade since a routine job.
Plan it, don’t scramble
The cheapest way to stay on a supported version is to treat upgrades as routine maintenance rather than a project. Laravel ships around the same time each year, so the upgrade can be scheduled like any other recurring job: a small amount of time each year, rather than a large and risky catch-up every few years.
That’s how we handle it for the applications on our Laravel support retainers. Security patches, and Laravel and PHP version upgrades, are planned into each client’s monthly hours well before support ends, alongside the features and improvements the application actually exists for.
Where to start
First, find out which version you’re on. Your developer can check in seconds: it’s in the application’s composer.lock file, and php artisan about shows it along with the PHP version.
If the answer is Laravel 11 or earlier, or you don’t have a developer to ask, we can help. Every engagement starts with a fixed-price onboarding audit. Over one to two days we review the code quality, dependencies, Laravel and PHP versions, hosting and deployment pipeline, then give you a written report in plain English and a prioritised plan. It’s yours to keep, whether or not you carry on with us.
From there, upgrades can be done ad hoc, or as part of a monthly support retainer. We’ve been building with Laravel since 2017, and if your application needs a new home, get in touch.
