Laravel stopped shipping security fixes for version 11 on March 12, 2026. Nothing looked different that day. Booking forms kept taking bookings and admin panels kept loading. What changed was quieter: from that date on, if someone finds a security hole in that version, the Laravel team won't patch it.
If your company paid an agency to build a customer portal in 2024, there's a fair chance it runs on Laravel 11. And if nobody on your side tracks framework versions, there's a fair chance nobody noticed. Teams that moved to version 12 aren't fully clear either. Bug fixes for Laravel 12 ended on August 13, 2026, and its security fixes run out on February 24, 2027, according to Laravel's official support policy.
That's the least glamorous trend in Laravel development right now, and it's the one most likely to cost a business money. The others are more fun to read about: AI features built into the framework, live updates without extra servers, apps that respond in a fraction of the time, and hosting that scales itself. Each of them also comes with fine print that sales pages tend to skip.
Below is what's changing and where each trend tends to break once real users show up.
First, where Laravel stands
Laravel is a PHP framework. PHP is the programming language running behind a huge share of websites. A framework is a ready-made toolkit that handles the repetitive parts of building a web app, like user logins, talking to a database, sending emails and checking form input, so developers can spend their time on the parts that make your product different.
A few numbers help explain why the trends below matter to so many businesses:
• W3Techs reported in early 2026 that PHP runs on 71.8% of websites whose server-side language it can detect. Ruby, the next closest, sat at 6.7%.
• JetBrains' State of PHP 2025 report, based on 1,720 developers who use PHP as their main language, found 64% of them use Laravel.
• The same report found 89% of those developers are on PHP 8, 56% work in small teams of two to seven people, and 58% have no plans to move to another language.
• On the AI side, 95% of PHP developers in the JetBrains survey had tried at least one AI coding assistant.
Neither source is perfect. W3Techs can't see internal tools, and JetBrains admits its own users were more likely to answer. Still, both point the same way: Laravel is the default for a very large group of PHP teams, and most of those teams are small.
That small-team detail explains most of what follows. A five-person team can't babysit servers or run a separate real-time service, and most recent Laravel changes target exactly that.
Trend 1: Yearly upgrades are now part of the budget
Laravel ships a new major version about once a year, usually in February or March. Each gets 18 months of bug fixes and two years of security fixes. Many businesses still treat upgrades as optional projects instead of routine maintenance.
Here's the current support calendar from Laravel's documentation:
Recent upgrades have been gentle. Laravel 13 was announced with no breaking changes for most apps. The main hard requirement is PHP 8.3 or newer on your server.
Laravel 11 was the bigger shake-up. It trimmed the default project down to far fewer files and moved a lot of configuration into a single startup file. Apps upgraded from older versions often kept the old layout, so two apps on the same version can look quite different inside. That affects how fast a new developer finds their way around.
Where upgrades actually get stuck
The framework is rarely the problem. The usual blockers are:
• Third-party packages that haven't released a compatible version yet. A payment library or PDF generator can hold the whole app back for weeks.
• Hosting that can't run PHP 8.3. Some shared hosting plans and older company servers lag behind.
• No automated tests. Without tests, the team has to click through the whole app by hand to check nothing broke, and that's where upgrade budgets explode.
Pro tip
Ask your developers for a one-page "upgrade readiness" note every January. It should list your current Laravel and PHP versions, any packages that block an upgrade, and a rough estimate in days. A note like that turns a scary migration into a normal line item.
Trend 2: AI features are moving inside the app itself
The headline addition in Laravel 13 was the Laravel AI SDK becoming stable. An SDK, or software development kit, is a set of ready-made building blocks. This one gives Laravel apps a standard way to generate text, create embeddings (number-based fingerprints of text that let you search by meaning instead of exact words), run AI agents, and work with audio and images.
For a business, the useful part is that the SDK is provider-agnostic. It works with OpenAI and Anthropic, and switching providers is mostly a configuration change. If one provider raises prices or has a bad month, you aren't locked in.
Common uses in business apps include summarizing support tickets, drafting replies, tagging incoming documents, searching a help center by meaning, and pulling structured data out of messy emails or PDFs.
What happens when the AI doesn't give you what you expected
This is where most AI features fall apart, and it has little to do with Laravel:
• Data gaps. A customer uploads a blurry invoice scan and the model returns an amount but no date. Your code needs to decide whether to save a half-filled record, flag it for a person, or ask the customer again. Saving it quietly is the worst option, because nobody notices until month-end.
• Conflicting signals. The AI tags a support ticket as "billing," but the customer picked "technical issue" from the dropdown. Which wins? A sensible rule is to trust what a human chose, show the AI's suggestion next to it, and track how often they disagree. If they disagree 40% of the time, either the model or your categories need work.
• Real-time decisions. If a user is waiting on a page for an AI answer, a 20-second delay feels broken. For anything slower than a couple of seconds, move the work to a background job (covered in Trend 7) and show a "working on it" state. For truly live features, stream the answer word by word so the page never looks frozen.
• Provider outages. Every AI provider has bad days. A reasonable pattern is to set a strict timeout, retry once, then fall back to a second provider or a plain non-AI response. Because the SDK makes swapping providers easy, this fallback is cheaper to build than it used to be.
Behavior under pressure
AI providers cap requests per minute. During a launch or an email blast you'll hit those caps fast, and every request past the limit fails.
The fix is to push AI calls through a queue that sends them at a controlled pace, and to cache answers that repeat. If 300 customers ask your help bot the same question about refund policy, you shouldn't pay for 300 separate AI answers. Put a spending cap in place too. A bug that loops an AI call can burn through a monthly budget overnight.
Watch out
Don't send customer data to an AI provider until you've checked what your privacy policy and contracts allow. Strip out names, emails and payment details the model doesn't need. This is a legal question as much as a technical one, and it's much easier to settle before launch.
Trend 3: AI is also changing how Laravel apps get built
There's also AI helping your developers write the product, and Laravel now has first-party tools for it.
Laravel Boost is a package that connects AI coding assistants to your actual project. It runs as an MCP server. MCP, or Model Context Protocol, is a standard way for AI tools to plug into other software and ask questions. Through Boost, an assistant can look up your database structure, read your app's error logs, and check Laravel's documentation for the exact version you're running, instead of guessing from whatever it learned during training.
That fixes a real annoyance. Assistants often suggest code for older Laravel versions because old examples fill the internet.
Boost also ships a skill that teaches assistants Laravel best practices, plus a security audit step when adding new skills. Laravel Nightwatch, the team's hosted monitoring service, added its own MCP server as well, so an assistant can pull real error details and slow-request timings from production and help trace the cause.
The upside is speed on routine work like forms, admin screens and tests. The downside is that AI-written code still needs a human who understands it. Teams getting good results treat AI output like work from a fast junior developer that always gets reviewed.
A fair question for any agency quoting on Laravel development in 2026 is how they use AI and how they review what it produces. A vague answer is a warning sign. A good answer mentions code review, automated tests, and static analysis, which is covered in Trend 9.
Trend 4: Live updates without a separate real-time service
Chat windows, live order tracking and dashboards that update without a refresh are now expected, even in plain internal tools.
Live features need a connection that stays open so the server can push updates instantly. That's what WebSockets do. For years, Laravel apps usually paid a third-party service for this.
Laravel Reverb, which launched alongside Laravel 11, is Laravel's own WebSocket server. You run it yourself, so there's no per-message fee. In Laravel 13, Reverb gained a database driver, which means small apps can run it without setting up Redis, a separate in-memory data store that bigger setups use to coordinate between servers.
The edge cases nobody demos
Live features look great on office Wi-Fi and get harder on a phone in a lift.
• Missed messages. When a phone loses signal for 30 seconds and reconnects, any updates sent during that gap are gone. The connection doesn't replay them. Your app has to handle this by fetching the latest state from the server after every reconnect. Skip this step and a warehouse screen can show an order as "packing" long after it shipped.
• Out-of-order updates. Two updates sent a split second apart can arrive in the wrong order. Include a timestamp or version number with each update and ignore anything older than what the screen already shows.
• Duplicate events. The same update can occasionally arrive twice. Design screens so showing an update twice does no harm.
At scale
Every open browser tab holds a connection to the server. A dashboard with 50 office users is trivial. A consumer app with 40,000 people watching a live auction is a different job entirely. At that size you need several Reverb servers sharing the load, and Redis to keep them in sync. The database driver is great for getting started, but it puts extra load on your main database, which is the last place you want pressure during a traffic spike.
Send small signals over the live connection ("order 1182 changed") and let the page fetch the details itself.
Trend 5: Faster response times through long-running servers
In a standard PHP setup, every time someone loads a page, the server starts the whole Laravel app from scratch, handles the request, then throws everything away. It's simple and very forgiving. A mistake in one request can't leak into the next one.
The cost is that startup work happens on every single request. Laravel Octane changes this by starting the app once and keeping it in memory, then feeding it request after request. Octane runs on top of an app server such as FrankenPHP, Swoole or RoadRunner. The JetBrains survey flagged FrankenPHP in particular as gaining real traction.
The catch with keeping things in memory
The risk is data from one request sticking around for the next. Say some code stores "the current customer" somewhere that isn't reset between requests. Under the standard setup, that's harmless. Under Octane, the next visitor might see someone else's details, which is a privacy incident.
Memory leaks are the other issue. A small leak that would vanish instantly in a normal setup builds up over thousands of requests until the server slows down or crashes. Octane handles this by restarting each worker after a set number of requests. Picking that number is a judgment call based on how your app behaves under real load.
This is why "just turn on Octane" is poor advice for an older codebase. For a new project written with Octane in mind, it's a solid choice. For a five-year-old app, budget time to audit the code first. Speed from a PHP framework only counts if the answers it serves are correct.
Pro tip
Before switching to Octane, measure where your app actually spends its time. If most of each request goes to slow database queries, Octane won't fix much. Adding an index to one table can sometimes beat a whole server change.
Trend 6: Hosting that manages itself
Hosting a Laravel app used to mean renting a server and hoping someone remembered the security updates. The Laravel team now offers three official routes.
Laravel Cloud, the newest, can pause an app with no traffic and wake it when someone visits. That's great for staging sites and internal tools used a few hours a day. For a customer-facing app, that first visit after a quiet period can be slow, so you'd usually keep production running.
Autoscaling isn't a magic shield
Automatic scaling adds more copies of your app when traffic rises. What it doesn't do is add more database. If 20 copies of your app hit one database at once, the database becomes the bottleneck, and a 21st copy only makes it worse.
Set upper limits on scaling, both for your database's sake and your bill's. A misbehaving bot scraping your site at 3 a.m. can trigger scaling you pay for. Rate limiting, which caps how many requests a single visitor can make, is the cheap first defense here, and Laravel has it built in.
Small businesses can now get hosting that used to need an operations person. The real decision is who on your side owns the account, watches the bill and gets the alert.
Trend 7: Background jobs are now standard
A queue is a waiting list for work. Instead of making a user wait while the app sends an email, resizes a photo or calls an AI model, the app drops a note on the queue and responds right away. Separate worker processes pick up the notes and do the work in the background.
Laravel has had queues for years, but almost every serious app now uses them from day one. Horizon, Laravel's dashboard for Redis-based queues, shows what's waiting, what failed and how long jobs take.
Where queues get tricky
Queues trade one problem for a set of smaller ones. Following Laravel best practices here saves a lot of late nights.
• Jobs that run twice. A worker can crash after finishing a job but before marking it done, so the job runs again. If that job charges a card, you've double-billed a customer. Jobs that touch money or send messages must be safe to repeat. Developers call this being idempotent.
• Conflicting signals from outside services. Payment providers send webhooks, automatic messages that tell your app something happened. They can arrive late, twice, or out of order. It's common for your app to show an order as "pending" while the payment provider says it's paid. The fix is to treat the provider as the source of truth for payment status and to check with it directly when the two disagree, instead of trusting whichever message arrived last.
• Jobs that fail forever. Set a sensible number of retries with a growing wait between them, and send permanently failed jobs somewhere a person will actually look.
Laravel includes a simple way to stop the same job from being queued twice at the same time. A developer marks the job as unique and tells Laravel what makes it unique:
class ChargeInvoice implements ShouldQueue, ShouldBeUnique
{
public function __construct(public Invoice $invoice) {}
public function uniqueId(): string
{
return (string) $this->invoice->id;
}
}
In plain terms, this says "only one charge job per invoice can be waiting at once." It won't stop every duplicate on its own, since the charging code should still check whether the invoice is already paid, but it removes the most common cause.
When the queue backs up
Under heavy load, the queue grows faster than workers can clear it. Customers get their confirmation email 40 minutes late and assume the order failed. Watch queue length the same way you'd watch website uptime. Split jobs into separate queues by urgency, so a big overnight report can't block password reset emails. Laravel 13 also added Cache::touch, which extends how long a cached item lives without re-fetching it, a small change that helps busy apps avoid reloading the same data over and over.
Trend 8: Passwords are slowly giving way to passkeys
Laravel 13's starter kits, the ready-made login and account screens many projects begin with, now include passkey support, and so does Fortify, the package that handles login logic behind the scenes.
A passkey lets someone sign in with their fingerprint, face scan or device PIN instead of a password. The phone or laptop holds a private key that never leaves the device, and the website only stores a public key. There's no password for attackers to steal from your database or phish from your customers.
The payoff is fewer reset tickets and hacked accounts. The edge cases need thought:
• Lost or replaced devices. If a customer's only passkey was on a phone they dropped in a river, they need another way back in. Keep a recovery path, such as email verification or backup codes, and make sure support staff know how it works.
• Shared devices. Office teams sometimes share a front-desk computer. Passkeys tied to one person's fingerprint don't fit that setup well, so you may need to keep password login for certain roles.
• Mixed adoption. Some users will switch right away and some never will. Plan to support both methods for years, not months.
The starter kits also brought back team support, so one user can belong to several organizations, a common setup in business software that used to need custom code.
Trend 9: Stricter code, more testing, fewer surprises
PHP once had a reputation for loose code. The Laravel community is a big reason that's changing.
The JetBrains 2025 survey found PHPStan, a tool that scans code for mistakes before it ever runs, in use by 36% of PHP developers. Pest, a testing tool popular in Laravel projects, reached 17%. Both keep growing.
Laravel 13 added PHP attributes in around 15 places. Attributes are small labels written directly above a piece of code that describe how it should behave, such as which database table a model uses or which fields should stay hidden from the public. The old way still works. The new way keeps settings next to the code they affect, which makes it easier for people, and AI assistants, to read.
Why should a non-developer care? Because testing and static analysis are what make every other trend in this article affordable. Upgrades are cheaper with tests. AI-written code is safer with tests. Octane is safer with static analysis. A team that follows Laravel best practices on testing can say yes to new features without dreading what they might break.
If you're comparing agencies, ask whether automated checks run before every release.
When the trends pull in different directions
Not every trend suits every business, and some of them conflict. Octane wants code written carefully for long-running memory, while a fast AI-assisted workflow can produce code nobody has checked for that. Laravel Cloud's pause-when-idle saves money but slows the first visitor. The table below is a rough starting point for sorting out what to do first.
Businesses often reach for the exciting trend and skip the dull one underneath. An AI feature built on an unsupported version, without tests, will cost more to fix later than it saved at launch.
Key takeaways
1. Check your Laravel and PHP versions today. Version 11 lost security support in March 2026, and version 12 loses it in February 2027.
2. Laravel 13 is a gentle upgrade for most apps, but your server must run PHP 8.3 or newer.
3. The Laravel AI SDK makes AI features easier to build and easier to move between providers. Plan for missing data, disagreements with user input, slow responses and outages.
4. Reverb brings live updates in-house. Always reload the latest data after a reconnect.
5. Octane speeds apps up but punishes code that leaks data between requests. Audit older apps first.
6. Managed hosting removes server chores. Someone still has to own the bill and the alerts.
7. Queued jobs that touch money must be safe to run twice.
8. Tests and static analysis are what make every other upgrade affordable.
Conclusion
Most of what's new in Laravel this year points at one goal: letting small teams ship and run apps that used to need bigger ones.
The businesses that benefit most won't be the ones that adopt everything first. They'll be the ones that keep their version current, test their code, watch their queues and add the new features one at a time with a clear reason for each. That's how Laravel development stays cheap to maintain after the launch party is over.
If you do one thing after reading this, find out which Laravel version your app runs today. Everything else on this list is easier once that answer is a number you're happy with. For a mature PHP framework with a busy yearly release cycle, staying current is the habit that pays for itself.
