Every March, Laravel ships a new major version, and every March the same question lands in team Slack channels: do we upgrade now, or wait for the dust to settle? Laravel 13, released on March 17, 2026, makes that decision easier than usual — it’s one of the few major releases where the framework team deliberately optimized for zero breaking changes rather than headline features. I’ve now run this upgrade on several production codebases, and this article covers what actually changed, what the real performance numbers look like, and where the upgrade can still bite you if you skip the fine print.
The Big Picture: A Maintenance Release With Teeth
Laravel 13 isn’t a rewrite. Compared to the jump from Laravel 10 to 11, which restructured the entire application skeleton, this release reads more like a disciplined cleanup pass: raise the PHP floor, formalize a few APIs that had been half-baked in Laravel 12, and ship one genuinely new capability — a production-stable, first-party AI SDK. If you’re expecting a flashy changelog, you won’t find one. If you’re running a business on top of Laravel, that restraint is exactly what makes this release worth taking seriously.
PHP 8.3 Is Now Mandatory — And That’s the Point
Laravel 13 drops support for PHP 8.2 and requires PHP 8.3 as a minimum. On the surface this looks like a routine dependency bump. In practice, it’s a forcing function. PHP 8.1 reached end of life in late 2025, and a meaningful share of Laravel 12 installations were still quietly running on it. Framework upgrades that raise the PHP floor are, whether teams like it or not, one of the more reliable ways security debt actually gets paid down across the ecosystem.
The performance side isn’t cosmetic either. Independent 2026 benchmarks put Laravel 13 on PHP 8.3 at roughly 445 requests per second on typical API endpoints — a real, if modest, gain over the previous version, driven mostly by PHP 8.3’s JIT compiler improvements and typed class constants rather than anything Laravel-specific. Where the framework itself contributes directly is prepared statement caching in the query builder: repeated queries with the same structure but different bindings now reuse the same prepared statement handle instead of re-preparing it, which shows up as a 15–25% improvement on read-heavy workloads against MySQL 8.x and PostgreSQL 16+. If your application does a lot of repetitive Eloquent queries — paginated listings, dashboards, report generation — this is the change that will actually move your response-time graphs.
Before you touch composer.json: upgrade the PHP runtime on your server first. Running composer update against a Laravel 13 constraint while your server still serves PHP 8.2 will fail with a dependency resolution error, not a helpful message about PHP versions. Get the runtime sorted, verify with php -v, and only then touch the framework dependencies.
What’s Actually New
A Production-Stable AI SDK
The single feature getting the most attention is the Laravel AI SDK graduating from beta to a stable, first-party package. It gives you one provider-agnostic interface for text generation, tool-calling agents, image generation, and embeddings, working with OpenAI and Anthropic out of the box. Switching providers is a configuration change, not a rewrite — the SDK normalizes retry logic and error handling behind a consistent API. For teams that were previously stitching together separate SDKs and writing their own retry wrappers, this removes a chunk of glue code that added no business value.
Reverb Gets a Database Driver
Laravel Reverb, the first-party WebSocket server, now supports horizontal scaling through a database driver instead of requiring Redis. That’s a meaningful simplification for small-to-mid-size applications that wanted real-time features but didn’t want to add Redis purely for pub/sub. It’s worth being honest about the limits here: for high-throughput applications juggling thousands of concurrent WebSocket connections, Redis is still the better-tested option. Treat the database driver as a way to reduce infrastructure complexity for moderate workloads, not a universal Redis replacement.
PHP Attributes as an Alternative to Class Properties
Laravel 13 introduces first-class support for PHP attributes across more than 15 locations in the framework — models, controllers, jobs, listeners, mailables, notifications, and commands. Instead of scattering $table, $fillable, and $hidden across a model as properties, you can declare them compactly as attributes at the top of the class:
php
#[Table('users', key: 'user_id', incrementing: false)]
class User extends Model
{
// ...
}
This is additive, not a replacement — existing property-based configuration keeps working. It’s a nice-to-have for new code, and not something worth retrofitting across an entire legacy codebase just because it exists.
Typed Configuration Retrieval
One of the more quietly useful additions: you can now declare the expected type when reading config values, and Laravel throws a clear exception at boot if the actual value doesn’t match, instead of letting a stringly-typed "true" silently break a boolean comparison three layers deep in your code. This catches a category of bug that previously only surfaced at runtime, in a specific code path, usually in production.
Cache::touch() and Smarter Queue Routing
Cache::touch() lets you extend a cache entry’s TTL without re-fetching and rewriting the underlying data — a small method that removes a surprisingly common workaround. On the queue side, the new Queue::route() method lets you centralize which connection and queue each job class uses in a single service provider, instead of repeating that configuration on every job class or at every dispatch call site. If you’ve ever had to hunt down which of your fifteen job classes still points at the old queue name after an infrastructure change, this is the fix.
CSRF Protection Gets an Origin Check
The CSRF middleware has been renamed from VerifyCsrfToken to PreventRequestForgery and now checks the request’s Origin header in addition to the existing token. This adds a second layer of defense — the kind of change that’s invisible when everything works and immediately noticeable if you have an internal tool or webhook integration that sends requests without a proper origin header.
What Actually Breaks (Read This Before You Upgrade)
Laravel 13 is billed as close to zero breaking changes for most applications, and for typical CRUD apps that’s a fair description. But «most applications» isn’t «your application,» and a few specific changes are worth checking against your codebase directly:
- Job serialization format changed. Jobs queued under Laravel 12 will fail on a Laravel 13 worker because the payload format is different. Drain your queues completely before deploying the upgrade, or run a mixed worker pool during the transition window. This is the single most common cause of silent job failures I’ve seen reported after this upgrade — and because it fails silently in some queue drivers, it’s easy to miss until customers start asking why their notification emails never arrived.
Model::paginate()now defaults to 25 items per page instead of 15. If your frontend pagination assumes exactly 15 items, this will quietly shift your UI. Pass the count explicitly (paginate(15)) wherever the number matters.- Cache and session cookie names now use hyphens instead of underscores. If anything downstream — a CDN rule, a proxy config, an old integration — hardcodes the underscore-based name, set
CACHE_PREFIXandSESSION_COOKIEexplicitly in.envto avoid surprises. - Deprecation warnings from Laravel 12 are now runtime errors. If your team suppressed deprecation notices instead of acting on them (a common shortcut under deadline pressure), those suppressed warnings are the first thing that will break after the upgrade.
A Realistic Upgrade Plan
- Confirm your server runs PHP 8.3 or later — upgrade the runtime first, independently of the framework.
- Update Livewire, Inertia, and any other first-party-adjacent packages to their latest compatible versions before touching Laravel itself.
- Run
composer update laravel/framework --with-all-dependencieson a staging environment, not production. - Drain your job queues, or switch
QUEUE_CONNECTION=synctemporarily during the deploy window if you can’t afford downtime for a full drain. - Run your test suite after each meaningful change, not once at the end. If you don’t have a test suite, treat this upgrade as the reason to start one — retrofitting tests during a major-version upgrade is painful, but doing the upgrade with zero tests is worse.
- For codebases without solid test coverage, consider Laravel Shift ($29 per upgrade). It automates 80–90% of the mechanical changes — stub updates, renamed method calls, config restructuring — and on any codebase larger than a hobby project, it pays for itself in saved hours.
Should You Upgrade Now?
If your application already runs on PHP 8.3, yes — the upgrade path from Laravel 12 is short, the breaking changes are well documented and narrow in scope, and the query-builder performance gains are free once you’re on the new version. If you’re still on PHP 8.1 or 8.2, there’s no need to panic: Laravel 12 receives bug fixes until August 13, 2026, and security fixes until February 24, 2027, which gives you a real runway to plan the runtime upgrade first rather than rushing both changes at once.
The one group that should treat this as urgent rather than optional is anyone still running an application on Laravel 10 or earlier — security support for those versions has already ended, and Laravel 13 is the sensible upgrade target rather than an intermediate stop.
FAQ
Does Laravel 13 require PHP 8.3? Yes, PHP 8.3 is the minimum supported version. Support for PHP 8.2 and earlier has been removed, so the PHP runtime needs to be upgraded before you update the framework dependency.
How much faster is Laravel 13 compared to Laravel 12? Reported benchmarks show around a 5% throughput increase on API endpoints (roughly 445 requests per second), plus a 15–25% improvement on read-heavy database workloads thanks to prepared statement caching in the query builder. Actual gains depend heavily on your specific workload.
Are there breaking changes in Laravel 13? Yes, though they’re narrower than in previous major releases. The most impactful are a changed job serialization format (requiring a queue drain before upgrading), a default pagination size change from 15 to 25 items, and cookie naming changes from underscores to hyphens.
Is the Laravel AI SDK required to use Laravel 13? No, it’s an optional first-party package. You can upgrade to Laravel 13 without touching the AI SDK at all if your application has no use for it.
Should I use Laravel Shift for the upgrade? For codebases larger than a small side project, it’s usually worth it. Shift automates most of the mechanical changes for about $29 per upgrade, which is typically far cheaper than the developer hours spent doing the same changes by hand.