Laravel 13: What Changed?

Prologue

Laravel 13 was officially released on March 17, 2026. This article has been updated to reflect the final release rather than the earlier preview information. Previously, the version was still under development, and some parts of this article were based on what could potentially be added. This section now includes only changes that have been officially released.

I want to consider this news from two perspectives: what it means for Laravel development as a whole (the “day-to-day” impact) and what it means for the risk/reward balance of actually upgrading an existing project. Upgrading major Laravel versions is always a tedious process, so I think the second perspective is more interesting, and most of the Laravel 13-related content I’ve seen so far only touches on the first.

This is important because most of the “Laravel 13 preview” content I’ve seen online beforehand appears to be misleading in several key points. When you’re upgrading an existing project, what really matters is knowing the practical details, not just the new features. ✨

The latest news about Laravel can be found on the framework’s blog, and issues and enhancement proposals can be reviewed on the Laravel GitHub page.


Questions I Would Ask Before Upgrading

Before I get to the features, here are some questions that I would ask myself before upgrading my production apps:

❓ “Do I need to upgrade my PHP version first?” Yes, it does, and it’s non-negotiable. Details in the next section below.

❓ “Will my existing models and jobs need to be rewritten?” Not necessarily. Laravel 13 introduces several new capabilities while allowing existing application patterns to remain in place. However, production upgrades should still be tested against the application’s dependencies, queues, integrations, and deployment environment.

❓ “Is their AI useful, or is it marketing speak?” The AI is production-ready and will not be a beta release.

❓ “Do I really wish to upgrade now, or wait?” It depends on which PHP version you’re currently using, and that will be discussed in the section below.


What Actually Shipped in Laravel 13

1. ⚙️ PHP 8.3+ is Now Required

This goes without saying. The framework from now on requires PHP 8.3 or newer (Laravel 12 was still PHP 8.2 compatible, but this version is no longer supported). If you are on PHP 8.1 or 8.2, you should consider upgrading your PHP version before attempting to upgrade Laravel.

So if you’re still on PHP 8.1 or 8.2, this right here is probably your #1 priority, not the Laravel version upgrade.

2. 🖼️ Native PHP Attributes Offer an Alternative to Property-Based Configuration

This is the largest change for developers. For the last ten years, Eloquent models were configured using protected properties:

// The old way (still works, nothing breaks)
class User extends Model
{
    protected $fillable = ['name', 'email'];
    protected $hidden = ['password'];
}

Laravel 13 provides native attribute-based configuration as an alternative and covers over 15 places in the framework where such configuration can be used. These are Eloquent models, Form Requests, API Resources, Jobs, Mailables, Listeners, Console Commands, Factories, test seeders, and others:

// The new way (optional)
#[Fillable(['name', 'email'])]
#[Hidden(['password'])]
class User extends Model
{
}

The crucial part for anyone who needs to maintain an existing app: it’s opt-in, not a replacement. Laravel team calls this release “Minimal Breaking Changes” at the application-code level; your existing property-based models do not change a thing. You can adopt attributes file by file, at whatever pace is good for your team, or not adopt at all.

There’s one thing to keep in mind before you upgrade: “Minimal Breaking Changes” means your application logic shouldn’t break, but some infrastructure defaults may still change. That said, several devs who had to update real production applications have stumbled upon what can best be described as silent changes: configuration or infrastructural defaults quietly (cache behavior, session handling) shifting without throwing a real error. Your code is not going to crash, but it’s worth diffing your config files against the new Laravel 13 stubs before you deploy, not just running composer update and assuming that everything is the same.

3. 🤖 The Laravel AI SDK Is Now Stable

Laravel 13 introduces the Laravel AI SDK as a stable first-party package (it was in beta pre-release). Two main features are worth knowing about:

  • Built-in utility classes for common AI operations like text generation, summarization, and re-ranking search results by semantic similarity
  • Semantic search support for Eloquent’s query builder, which is useful for implementing RAG (Retrieval-Augmented Generation) pipelines or recommendation systems

If you’re not building AI applications, this update won’t really affect your day-to-day development work.

4. 🧵 Queue Routing By Job Class

Laravel 13 provides an improved way to control where a job will be executed – instead of specifying queue/connection names in each job class, you may now define the routing in one place:

use Illuminate\Support\Facades\Queue;

Queue::route(ProcessPodcast::class, queue: 'podcasts', connection: 'redis');

A single location to observe and update job routing, rather than searching through all job classes that could have overridden it $queue or $connection.

5. ⏱️ Cache::touch() for TTL extension

A minor but genuinely useful addition – being able to extend the lifetime of a cache item without having to read and write its value:

// Before: read, then re-write with a new TTL
$value = Cache::get('report-summary');
Cache::put('report-summary', $value, now()->addHours(2));

// Laravel 13: just extend the TTL directly
Cache::touch('report-summary', now()->addHours(2));

Laravel 13 ships first-party support for embeddings and a similarity search query builder, but the thing is, it’s not infrastructure-free. According to Laravel’s own documentation, a vector search requires a PostgreSQL database with the pgvector extension installed, as well as the Laravel AI SDK. If you are running your app on MySQL, or haven’t provisioned a PostgreSQL image with pgvector support, this feature simply won’t be available to you:

$documents = Document::query()
    ->whereVectorSimilarTo('embedding', 'Best project management practices', minSimilarity: 0.4)
    ->limit(5)
    ->get();

What Laravel is genuinely taking away is the application-level glue code, generating embeddings, performing cosine-similarity queries by hand, and wiring up a separate vector search library. The infrastructure (PostgreSQL + pgvector) part doesn’t disappear, however, and it’s worth checking if your host doesn’t already support it before you plan on using this feature. Laravel Cloud’s managed Postgres has support for pgvector by default; a lot of shared or traditional hosting won’t.

7. 📡 Reverb’s new Database Driver

Laravel Reverb (the framework’s WebSocket server for real-time features) previously needed Redis for horizontal scaling purposes. Laravel 13 adds an alternative database driver for deployments that don’t need that level of throughput:

# .env
BROADCAST_CONNECTION=reverb
REVERB_APP_ID=your_app_id
REVERB_APP_KEY=your_app_key
REVERB_APP_SECRET=your_app_secret
REVERB_HOST=localhost
REVERB_PORT=8080
REVERB_SCHEME=http

For chat features, live notifications, or collaboration tools that don’t need the level of throughput that Redis provides, it can be a good way to remove a dependency from your stack entirely.

8. 🧹 Leaner Core

The framework has removed some older polyfills and compatibility shims from its core, which helps reduce unnecessary overhead for applications that don’t need them. Along with improvements to routing and REST resource handling (cleaner subdomain handling, more flexible resource routes) and various small utility additions like Cache::touch(), the overall theme is changes that lean into refinement rather than a complete rewrite.


Should you upgrade now? A practical decision guide

The decision to upgrade is ultimately a business decision for the team to consider. However, I can offer some guidance based on the circumstances

Your situationRecommendation
Already on PHP 8.3+ and Laravel 12Good candidate for an upgrade soon with limited risk at the application layer, but still requires due diligence
Still on PHP 8.1 or 8.2Better to upgrade PHP first and then Laravel 13
Using Laravel 11 or another older supported releaseCheck Laravel’s current support policy and plan an upgrade based on your security-support window, PHP version, dependencies, and project risk
In the middle of a sprint for a clientThere is no rush. This is not a security-related update after all

And here’s that timeline for reference based on the previously mentioned release pattern:

Laravel Support Timeline

If you are doing this for a team (rather than an individual project), this is the kind of low-priority, plan-it-properly upgrade that should be batched in a sprint planning capacity calculation, rather than slipped in on the fly.

From a project-delivery perspective, I would not treat a framework upgrade as a developer-only task. It should be planned as a controlled change with a defined scope, dependency review, testing window, rollback criteria, and stakeholder communication. The technical upgrade may be performed by developers, but the delivery risk belongs to the project as a whole.


My Laravel 13 Upgrade Checklist for Real Projects

Feature lists are easy to find: what’s more challenging to find is the sequence that I, as a person planning such an upgrade as a delivery task, would actually perform in my target production environment of actual code before proceeding. Therefore, it’s not just a composer update command

CheckWhy it mattersWhat I’d actually do
PHP runtimeLaravel 13 specifically requires PHP 8.3+Run php -v and php artisan --version on the production server, not just my local dev environment
Composer dependenciesThird-party packages can frequently have stricter requirements than Laravel itselfRun composer why-not laravel/framework 13.* and examine the changelogs of all my dependencies
Official upgrade guideLaravel’s official documentation covers all possible breaking changes, including obscure edge casesRead it in its entirety, and don’t consider summary articles (including this one) as sufficient research
Automated testsUpgrades always reveal subtle assumptions not covered by my current test suiteRun the full test suite before making any changes, and run it again after
QueuesJob routing, serialization, and retry behavior can all change in subtle but breaking waysTest delayed, failed, and retried jobs in particular
Scheduled tasksProduction deployments often have tacit assumptions about scheduler behaviorTest that your crontab entries are behaving as expected in a staging environment
IntegrationsIntegrations – Payment, email, and storage SDKs can sometimes behave unexpectedlyRun sandbox/integration tests for each external service
Staging parityThis is where theoretical “silent” changes in behavior would be revealedDeploy the actual candidate upgrade commit to my staging environment, not just a fresh install
Rollback planEvery major upgrade should have some form of rollback validation procedureHave clear success criteria defined before beginning the upgrade process
MonitoringThe true validation of an upgrade often happens 48 hours after deploymentWatch error rates, queue depths, and response latency over time

This is the sequence that I, as a developer making the upgrade as part of my job, would actually follow – and the difference between “the article said there were no breaking changes” and “I verified it for my application”.


What I Focused On in This Guide

While there is no shortage of Laravel 13 content online, much of it focuses heavily on new features without spending enough time on the practical questions a working developer faces when upgrading an existing application.

That’s why I focused this article on:

This Article
Breaking changesDistinguished from “silent” infrastructure/config changes, not just a blanket claim
PHP requirementFlagged as the actual first action item, not a footnote
Vector searchInfrastructure requirement (PostgreSQL + pgvector) stated up-front, not buried behind
Code examplesOld-vs-new side-by-side, both shown as valid
Upgrade guidanceA practical decision table plus a full pre-upgrade checklist

Final Takeaway

Laravel 13 is not a reason to upgrade simply because a new version exists. The better question is whether the upgrade creates enough technical or business value to justify the change now. For a production application, I would prioritize compatibility, testing, dependencies, deployment risk, and rollback readiness before chasing individual new features.


Frequently Asked Questions (FAQ)

Do I have to rewrite my models to use PHP Attributes?
No. Property-based configuration ($fillable, $hidden, etc.) still works as normal. Attributes are an optional, file-by-file adoption path

What is the minimum PHP version for Laravel 13?
PHP 8.3. This is a hard requirement, not a recommendation.

Is the AI SDK worth considering if I’m not building an AI product?
Not particularly. It’s completely additive and won’t touch anything you’re not touching, but it’s probably better not to learn it unless you have a specific use case.

Is this a good time to upgrade a production application?
If you are already on PHP 8.3+ and Laravel 12, the move to Laravel 13 is probably going to be a minor version upgrade, but I’d still double-check the upgrade guide, dependencies, test suite, and any application-specific integrations before deploying to production.


pmwithmizan
pmwithmizan

Scrum Master & Project Manager with 6+ years delivering software at scale across international teams. Certified ScrumMaster (CSM) with a proven record of 95% on-time delivery, 90% client satisfaction, and cycle time reductions of up to 30%. Experienced in coaching teams, scaling Agile practices, and aligning engineering delivery with business outcomes. Skilled at RAID governance, forecasting, backlog refinement, and stakeholder management. Technical foundation in PHP/JS stacks, AWS, and databases ensures clear translation of technical trade-offs into business decisions.

Leave a Reply