Laravel Version Support Policy: When Does Your Version Lose Security Fixes?

Laravel's version support policy is the same for every recent release: each major version gets 18 months of bug fixes and 2 years of security fixes, and a new major version ships roughly once a year. In practice, only the two newest versions are covered at any given time. As of January 2027, that means Laravel 13 with full support and Laravel 12, which stops receiving security fixes on February 24, 2027.

If your app runs Laravel 11 or anything older, it's already getting no patches at all. Below is the full table, what each support phase means for an app in production, and what I'd do depending on which version you're on.

The short answer

Here's when each version loses bug fixes and security fixes. The dates come from Laravel's official support policy table, with the older versions taken from the Laravel 9 release notes. Always double-check the official table before you make a decision, since dates for upcoming versions can shift.

My rule of thumb is simple. On the latest version, keep applying updates as they come. On the second newest, the upgrade belongs on your calendar for the next few months. Two or more versions behind, you're unpatched, and the upgrade should be your top technical priority.

Laravel 14 doesn't have an official release date yet. According to Laravel News' Laravel 14 overview, it will require at least PHP 8.4 because it builds on Symfony 8, though that could still change before release. Version support is only one part of keeping an app healthy. Backups, monitoring and hosting are covered in my complete guide to web application maintenance.

Bug fixes, security fixes and end of life

Every Laravel release moves through three phases, and the one you're in tells you how much time you have.

Full support: the first 18 months

Laravel fixes both regular bugs and security issues in your version. Fixes ship as minor and patch releases, which, under Laravel's own policy, should never contain breaking changes. Your developer can pull them in routinely without rewriting anything.

Security fixes only: months 18 to 24

Ordinary bugs no longer get fixed in your version, but security vulnerabilities still do. The app is still reasonable to run, and this is the window where the upgrade should be planned and ideally underway. Laravel 12 sits in this phase until February 24, 2027.

End of life

Nothing visible happens on the day support ends. The app keeps running exactly as before, it just receives no more fixes. When a vulnerability is later found in Laravel, the fix only goes to supported versions, and the details usually become public, which makes unpatched apps easier to target. Third-party packages also drop support for old Laravel versions over time, so you lose that route to fixes as well.

The rhythm is predictable. Laravel ships a new major version around the first quarter of each year, and when it lands, the previous version typically has about six months of bug fixes and a year of security fixes left. Laravel 13 came out on March 17, 2026, and Laravel 12 received its last bug fixes on August 13, 2026. That gap is your window to upgrade without pressure.

Don't forget PHP: the second deadline

Laravel runs on PHP, and PHP has its own lifecycle: 2 years of active support followed by 2 years of security fixes, always ending on December 31. According to PHP's list of supported versions, PHP 8.2 gets security fixes through December 31, 2026. From 2027, PHP 8.3 is the oldest version still being patched.

Each Laravel version only supports a specific range of PHP versions. That range decides how long you can keep the server itself patched, even after Laravel support has ended.

This is where the oldest apps get into real trouble. A Laravel 10 app gets no framework fixes, but it can at least run on a PHP version that's still patched. From 2027 onward, Laravel 9 officially supports no PHP version that still gets security fixes. Both layers are unpatched at once.

The PHP requirement cuts the other way too. Laravel 13 needs PHP 8.3 or newer, and Laravel 14 is expected to need 8.4. If your server runs an older PHP, it has to be upgraded before or alongside the framework. Hosting providers also retire old PHP versions from their platforms sooner or later, and that can force an upgrade on short notice.

How to check which Laravel version you're running

You don't need to write code to find out. Here's how:

1. Ask your developer or hosting provider: "Which versions of Laravel and PHP is our app running in production?" That should take minutes to answer.
2. If you or a developer has server access, the command php artisan --version prints the Laravel version. On newer versions, php artisan about gives a summary that includes both the Laravel and PHP versions.
3. If you have access to the repository, open composer.lock, search for laravel/framework, and read the version number just below it.
4. Check the PHP version where the app actually runs, for example in your hosting control panel. The command line and the web server can run different PHP versions on the same machine, so php -v in a terminal isn't always the full picture.
5. Write down both versions and their end dates from the tables above, and set a reminder six months before the first one.

This usually takes under an hour. If whoever maintains your app can't give you a clear answer, that tells you something too: probably nobody is watching.

What to do based on your version

Once you know your version, the next step is fairly clear. This is what I'd recommend for a typical business app with user logins and personal data.

On Laravel 12, the upgrade is rarely a big job. Laravel's own upgrade guide from 12 to 13 estimates 10 minutes, and the team deliberately kept breaking changes to a minimum. That can hold for a small app with few packages and decent test coverage. With lots of third-party packages and no tests, expect more, because every package also has to support the new version.

On Laravel 10 or 11, there are more steps. Work through the upgrade guides in order, and ideally ship each step separately so it's obvious which one caused a problem. I've written up the safe way to do it, with backups, a staging environment and a rollback plan, in why and how to keep your software dependencies updated. For budgeting, see my breakdown of what a Laravel upgrade costs.

On Laravel 9 or older, including the old Laravel 5 and 6 apps, you're looking at a project, not a routine task. The question is whether it pays to upgrade step by step or to modernize parts of the system. I cover that in signs your legacy PHP application needs modernizing.

Can't upgrade before the deadline?

Sometimes the upgrade can't be finished before support ends. A critical package may not support the new version yet, or your team is tied up elsewhere. In that case, the goal is to reduce risk until the upgrade is done:

• Set a specific date for the upgrade and stick to it. "Soon" isn't a plan.
• Keep PHP and the server on the newest version your Laravel release supports.
• Watch for security advisories. Run composer audit regularly so you know when known vulnerabilities show up in your packages.
• Limit who can reach the app. An admin panel, for example, can be restricted to specific IP addresses or put behind a VPN.
• Switch off features nobody uses, and remove packages the app no longer needs.
• Make sure backups and monitoring work, so you spot problems fast and can recover.

None of this makes an unsupported version safe. It buys you time, and that time should go into the upgrade. Write the decision down, with the risks you accepted and the date you'll be done. If you sell to larger European companies, their security questionnaires often ask whether you run supported software versions, and a documented plan is a far better answer than a shrug.

When you don't need outside help

I earn money from upgrades, so it's only fair to say when you can skip hiring someone. If you have an in-house developer who knows Laravel, a 12 to 13 upgrade on an app with tests is a manageable task with the official guide in hand. If the app is being shut down or replaced within a few months, an upgrade is rarely worth the cost, and restricting access while you wind it down is the better call. And if the app isn't built on Laravel, none of these dates apply. Find a specialist in whatever it actually runs on.

Next steps

Start with the two version numbers: Laravel and PHP. Compare them against the tables above and put the dates in your calendar. This checklist is all you need for a clear picture.

If upgrades aren't already part of your agreement with your developer, get them written in. My checklist for a software maintenance agreement shows what it should cover. If you'd like help with the work itself, here's how I handle Laravel development, upgrades and ongoing work. You deal directly with me, the developer writing the code, and you'll hear back within one business day. I work from Denmark on CET, so I overlap comfortably with most of Europe.

Frequently asked questions

Does Laravel still have LTS releases?+

No. Laravel hasn't labeled a release as LTS (long-term support) since Laravel 6. Every major version now gets the same support window: 18 months of bug fixes and 2 years of security fixes. That means there's no version you can settle on for many years. Plan for one upgrade per year instead, ideally within six months of each new release.

Should I wait for Laravel 14 instead of upgrading to 13?+

No, not if you're on Laravel 12 or older. Laravel 13 gets security fixes until March 17, 2028, so you have plenty of runway. The step from 13 to 14 is also smaller once you're already on 13. And Laravel 14 is expected to require PHP 8.4, which may mean a server upgrade on top of the framework work. If you're already on 13, Laravel 14 is simply your next scheduled upgrade.

Do Laravel's first-party packages follow the same policy?+

Not quite, and their window is shorter. Laravel's support policy says that for its additional libraries, only the latest major release receives bug fixes. If you're on an older version of Cashier for billing or Horizon for queues, those need upgrading too. Include them in your version overview, because they can make an upgrade bigger than the framework itself.

Can my hosting provider keep an outdated Laravel app secure?+

Only partly. Your host can keep the server, database and PHP patched, and some Linux distributions maintain their own security fixes for older PHP versions for a while. But Laravel lives in your app's code, and your host can't patch that. A vulnerability in the framework only gets closed by upgrading the app, which is a job for a developer.

Is running an unsupported Laravel version a GDPR or NIS2 issue?+

It can be. No law bans a specific framework version, but if your app processes personal data, GDPR Article 32 requires security appropriate to the risk and the state of the art, and known unpatched vulnerabilities are hard to defend after a breach. If your business falls under NIS2, the security requirements are stricter still. Talk to a legal advisor if you're unsure about your obligations.