Three major releases dropped recently. Each has a long changelog. Most of it does not matter for the average production app.
Here is what does.
Laravel 12: Starter Kits with React, Vue, and Livewire Out of the Box
Laravel 12 shipped in February 2025. The headline change is not a new auth system or a new ORM layer - it is the rebuilt application starter kits.
The new laravel new flow now lets you pick React, Vue, or Livewire as your frontend, with TypeScript support and Tailwind baked in from the first command. Inertia.js is the bridge for React and Vue kits. The workbench tooling was also rebuilt to make package development less painful.
Why this matters: Before 12, scaffolding a Laravel plus React or Vue app meant stitching together Breeze, Vite, Inertia, and TypeScript config by hand. The new starter kits collapse that into a single opinionated starting point. You spend less time configuring and more time on the actual product.
For teams already running Laravel 11, the upgrade path is minimal - Laravel 12 follows the same annual release cadence and requires PHP 8.2 or higher, same as 11.
One thing to check before upgrading: any package that depends on internal Illuminate contracts may need a version bump. Run composer outdated before you touch composer.json.
If you want a deeper look at how we wire Laravel backends to React frontends in production, see our Next.js Frontend Development service page - the patterns apply equally when Next.js replaces Inertia on the frontend.
NestJS 10: Native Bun Support and ESM Improvements
NestJS 10 landed in mid-2023, and the framework has continued shipping incremental updates on that major. The headline from v10 that actually changed day-to-day work was first-class support for Bun as a runtime, alongside improved ESM module resolution.
Why this matters: Running NestJS on Bun shortens cold start time and cuts test suite runtime - Bun's bundler and test runner are meaningfully faster than ts-node or jest in raw execution. If you run NestJS in Lambda or ECS with short-lived tasks, that matters.
ESM improvements matter because CommonJS interop in large NestJS monorepos causes subtle import ordering bugs that only surface in production builds. The v10 changes make the module graph more predictable.
What you should actually check before switching runtime: your native Node addons (sharp, bcrypt, anything with a .node binary) may not have Bun-compatible builds yet. Test the dependency tree before committing.
Also worth noting: if you are on NestJS 9 or older, the v10 migration guide is short. The breaking changes are mostly around deprecated lifecycle hooks and some HTTP adapter internals. Budget an afternoon, not a sprint.
React 19: Server Actions Move from Experiment to Stable
React 19 was released in December 2024. The one feature that changes production apps is this: Server Actions are now stable.
Server Actions let you call server-side functions directly from a React component without writing a separate API route. You annotate a function with "use server", pass it to a form or a handler, and React handles the serialization, the network call, and the state update.
Why this matters: For CRUD-heavy SaaS products, this eliminates a whole class of boilerplate. You no longer need a REST or tRPC route for every form submission. The client component stays thin; the data mutation lives on the server where it belongs.
The other notable stable addition in React 19 is the use() hook for reading promises and context inside render. Combined with Suspense, it replaces a lot of useEffect plus loading-state machinery that developers have been writing for years.
What to watch out for: Server Actions are a React primitive, but they need a framework to handle the server side - Next.js App Router, Remix, or similar. Using React 19 with a pure Vite client-side setup does not give you Server Actions. Know what layer you are actually running.
The useOptimistic hook also stabilized in 19 - pair it with a Server Action and you get instant UI feedback before the server confirms. That pattern alone removes most of the manual optimistic update code that clutters React codebases.
The Short Version
| Release | The One Thing | Action |
|---|---|---|
| Laravel 12 | New starter kits with React / Vue / Livewire + TypeScript, first-party | Rebuild scaffolding on new projects; upgrade path is low-risk |
| NestJS 10 | Native Bun runtime support + ESM fixes | Evaluate Bun for Lambda / ECS cold-start; check native addons first |
| React 19 | Server Actions stable | Adopt in App Router projects; replace boilerplate CRUD routes |
None of these require you to rewrite anything running in production today. They are additive. The upgrade calculus is: does the new primitive remove code I maintain? If yes, plan the migration. If no, stay on your current version until the next natural refactor.
For related thinking on how to pick the right Laravel patterns before you hit a scaling wall, the post on Model Observers vs Events vs Listeners in Laravel: Pick the Right Tool is worth 5 minutes of your time.
And if you are tracking what the AI tooling ecosystem is doing in parallel with these framework releases, the takes on Gemini 2.5 Pro Is Out. Here Is What Actually Changes for People Who Ship. and GPT-6 Astra Released: What Engineering Teams and Founders Actually Care About cover the same "builder's take, not press release" angle.
Frequently asked questions
For most production apps, there is no urgent reason. Laravel 12's main additions are the new starter kits, which help new projects more than existing ones. If you are starting a new project, use 12. For existing apps, wait until your next planned maintenance window, run composer outdated, check for package compatibility, and do the upgrade then. The breaking changes are minimal.
No, not in a useful way. Server Actions are a React primitive, but they require a server runtime to execute the function on. Next.js App Router is the most mature host for them today. Remix supports a similar pattern with its own action API. A plain Vite plus React setup is client-side only and cannot run Server Actions.
Run bun install in a branch copy of your project and check for failed native addon builds first - look for packages like bcrypt, sharp, or anything with node-gyp in the install output. Then run your test suite with bun test. If both pass clean, your migration risk is low. If native addons fail, check whether a pure-JS or WASM alternative exists before committing to the switch.
Enjoyed this article?
Get notified when I publish new posts on SaaS, Laravel, and remote engineering.
