Laravel Breeze vs Jetstream vs Fortify, Which Auth Kit in 2026

For a new Laravel app in 2026, install the official Laravel starter kit that matches your frontend (React, Vue, or Livewire) and reach for Laravel Fortify when you want auth logic with no UI attached. That answer reframes the whole Laravel Breeze vs Jetstream debate, because Laravel 12 shipped first-party starter kits that replace both Breeze and Jetstream, and neither one is receiving new development.

Most guides on this topic were written in 2022 and never revisited. They tell you to run breeze:install on a fresh project, which was solid advice then and is dated now. You probably sensed that already, which is why you are checking the Laravel auth starter question again instead of copying a three-year-old tutorial.

What follows covers what each of the three tools actually does, a side by side table, the one case where Jetstream is still the right call, why Fortify outlives both, and a short decision path you can run against your own project.

Key Takeaways

Laravel Breeze vs Jetstream vs Fortify at a glance

The three tools solve different amounts of the same problem. Breeze is scaffolding you own. Jetstream is scaffolding plus account features. Fortify is the auth backend with no opinion about your interface.

One detail matters more than any feature row. Breeze and Jetstream both publish files into your repository, so the moment you install either one, that code is yours to maintain. Fortify stays a Composer dependency, which is why it keeps shipping updates while the other two sit still.

Read that as a shape, not a scoreboard. More features is not better when you have to own every published Blade file that arrives with them.

If you would rather describe the auth flow you need and generate the routes, controllers, FormRequests, and Pest tests against your own conventions, you can Try StackMivo Now.

What Laravel Breeze actually gives you

Breeze sits at the minimal end. It publishes login, registration, password reset, email verification, and password confirmation into your app as plain controllers, routes, views, and tests.

Installing it takes about a minute.

composer require laravel/breeze --dev
php artisan breeze:install
php artisan migrate
npm install && npm run dev

The installer asks which stack you want. Blade with Alpine, Livewire, React or Vue through Inertia, or an API only variant for a separate SPA or mobile client. Everything arrives styled with Tailwind CSS.

What you get is small enough to read in one sitting, and that is the entire appeal. A LoginController you can open and change beats an abstraction you have to configure. Developers new to the framework learn Laravel's auth internals faster from Breeze than from any package.

Missing pieces matter just as much. No two factor authentication. No teams. No session management screen. No API token UI. Breeze assumes you will build those yourself, and for a single tenant internal tool that assumption usually holds.

The trade nobody mentions

Published code is unversioned code. When Laravel changes an auth convention, Breeze does not update your files, you do. Teams that installed Breeze in 2022 and never reopened the auth folder are running 2022 patterns in a 2026 app, and nothing in composer outdated will tell them.

What Laravel Jetstream adds on top

Jetstream is Fortify underneath with a full account UI on top. The Jetstream documentation is direct about the split. Fortify handles the backend auth routes and controllers, Jetstream supplies the screens.

That extra surface is where the value sits.

• Two factor authentication with recovery codes and a QR setup flow.

• Browser session management so a user can log out other devices.

• API token management built on Laravel Sanctum, with per token abilities.

• Profile management including photo upload and account deletion.

• Teams with roles, invitations, and a current team switcher, if you opt in at install time.

composer require laravel/jetstream
php artisan jetstream:install livewire --teams
php artisan migrate

Two stacks are available, Livewire with Blade or Inertia with Vue. There is no React option, which quietly disqualifies Jetstream for a lot of teams before the feature list even matters.

A three person team building a B2B reporting tool picked Jetstream in week one for the teams feature alone. It worked. Nine months later their designer delivered a house style, and the team found they now owned several dozen published Blade components that all needed reskinning, plus an invitation flow whose email templates lived in the same published tree. A feature installed in five minutes turned into a two week design migration. None of that is Jetstream's fault. It is simply what installing someone else's UI means.

Teams remains the honest reason to choose Jetstream. If you need multi tenancy with invitations shipped this month and cannot spare the time to build it, the scaffolding is right there. If you are designing multi tenancy for the long run, decide how you want a multi tenant SaaS modelled before you inherit anyone else's team schema.

Where Laravel Fortify fits

Fortify is the headless option. It registers the auth routes and controllers, then stops, leaving every view to you.

composer require laravel/fortify
php artisan fortify:install
php artisan migrate

You then tell it which views to render.

use Illuminate\Support\ServiceProvider;
use Laravel\Fortify\Fortify;

class FortifyServiceProvider extends ServiceProvider
{
    public function boot(): void
    {
        Fortify::loginView(fn () => view('auth.login'));
        Fortify::registerView(fn () => view('auth.register'));
        Fortify::twoFactorChallengeView(fn () => view('auth.two-factor-challenge'));
    }
}

Behaviour lives in two predictable places. Feature flags in config/fortify.php switch registration, password reset, email verification, and two factor on or off. Action classes in app/Actions/Fortify hold the logic for creating a user, updating a password, and resetting one, so you edit a single class instead of a controller you copied.

Three situations make Fortify the right answer. You already have a design system and refuse to inherit anyone's markup. You are authenticating a decoupled SPA or a mobile client and pair Fortify with Laravel Sanctum. Or you are retrofitting auth into an existing app where published scaffolding would collide with routes you already own.

Active maintenance is the quiet advantage. Fortify is the only one of the three still getting new development, which is why the Fortify documentation sits in the current Laravel docs while Breeze's does not. Describing the missing views and having AI code generation produce them against your existing components is usually faster than porting a starter kit's markup.

Laravel Breeze vs Jetstream in 2026, the part most guides miss

Laravel 12 introduced new official starter kits, and they are the default answer for a new application. The installer offers three.

• React with Inertia 2, TypeScript, and shadcn/ui components.

• Vue with Inertia 2, TypeScript, and shadcn-vue components.

• Livewire with Livewire 3, Flux UI free components, and optional Volt single file components.

All three ship on Tailwind CSS 4 and include the auth surface you expect, plus a settings area for profile and password. Each kit also has an optional WorkOS AuthKit variant that brings social login, passkeys, and SSO without you writing the provider integration. Laravel's starter kit docs note that WorkOS covers up to 1 million monthly active users for free, so confirm current terms before you build on it.

Starting a project is one command, and the installer prompts for the kit.

laravel new my-app

Here is the piece that changes the Laravel Breeze vs Jetstream conversation. Laravel's documentation presents these kits as the replacement for Breeze and Jetstream, and both older kits have stopped receiving new development. Breeze's documentation now lives in the Laravel 11 docs rather than the current release.

None of that breaks your application. Published files keep working, and frozen scaffolding is far less risky than a frozen runtime dependency, because the code already belongs to you. So the practical effect is narrow. Do not start new projects on Breeze or Jetstream, and do not panic about the ones already running.

How to choose your Laravel auth starter

Run this list top to bottom and stop at the first match. The Laravel Breeze vs Jetstream decision is mostly a frontend decision wearing a feature list.

1. New app, standard email and password auth, React, Vue, or Livewire frontend. Use the official starter kit for that frontend.

2. New app that needs social login, passkeys, or SSO on day one. Use the starter kit's WorkOS variant, or Fortify plus a provider you control.

3. Existing app with an established design system. Use Fortify and render your own views.

4. Mobile client or a decoupled SPA. Use Fortify with Sanctum and skip published views entirely.

5. You need a working teams and invitations UI this month. Use Jetstream with the teams option, knowing it is frozen.

6. Already shipping on Breeze. Stay put. The files are yours, they still work, and a rewrite buys you nothing.

What a migration off Breeze really involves

There is no upgrade command, and that surprises people. Both Breeze and the new kits publish files, so moving between them is a reimplementation rather than a version bump. Keep your User model, your migrations, and your feature tests, then port views and routes deliberately. If you are regenerating models and factories along the way, a pass over the php artisan make:model flags saves a surprising amount of typing.

Budget it as a real ticket. An app with customised auth views, a password policy, and a social login bolted on is a multi day job, not an afternoon.

Generating auth features instead of picking scaffolding

Every scaffolding option shares one weakness. Each gives you the same generic 80% that every other project got, and the remaining 20%, your roles, your invitation rules, your audit trail, is still hand written.

That last stretch is where StackMivo is aimed. Describe the flow in plain English, something like a two factor login with recovery codes and an audit log entry on every successful sign in, and it generates production-ready Laravel apps rather than snippets. Eloquent models and relationships, migrations, controllers, Policies, FormRequests, API Resources, Filament admin resources, and Pest tests, as standard Laravel code you can read, edit, and keep.

Two things make that useful on a live codebase. Laravel-native intelligence means the output follows framework conventions across Laravel 9, 10, 11, and 12 instead of generic PHP. Connecting GitHub, GitLab, or Bitbucket lets it index your models, routes, and business logic first, so a generated Policy references your actual roles rather than an invented enum.

You still review everything, which is the whole point of ownable code. Get started free and try it on the auth feature you have been putting off.

The verdict on Laravel Breeze vs Jetstream vs Fortify

Three tools, three jobs. Breeze hands you a small set of auth files to own. Jetstream hands you a much larger set, including teams and two factor, then expects you to maintain the UI that came with it. Fortify hands you the backend and keeps its opinions to itself, which is exactly why it is the one still moving forward.

For 2026 the Laravel Breeze vs Jetstream question largely resolves itself. New apps belong on Laravel's current starter kits, custom interfaces and API clients belong on Fortify, and Jetstream earns a look only when you need a teams UI faster than you can build one. Existing Breeze apps are fine where they are.

Pick by frontend first, then by how much account surface your users actually need. Spend the hours you saved on the part scaffolding never covers, your roles, your invitation logic, your audit trail. That is where your product actually lives, and it is the work worth doing carefully, whether you write it by hand or generate it against conventions you already trust.