Why are Laravel Breeze and Jetstream no longer the recommended starting point for a Laravel 13 app, and how do the current kits differ?
answer
- READMEs: for Laravel 11.x and prior
- breeze:install stubs vs whole projects
- Jetstream stayed a runtime package
- Inertia 2 and Livewire 3 with Volt
- Fortify everywhere now
basics
~20 sBreeze and Jetstream are marked as starter kits for Laravel 11.x and earlier. Laravel 13's kits are whole Inertia 3 or Livewire 4 applications with TypeScript, shadcn or Flux UI and Fortify auth, created by laravel new instead of an install command.
solid answer
~50 sBoth packages' READMEs now say they are for Laravel 11.x and prior, and the 13.x docs have no page for either. **Breeze** was a package whose `breeze:install` command copied stubs (Blade, Livewire with Volt, React or Vue on Inertia 2 with Ziggy, or an API stack) into an existing app, with its own auth controllers. **Jetstream** ran `jetstream:install inertia|livewire` but stayed a runtime dependency: routes loaded from the package, `HasTeams` on your `User`, optional teams and API tokens. The current kits are separate Composer projects you create with `laravel new`: Inertia 3 kits for React, Vue and Svelte with TypeScript and shadcn, or a Livewire 4 kit with Flux UI, all with authentication through Fortify, and teams or WorkOS AuthKit as installer variants. Breeze and Jetstream still install on Laravel 13, but they scaffold the older Inertia 2 and Livewire 3 stacks.
code
bash · 6 lines# superseded (Laravel 11 and earlier)
composer require laravel/breeze
php artisan breeze:install react
# current (Laravel 12 and 13)
laravel new hr-portal --reactgo deeper
Know that Breeze and Jetstream belong to Laravel 11 and earlier, and that new apps start from the React, Vue, Svelte or Livewire kit.
Contrast install-command stubs and Jetstream's runtime package with whole-project kits, and name the stacks each one pins.
Explain why reaching for Breeze on a new app is a trap: Inertia 2 or Livewire 3 with Volt on day one, and no Fortify.
Frame kit generations as a signal of where the ecosystem invests, and keep existing Breeze or Jetstream apps as they are rather than rebuilding them.
## The short history For several years a new Laravel app got its login screens from one of two first-party packages: - **Laravel Breeze** — a minimal kit. You required the package, ran `php artisan breeze:install {stack}`, and it copied controllers, views and routes into your app. Stacks were `blade`, `livewire`, `livewire-functional`, `react`, `vue` and `api`. - **Laravel Jetstream** — a fuller kit with profile management, optional **teams**, API tokens and two-factor authentication, installed with `php artisan jetstream:install inertia` or `livewire`, plus flags such as `--teams`, `--api`, `--verification` and `--dark`. Both repositories now open with the same line: *"This starter kit is for Laravel 11.x and prior."* The 13.x documentation has no Breeze or Jetstream page; its starter-kits page describes only the React, Vue, Svelte and Livewire kits. ## How the old kits worked | | Breeze | Jetstream | |---|---|---| | Delivery | package + `breeze:install` copying stubs | package + `jetstream:install`, staying a runtime dependency | | Auth backend | its own controllers, e.g. `AuthenticatedSessionController`, copied into the app | Fortify, driven through Jetstream's actions | | Front ends | Blade, Livewire 3 with Volt, Inertia 2 with React or Vue (plus Ziggy for route names) | Livewire 3, or Inertia 2 with Vue (plus Ziggy) | | Teams | none | built into the package: `HasTeams` trait, team models, invitations | | Upgrades | nothing to upgrade after install | `composer update` changed behaviour under you | Jetstream's split — some code in your app, the rest in `vendor` — was its main source of friction: customising a team feature meant learning which part lived where. ## How the current kits work - **Created, not installed**: `laravel new` runs `composer create-project` on the kit's own repository, so you start from a complete app rather than patching a skeleton. - **One auth backend**: every kit uses **Laravel Fortify** for login, registration, password reset, email verification, two-factor authentication and passkeys. - **Current front-end stacks**: Inertia 3 with React 19, Vue or Svelte 5, all in TypeScript with a shadcn library; or Livewire 4 with Flux UI. - **Typed routes**: the Inertia kits use Wayfinder instead of Ziggy. - **Variants instead of package features**: teams (`--teams`) and WorkOS AuthKit authentication (`--workos`) are separate branches of each kit, still delivered as code you own. - **All code local**: no kit package remains in `vendor`, unlike Jetstream. ## Can you still use Breeze on Laravel 13? Technically yes — both packages' `composer.json` still allow `illuminate/*` `^13.0`. But you would be starting a new app on the stacks they pin: Breeze's Inertia stack requires `inertiajs/inertia-laravel` `^2.0` and its Livewire stack requires Livewire 3 with Volt. You would begin a new project a major version behind on its front-end framework, and on scaffolding that no longer appears in the docs. ## What the new design changes in practice - **One repository per stack.** Instead of one package generating six stacks (Breeze) or two stacks times several flags (Jetstream), each kit is its own complete project you can read before you create it. - **Current framework majors.** The kits track Inertia 3 and Livewire 4, while Breeze and Jetstream still pin Inertia 2 and Livewire 3. - **One auth backend.** Fortify sits behind every kit, so the same routes, actions and features exist whatever the front end. - **No package-owned pieces.** Nothing like Jetstream's vendor-loaded routes or `HasTeams` trait remains; teams are generated code in the teams variant. ## Existing apps An app that started on Breeze owns its copied code and simply keeps running; there is nothing to migrate. An app on Jetstream still depends on the package and should track its supported range. Neither needs rebuilding on a new kit — the point is only that **new** projects should start from the current kits. ## Answering in an interview 1. Say they are superseded, and cite what the READMEs say. 2. Contrast delivery: install commands and a runtime package then, whole-project templates now. 3. Name the new stacks (Inertia 3 or Livewire 4, TypeScript, shadcn or Flux, Fortify). 4. Note the pitfall of installing Breeze on a new Laravel 13 app: old Inertia and Livewire majors.
- A team created a Laravel 13 app and then ran breeze:install livewire. What have they ended up with?Breeze's Livewire stack requires `livewire/livewire` 3.x and `livewire/volt`, so the new app runs Livewire 3 with Volt components and Breeze's own auth controllers — not Livewire 4, not Flux UI and not Fortify. It works, but it starts a major version behind and outside what the current docs describe.
- Where did Jetstream's teams feature go?It became a variant of each current kit: `laravel new --teams` creates the kit from its teams branch, which includes team models, invitations, team switching and routes scoped by the current team's slug, all as code in your app rather than in a package.
saying these in an interview costs you the question
- Breeze is still the recommended minimal kit for new Laravel 13 apps
- Jetstream copied all of its code into the app, just like the new kits
- Breeze used Fortify for its authentication controllers
- Breeze and Jetstream cannot be installed on Laravel 13 at all
- The new kits are installed into an existing app with php artisan breeze:install