Which Laravel Version Are You On, and Is It Still Getting Fixes?

Laravel publishes a support table, and it's the most useful page on their site for anyone who owns an application rather than writes one. It tells you, with dates, whether the framework your business runs on is still being fixed.

Here it is as published, at the time of writing:

Those are Laravel's own figures. Read the two right-hand columns against today's date and you get your answer.

What the two columns mean

Bug fixes are the ordinary maintenance stream: something behaves incorrectly, it gets fixed, you get the fix in a patch release.

Security fixes continue for longer, and cover only flaws with a security impact. A version in this window is still safe to run in the sense that reported vulnerabilities get patched, but ordinary defects in it are now permanent.

After both dates, nothing further is published for that version at all.

The policy behind the table is 18 months of bug fixes and 2 years of security fixes for every release, with a new major version each year around the first quarter. That's the whole planning model, and it's more generous than it first looks: it means you can be a full version behind and still be receiving security patches.

Where that leaves most applications today

Laravel 10 has been fully out of support since February 2025.

Laravel 11 passed its security-fix date on March 12, 2026. If you're on 11, no further fixes of any kind are coming.

Laravel 12 stopped receiving bug fixes on August 13, 2026 — recently enough that it may not have registered. It still gets security fixes until February 2027, so there's no emergency, but the clock is now visible.

Laravel 13 arrived on March 17, 2026 and is the only version currently getting bug fixes.

How to check where you are

From the application directory:

php artisan --version

If you can't run commands on the server, look in composer.json for the laravel/framework line. That shows the constraint the project allows, such as ^12.0. For the version actually installed, composer.lock is the honest answer — a constraint of ^12.0 tells you it's some Laravel 12, not which one.

While you're there, check your PHP version with php -v, because the two are linked and the PHP one is often the real obstacle. The table above lists the PHP versions each Laravel release supports, and they only move forward.

What being unsupported actually costs

Not what people fear, and not nothing.

Your application doesn't stop working. There's no license check, no deadline that disables anything. A Laravel 10 application running today runs exactly as it did.

What you lose is future fixes. A vulnerability found in the framework next year gets patched in the supported versions and not in yours. There's no notification and no visible change on the day it happens — you simply have an unpatched flaw with a public description of how it works.

The slower cost is the ecosystem drifting away. Packages drop support for old framework versions, so a package you need a fix from will eventually require a Laravel version you're not on. The same applies underneath: each Laravel version supports a range of PHP versions, and PHP has its own end-of-life schedule. Staying put means eventually running unsupported PHP on an unsupported framework, which is where "we should upgrade" turns into "we can't upgrade without a project."

And it gets harder the longer you leave it, which is the part worth planning around. Each hop has its own set of breaking changes, and the work of four hops taken together is worse than four hops taken separately — a year apart, each one is a contained job against a documented guide. Four years later, it's an unpicking exercise where a failure could have come from any of them.

A schedule that works

Upgrade once a year, shortly after the new major release settles. Laravel ships majors around Q1, so pick a month in the middle of the year, when the release has had time to shake out and the packages you depend on have caught up.

Doing it that way, you're always inside the bug-fix window, always one documented hop from current, and the job stays small enough to fit in a normal week rather than needing its own budget line.

If you're already several versions behind, the same principle applies in reverse: go one version at a time rather than aiming straight at 13. Each release has an upgrade guide written for the version immediately before it, so taking them in order means using those guides as they were written.

The question to ask your developer isn't "are we on the latest version" — being one behind is a perfectly reasonable place to be. It's "are we still inside the security window, and when do we fall out of it." That has a date for an answer, and you can put it in a calendar.

We upgrade and maintain Laravel applications and the web systems built on them, including ones several versions behind. If you want to know where yours stands and what getting current would take, tell us what you're running.