Jetstream Laravel Package

Technical Evaluation

Architecture fit. Jetstream is not a runtime library — it is a scaffolding generator that publishes code into the host application. composer require laravel/jetstream plus php artisan jetstream:install livewire|inertia copies controllers, actions, Livewire/Vue components, Blade views, routes, config, and tests into the app, and wires in Fortify (authentication backend), Sanctum (API tokens), and a Tailwind-based design layer. The architectural implication is significant for a TPM: after install, the code is ours. Jetstream is a build-time dependency whose output must be owned, versioned, and patched by our team, not an upstream package we upgrade in place. Fit is strongest for greenfield Laravel apps that want a credible auth/teams/2FA/token baseline in days, and weakest for brownfield apps or teams expecting managed, upgradeable dependencies.

Integration feasibility. Install is a single command with flags controlling surface area (--teams, --api, --dark, --verification, --pest, --ssr, --composer), plus migrations for teams, team invitations, two-factor columns, and personal access tokens. Two mutually exclusive stacks exist: Livewire (PHP-centric, minimal JS) and Inertia + Vue 3 + Ziggy (SPA-style, Node/Vite build). Feasibility is high on a clean Laravel 11-or-earlier app and low on an existing app with established auth, routing, or design conventions — in that case, the pragmatic path is to use Fortify directly and cherry-pick Jetstream actions/components rather than run the installer.

Technical risk. The dominant risk is lifecycle, not code quality. The README explicitly scopes the kit to "Laravel 11.x and prior" and redirects to the newer official starter kits, which is a clear signal that Jetstream is on a maintenance trajectory rather than the strategic path. That makes it a poor foundation for a multi-year product unless we accept ownership of the copied code. Secondary risks: stack lock-in (Tailwind 3-era config, Vite 4/5, Inertia 0.6.x, Livewire 3, Alpine), manual application of security fixes because patches land in the package but not in our already-published files, and a non-trivial security surface (2FA challenge flow, recovery codes, token management, team invitations by email). Dependents: 0 in the supplied metadata is a weak ecosystem signal — likely a registry artifact, but it should not be used as validation either way. MIT license removes legal risk.

Key questions.

• Is this greenfield, or are we retrofitting auth into an existing app?
• Which stack — Livewire or Inertia/Vue — matches our team's actual skills and our front-end strategy?
• Do we need Teams (multi-tenancy-lite), API tokens, 2FA, and email verification, or only a subset?
• What is our target Laravel version and support horizon — are we committing to ≤11, or do we need Laravel 12+ starter parity?
• Who owns the published code, and what is our policy for re-diffing upstream releases?
• Is SSR required, and do we accept the Node/Vite operational overhead?
• Do we need SSO/SAML/OIDC (not provided) — and if so, does choosing Jetstream now create rework?

Integration Approach

Stack fit. Baseline is PHP 8.1+ on Laravel 10/11, Composer, npm, and Vite. Livewire is the lower-friction fit for a PHP-heavy team and reduces JS surface area significantly; Inertia + Vue 3 (with Ziggy for route helpers and optional SSR) fits teams with an existing SPA skill set and a Vue-oriented design system. Tailwind is mandatory to the scaffolding; the kit predates Tailwind 4 conventions, so plan on Tailwind 3 semantics or a deliberate migration. Fonts are served via bunny.net.

Migration path. Treat this as a greenfield accelerator only. For an existing application, the viable path is: install Fortify for the auth backend, add Sanctum if tokens are needed, then port Jetstream's actions and views selectively (profile update, password update, 2FA enable/confirm, session logout-other-browsers, token CRUD, team invitations). A useful tactic is generating Jetstream in a throwaway reference app and diffing against our codebase to lift only what we need. Do not attempt to run the installer over an app with existing auth routes, layouts, or migrations without an isolated branch and a rollback plan.

Compatibility. Pin exact versions in composer.json and package.json and validate a matrix (Laravel 10 and 11, PHP 8.2/8.3, Node LTS, Livewire 3, Inertia 0.6.x, Tailwind 3, Vite 4/5, CommonMark 1/2). Known breakage axes historically: Vite majors, Tailwind majors, Livewire majors, Inertia/Ziggy coordination, and PHP 8 type strictness. Anything relying on Laravel 12+ conventions should be assumed unsupported.

Sequencing.

1. Spike: fresh Laravel app, install both stacks in branches, compare against our skill profile and design system.
2. Decide feature flags up front (--teams, --api, --verification, --ssr) — retrofitting these later is more expensive than scoping them now.
3. Establish auth baseline via Fortify config and confirm 2FA, recovery codes, and email verification behavior end to end.
4. Model Teams and invitations if enabled; validate email uniqueness and invitation lifecycle edge cases.
5. Add Sanctum token management only if required; confirm token scoping and revocation UX.
6. Rebrand: Tailwind theme, component overrides, translation strings, layout shells.
7. Wire CI around the shipped Pest 2 suite and extend it for our customizations.
8. Freeze the scaffold, tag a baseline commit, and document ownership plus the re-diff process against future upstream patch releases.

Operational Impact

Maintenance. The primary operational cost is code ownership. Upstream patches (v3.x has been steady, largely small correctness fixes: 2FA page reload, team-change visibility, provider registration, unused imports) will not flow to us automatically. We need a standing process — quarterly re-diff against upstream, plus reactive pulls for security-relevant Fortify/Sanctum fixes — and a named owner. Given the README's explicit redirection to the newer starter kits, budget for a future replatform evaluation rather than assuming indefinite upstream support.

Support. MIT-licensed OSS with no vendor SLA. Support is community plus the maintainers' release cadence; the changelog shows a maintainer-heavy cadence with occasional contributor fixes. Internal capability is the real support model: at least one engineer must be able to reason about Fortify's authentication pipeline, 2FA challenge handling, and Sanctum token semantics.

Scaling. Jetstream is application-layer, so it does not constrain horizontal scaling directly, but several components carry scale-relevant edges: the database session table used for "logout other browsers," Sanctum personal access tokens (one row per token, revocation paths), profile photo storage disk (default local — move to S3 for multi-instance deployments), team invitation emails (queue them), and Inertia SSR as an optional perf lever. Watch for N+1s around team membership and current-team resolution as team counts grow.

Failure modes.

• Lifecycle drift: the package stops tracking current Laravel, leaving us on an aging foundation with no clean upgrade path.
• Patch drift: security fixes land upstream but never reach our published files.
• Stack upgrade collisions: Tailwind 3→4, Vite major, or Livewire 2→3 breaking scaffolded components.
• Auth regressions in high-risk flows — 2FA challenge, team invitations, current-team switching — which the changelog history shows are recurring fix areas.
• Brownfield installer damage: overwritten routes, layouts, or migrations.
• Skill concentration: a single engineer owns auth, creating a bus-factor risk.

Ramp-up. Low calendar cost for Laravel-fluent engineers (one to three days to a working install with tests passing), but the effective surface is broad — Fortify, Sanctum, Tailwind, Alpine, and either Livewire or Inertia/Vue/Ziggy. The shipped Pest suite and official docs reduce onboarding friction. Recommended guardrails: run the spike before committing, document the deviation log from stock scaffolding, and treat the auth flows as owned product surface requiring review, not generated boilerplate.