Laravel 12 end of life: February 24, 2027, and what to do first

These come from the support policy in Laravel’s release notes. Our Laravel versions page lists the older releases too.

The first date has already passed, and it’s easy to miss. Since August 13, 2026, a defect that isn’t a security problem is no longer in scope for Laravel 12. If you hit a framework bug today, the fix is likely to land on 13 only, so you may be carrying a workaround already.

Your application keeps running. What ends is the promise of a patch. If a vulnerability in the framework is reported after February 24, 2027, you can’t assume a Laravel 12 release will follow. At that point your options are a rushed upgrade or a patch you maintain yourself.

The other change is what you can say about your software. Customer security questionnaires, penetration tests and procurement reviews often ask whether your framework is still supported. Before the date, the answer is yes. After it, you’ll have to explain why not.

Laravel 12 accepts PHP 8.2–8.5 and Laravel 13 accepts PHP 8.3–8.5. So the only version that blocks you is PHP 8.2, and that has its own deadline: php.net ends its security support on 31 December 2026, nearly two months before the framework date.

That gives you a natural order. Move PHP first, on Laravel 12, and release it. Once it has settled, move the framework. If something breaks, you’ll know which change caused it. Our PHP 8.2 end-of-life guide helps you choose between 8.3, 8.4 and 8.5.

These release lines allow Laravel 12 but not 13, according to their published constraints. If you have one installed, Composer will refuse the framework update until you change its major version. Each of those major updates can bring its own breaking changes, so this is usually where the time goes.

This is a selection, not a full list. The full table, with the method and the date we last checked it, is on our Laravel package compatibility matrix. To check your own application, run composer why-not laravel/framework ^13.0.

1. This week: run composer why-not laravel/framework ^13.0 and composer why-not php 8.3, then ask your host which PHP versions they offer for web, CLI and queue workers.
2. Before 31 December: move PHP off 8.2, if you’re on it. Clear deprecation notices while you’re there.
3. Next: update the packages that allow both Laravel 12 and 13, one at a time, so that each release changes one thing.
4. Then: change the framework constraint, following our Laravel 12 to 13 guide. The CSRF middleware rename and the new cache serializable_classes default are the two most likely to reach your code.
5. Finally: release to staging, run the flows your business depends on, and go live with a way back.

The upgrade checklist has the same sequence in more detail.

Some teams won’t reach 13 by February, whether because of a large custom package, a frozen release period or a host that won’t move. In that case, keep the exposure small. Run composer audit on a schedule, keep Laravel 12 on its latest patch until the end, keep PHP supported, and put a real date on the upgrade rather than leaving it open. A firewall can reduce some risk, but it won’t fix a framework vulnerability.

Our Laravel maintenance plan covers framework, package and PHP updates at USD 99/month, invoiced in the customer's local currency. That suits teams who’d rather not go through this every year.

Our Laravel upgrade service starts with a free assessment and ends in a fixed quote. Published prices run $799–$2,999+ in USD, invoiced in USD, GBP, EUR or INR, depending on the size of the application. The cost guide explains what moves that number. Laravel’s release notes call 12 to 13 a relatively minor upgrade, so the packages above usually decide how much work this is.