Laravel · Laravel

Laravel 12 New Features — A Complete Guide

Laravel 12 was a deliberately minimal, maintenance-focused release: a refreshed set of starter kits and dependency bumps rather than new framework features. Here's what actually changed and why.

John Kihiu12 min read

Laravel ships a new major version roughly every year on a predictable calendar cadence, and not every major version is meant to be a feature release — Laravel 12 is explicitly one of the quiet ones. Taylor Otwell has been consistent about this: majors line up with the calendar and with dependency support windows, not with a backlog of breaking features that needed a version bump to land. If you were expecting a Laravel 11-sized set of changes, Laravel 12 will look thin, and that's by design rather than an oversight.

Why this was a maintenance release

Laravel's public versioning policy ties major releases to a schedule (annually, typically Q1) rather than to feature readiness, specifically so that bug fixes and security patches have a predictable window and dependencies (PHPUnit, Symfony components, PHP itself) can be bumped without waiting for a pile of new features to be ready at the same time. Laravel 12 continued that pattern: the core framework changes are narrow, and most of what shipped is version alignment — supporting the current PHP and dependency versions — rather than new APIs developers need to learn.

Check the actual upgrade guide before assuming a feature exists

Because Laravel 12's core changes were minimal, it's easy to find blog content (including AI-generated summaries) that either recycles Laravel 11 features as if they're new, or invents ones that don't exist. The authoritative source is always laravel.com/docs/12.x/upgrade — if a claimed Laravel 12 feature isn't listed there, treat it as unverified rather than repeating it.

The starter kits got the bigger overhaul

Where Laravel 12 actually invested effort was the official starter kits — the scaffolding you get from laravel new when picking an authentication/frontend stack. The Breeze/Jetstream-era starter kits were refreshed with updated React, Vue, and Livewire options, cleaner default styling, and alignment with the current versions of Inertia and Tailwind. If you're starting a new project, this is the part of Laravel 12 you'll actually notice day one — the framework core underneath is very close to Laravel 11.

Bash · new project
laravel new my-app
# prompts for a starter kit: None, React, Vue, or Livewire
# each wires up auth scaffolding, Inertia or Livewire, and Tailwind

Dependency and minimum PHP version changes

Each Laravel major typically raises the minimum supported PHP version to track PHP's own release cadence, and bumps required versions of core dependencies like Carbon and the underlying Symfony components. This is unglamorous but it's the actual mechanism that keeps the framework able to use modern PHP language features (enums, readonly properties, and so on) without an ever-growing compatibility shim layer. Check the official upgrade guide for the exact PHP floor before upgrading a production app — this is the detail most likely to actually block a `composer update` rather than any application-code change.

What upgrading from Laravel 11 looks like in practice

Given how few breaking changes there are, most existing Laravel 11 apps upgrade to 12 with a version bump in composer.json and a run through the official upgrade guide's short checklist, rather than any meaningful code migration. The bigger practical risk is third-party package compatibility — Sanctum, Horizon, Livewire, Filament, and other ecosystem packages need their own Laravel 12-compatible releases, and on a real app that's usually the long pole, not anything in Laravel core itself.

Wrapping up

Laravel 12 is best understood as Laravel sticking to its own release philosophy: majors track a calendar and a dependency-support cycle, not a feature quota. The framework core changed little; the starter kits got the real refresh. If you're planning an upgrade, budget time for third-party package compatibility rather than application code changes — that's where the actual friction lives.

John Kihiu
Acumatica ERP Developer · Laravel Engineer

Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.