Laravel 11 stopped receiving security fixes on 12 March 2026. Laravel 12 stopped receiving bug fixes on 13 August 2026 and its security fixes end on 24 February 2027. If your business runs on either, this is the plain-English version of what those dates mean, how to check which one you have, and what it takes to move.
The dates, from Laravel's own support policy
Laravel releases one major version a year. Each gets 18 months of bug fixes and two years of security fixes, then nothing.
- Laravel 10: security fixes ended 4 February 2025. Runs on PHP 8.1–8.3.
- Laravel 11: bug fixes ended 3 September 2025; security fixes ended 12 March 2026. Runs on PHP 8.2–8.4.
- Laravel 12: bug fixes ended 13 August 2026; security fixes end 24 February 2027. Runs on PHP 8.2–8.5.
- Laravel 13: released 24 February 2026, bug fixes until 10 August 2027, security fixes until 24 February 2028. Needs PHP 8.3+.
Dates are taken from the Laravel release notes and kept in one place on our side, so every page that mentions them says the same thing.
What "end of life" means for a business, not a developer
Nothing breaks on the day. The application keeps serving pages. What changes is that when a security flaw is found in the framework, the fix ships for the supported versions and not for yours. From that point every new advisory is a door that stays open, and you find out about it from a scanner, an insurer or an incident, not from Laravel.
Laravel 12 is in the middle state now: security fixes still arrive until 24 February 2027, ordinary bugs are no longer fixed. That is the comfortable window to plan the move, before it becomes a deadline.
How to check which version you are on
Which Laravel version is your app on?
Paste your composer.json into the free audit. Within 24 hours you get the end-of-life dates, the abandoned packages, and a fixed price for bringing it current.
- Ask whoever looks after the application to run
php artisan --version, or opencomposer.lockand findlaravel/framework. The number before the first dot is the major version. - Ask for the PHP version the server runs:
php -von the server, or the PHP selector in the host's control panel. The version incomposer.jsonis only the oldest the app allows, not what it runs on. - Or paste the
composer.jsoninto the free Laravel audit and get both dates and the size of the upgrade in writing within a day. The same check is open source on GitHub if your developer prefers to run it themselves.
The PHP date that lands in between
PHP 8.2 stops receiving security fixes on 31 December 2026, two months before Laravel 12 does. A Laravel 11 or 12 application still running PHP 8.2 therefore hits its first deadline at the end of December, not in February. Laravel 12 runs on PHP 8.2–8.5, so it can move the runtime to PHP 8.4 without a framework change; Laravel 11 tops out at PHP 8.4. Our PHP 8.2 guide covers that date in full.
What forces the date in practice
The release calendar is advisory. These three are not, and each is quoted from its source.
Cyber Essentials v3.2 (April 2025)
All software on in-scope devices must: be licensed and supported; removed from devices when it becomes unsupported or removed from scope by using a defined sub-set that prevents all traffic to / from the internet; have automatic updates enabled where possible; be updated, including vulnerability fixes, within 14 days of release, where the update fixes vulnerabilities described by the vendor as 'critical' or 'high' risk
Bespoke application code is out of Cyber Essentials scope, but the PHP runtime and operating system on an internet-facing server are not. A Laravel app pinned to an end-of-life PHP branch fails the certification through its server.
Source, checked 16 October 2026.
Cyber insurance renewal
Use of any outdated or unsupported software or systems
Listed among the exclusions on Hiscox UK's cyber and data insurance policy. Policies are re-assessed every twelve months, so the renewal questionnaire is usually where an owner first meets the version problem. The UK Cyber Security Breaches Survey 2025 found 62% of small and 65% of medium businesses hold cyber insurance.
Source, checked 16 October 2026.
Your host retires the PHP version
If your project uses a retired version, you must update to a supported version.
Upsun (Platform.sh) lists PHP 8.1 and older as retired and 8.2 and 8.3 as deprecated. Ubuntu 20.04, which shipped PHP 7.4, left standard support in May 2025. Shared hosts force the runtime change on their own schedule, and the application breaks on their date rather than yours.
Source, checked 16 October 2026.
The routes to Laravel 13
- From Laravel 12: one major version. Usually the shortest upgrade there is: dependencies bumped, a handful of breaking changes, the test suite run green. It fits inside the Upgrade Sprint.
- From Laravel 11: two majors, taken one at a time with the suite green between them, plus the PHP move to 8.3+. Normally still one sprint.
- From Laravel 10 or older: three or more majors, abandoned packages to replace, and often tests to write first so there is something to prove each step with. That is the Full Upgrade.
Laravel publishes an upgrade guide for each version, and its own tooling has made single-version moves faster than they used to be. The cost sits elsewhere: third-party packages that never followed, custom code leaning on internals, and the absence of tests that would say whether anything broke. The upgrade cost guide shows how those drive the price.
What it costs with us
- Upgrade Sprint, $2,500 (£1,900), 7–10 working days. One or two Laravel majors and the matching PHP move, on a branch, test suite green, staging sign-off before production.
- Full Upgrade, $4,500–$6,000 (£3,400–£4,500), 2–3 weeks. Several majors, abandoned packages replaced, tests backfilled where they are missing.
- Care plan from $500/month. 6 engineer-hours a month on the Essentials plan, so Laravel 14 next year is a routine release rather than a project.
What to do this quarter
- Find the Laravel version and the server's PHP version (the two commands above).
- On Laravel 11 or older: you are already past end of security support. Book the upgrade now; the longer the gap, the more majors it spans.
- On Laravel 12: plan the move to 13 before 24 February 2027, and the PHP move before 31 December 2026 if the server is still on 8.2.
- On Laravel 13: put 10 August 2027 and PHP 8.3's 31 December 2027 in the calendar, or let a care plan carry them.
Find out where your app stands
Paste your composer.json on the free Laravel audit page. You get a written report within a day: the Laravel and PHP versions, the date each stops receiving fixes, the packages that block the move, and a fixed price. No call needed.
Frequently asked questions
Do we have to go all the way to Laravel 13?
To be on a supported version after 24 February 2027, yes: Laravel 13 is the only release receiving security fixes then. Stopping at 12 buys months, not years.
Our developer says the app works fine on Laravel 11. Is that wrong?
No. It works, and it will keep working. The point is that security fixes stopped on 12 March 2026, so the next framework advisory will not be patched for it. Working and supported are different questions.
Can we skip straight from Laravel 10 to 13?
The code can end up on 13 in one engagement, but the safe route goes one major at a time with tests green at each step. Skipping the intermediate steps is where upgrades go wrong.
We have an in-house developer. Why would we use you?
Most of our upgrade clients have one. An upgrade is a bounded piece of work that competes with the feature roadmap, and a fixed price with a date beats a quarter of evenings. We hand over notes your developer can read; the care plan is optional.
