Short version for the impatient: Laravel 13 shipped on March 17th, 2026, and the date that should drive your upgrade planning is not that one. It’s the day bug fixes stop for the version you’re running. For Laravel 12 that day was August 13th, 2026, which means it already passed while I was busy with other things.
I opened my spreadsheet of client apps last week and the Laravel 11 rows made me wince. Laravel 11 hit end of life in March. I knew that in the vague way you know your car’s inspection is “sometime this spring”. Then I went and read the actual support table instead of trusting my memory, and my memory was wrong in two places. So this post is the version of that table I wish I’d had, plus the small tooling I now use so I stop guessing.
If you are searching for the Laravel 13 release date because a client asked “are we current?”, the answer is below, along with the question you should ask instead.
The dates in one place
The Laravel release notes and the release cycle summary on Laravel News agree on the recent history. Major versions have landed early in the year since Laravel 9:
- Laravel 9: February 8th, 2022
- Laravel 10: February 14th, 2023
- Laravel 11: March 12th, 2024
- Laravel 12: February 24th, 2025
- Laravel 13: March 17th, 2026
The docs describe the schedule as “every year (~Q1)”, so a new major can land in February or March, and Laravel 14 is expected in the first quarter of 2027. Laravel 13 requires PHP 8.3. Laravel News says Laravel 14 will require PHP 8.4, which matters if a client’s host is still pinned to an older PHP, because then the framework upgrade is really a server upgrade wearing a disguise.
Support is the same shape for every major. Bug fixes for 18 months, security fixes for two years. Laravel 6 was the last LTS release, so nothing gets a longer window anymore. Here is how that plays out for the versions I still see in the wild:
- Laravel 10: bug fixes ended August 6th, 2024, security fixes ended February 4th, 2025. End of life.
- Laravel 11: bug fixes ended September 3rd, 2025, security fixes ended March 12th, 2026. End of life.
- Laravel 12: bug fixes ended August 13th, 2026, security fixes run until February 24th, 2027.
- Laravel 13: bug fixes until Q3 2027, security fixes until Q1 2028 (the Laravel News page gives March 17th, 2028).
One caveat on my own table: the official docs list Laravel 13’s end dates as quarters, and I’m quoting the quarters. Treat anything more precise as an estimate until the docs change.
Why the 18 months matters more than the two years
Most clients I talk to have heard “Laravel gets two years of security fixes” and concluded they have two years. That’s the generous number, and it’s the wrong one to plan around.
Here’s the arithmetic that bit me. A new major ships roughly every twelve months. Bug fixes last eighteen. So the previous major keeps getting bug fixes for only about six months after the new one ships. Laravel 13 came out on March 17th, and Laravel 12’s bug fixes ended five months later. After that date, a bug in Laravel 12 is something you either work around or fix in your own code, because the core team won’t patch it.
Security fixes are a different story and they do keep coming, so a Laravel 12 app isn’t about to be a liability tomorrow. But I’ve stopped treating “still gets security patches” as “fine”. My reasoning is boring and practical. Packages in the ecosystem follow the framework. The Laravel News write-up points out that for other first-party libraries, only the latest major release gets bug fixes. So the surrounding code you depend on moves on faster than the framework’s security window suggests.
I’d put it this way to a client: security-only is a holding pattern, not a place to live. You have roughly a year of holding pattern, and the work to leave it gets bigger the longer you wait, not smaller.
What a yearly cadence did to upgrade size
The reason I’m relaxed about all this, despite the dates sounding stressful, is that the upgrades themselves got small. Laravel moved to Semantic Versioning with Laravel 6 in September 2019. Since then, minor and patch releases shouldn’t break anything, and the team ships features during the year in those minors. Laravel 13.0 came out in March 2026, and by September 22nd the framework was at 13.33, according to Laravel News. That’s thirty-three feature and fix releases you absorbed with a plain composer update.
So a major version only has to carry the changes that break something. The 12.x release notes call Laravel 12 a “maintenance release” and say most applications can upgrade without changing application code. The docs also say they aim to make a major upgrade possible in a day or less. I’m skeptical of “a day” for a large app with a pile of custom packages, but I’ve done plenty of upgrades that took an afternoon, and I’ve never had one go badly when the app was only one version behind.
The upgrades that hurt are the ones where someone skipped two majors. Then you’re reading three upgrade guides at once and trying to work out which breakage came from which. If you take one thing from this post, take that: staying one version behind is cheap, staying three behind is a project.
The PHP floor is the other thing that stretches an upgrade. A host that can’t run PHP 8.3 turns a one-afternoon task into a negotiation with whoever manages the server. I check the PHP version before I check anything else now.
Pinning versions so the upgrade is a decision
The constraint in composer.json is where the policy becomes real. The docs recommend a caret constraint like ^12.0, since a major release can include breaking changes. Here’s what I used to have in a client app, and what I changed it to.
{
"require": {
"php": "^8.2",
"laravel/framework": "^11.0"
}
}
{
"require": {
"php": "^8.3",
"laravel/framework": "^13.0"
}
}
The first version looks harmless, and that’s the problem. It never complains. Composer will happily keep resolving the newest 11.x forever, and nothing in the project tells you the version has been out of support since March. The caret constraint protects you from surprise breakage, which is its job, but it also hides the passage of time.
The upgrade itself is mostly mechanical. Laravel’s upgrade guide for 13.x even mentions a /upgrade-laravel-v13 slash command for coding assistants, which requires Laravel Boost ^2.0. I haven’t used it on a client app yet, so I can’t tell you whether it’s good. I’d run it on a branch and read every line of the diff, the same way I’d treat a junior’s pull request.
I’ll admit I used to bump versions in a hurry right before a client call. That’s how I ended up merging a framework upgrade on a Friday once, which I don’t recommend, and which taught me that the date to do this is early in the week with a staging deploy and a rollback you’ve actually rehearsed.
A check I run every quarter
Rather than trust my memory again, I keep the support dates in code and let a script yell at me. This is a small PHP file I run from a scheduled job. It reads the framework version from composer.lock, compares it with a table of dates, and prints a warning when a project is out of bug fixes or out of security fixes.
<?php
// Dates from https://laravel.com/docs/13.x/releases
$support = [
'10' => ['bugfix' => '2024-08-06', 'security' => '2025-02-04'],
'11' => ['bugfix' => '2025-09-03', 'security' => '2026-03-12'],
'12' => ['bugfix' => '2026-08-13', 'security' => '2027-02-24'],
];
$lock = json_decode(file_get_contents('composer.lock'), true);
foreach ($lock['packages'] as $pkg) {
if ($pkg['name'] !== 'laravel/framework') {
continue;
}
$major = explode('.', ltrim($pkg['version'], 'v'))[0];
$dates = $support[$major] ?? null;
if (! $dates) {
echo "Laravel {$major}: no dates in my table, check the docs\n";
continue;
}
$today = new DateTimeImmutable('today');
$bugfix = new DateTimeImmutable($dates['bugfix']);
$security = new DateTimeImmutable($dates['security']);
if ($today > $security) {
echo "Laravel {$major}: END OF LIFE\n";
} elseif ($today > $bugfix) {
echo "Laravel {$major}: security fixes only until {$dates['security']}\n";
} else {
echo "Laravel {$major}: bug fixes until {$dates['bugfix']}\n";
}
}
Two things about this script. First, I left Laravel 13 out of the table on purpose, because its end dates are quarters in the docs and I’d rather have the script say “no dates, check the docs” than invent a day. Second, it’s a dumb script. It doesn’t know about PHP versions or about the first-party packages that only support the latest major. Making it smarter is a weekend project I keep not doing, and the dumb version has already paid for itself.
I also store the output next to each client’s retainer notes. When a client’s app flips from “bug fixes” to “security only”, that’s the conversation starter for a scoped upgrade, quoted at a fixed price rather than discovered during an incident. I wrote about how I think about that pricing in how I price freelance web development work, and a scheduled upgrade is the easiest line item to sell because the deadline isn’t mine.
If you want to see the kind of Laravel client work this feeds into, my portfolio has the projects. And if you’ve hit the other class of upgrade trap, the one where a new tool changes your build in ways the docs don’t flag, I covered one in my Laravel Wayfinder post.
Where I’m still unsure
I don’t have a firm opinion on whether a client on the current major should upgrade the week a new one ships. The docs suggest the upgrade is small, and the argument for going early is that you stay on a version with bug fixes for the full eighteen months. The argument against is that packages take a few weeks to catch up, and being first means finding the incompatible one yourself.
My current rule is to wait for the first couple of minor releases of the new major, then upgrade within the same quarter. It’s a compromise, and I can’t prove it’s optimal. If Laravel 14 lands in Q1 2027 as expected, I’ll test that rule against what actually happens and report back.
What to do this week
Open every Laravel project you’re responsible for and run composer show laravel/framework. Write down the major version next to a date: the day bug fixes end, and the day security fixes end. If any of them is on Laravel 11 or older, that’s an end-of-life app and it goes at the top of your list. If any is on Laravel 12, put the February 24th, 2027 security date in your calendar with a reminder three months earlier. Then check each server’s PHP version against the Laravel 13 floor of PHP 8.3, because that’s the thing most likely to turn a small upgrade into a long one.
