Breeze Multiauth Laravel Package

Product Decisions This Supports

• Whether to ship multiple personas in one app. The core product question this touches is "do admins, staff, and customers live in the same Laravel application, or do we split into separate apps/services?" This package is the cheap version of "one app": it scaffolds a second (and third) auth guard, provider, model, and login flow on top of Laravel Breeze so an admin portal can coexist with the customer app without contaminating the users table.
• Admin/back-office roadmap sequencing. If a near-term roadmap item is "internal console for support/ops," this is a low-cost way to validate the shape of that work before committing to a heavier admin framework (Filament, Nova, a separate service).
• Build vs. buy vs. borrow. It reframes the decision honestly: this is borrow, not buy. You run a generator once, it emits code into your repo, and the dependency effectively disappears. That makes the ROI calculation "hours of scaffolding saved vs. hours of review and ownership," not "license + integration + upgrade treadmill."
• Team starter-kit standardization. For an agency or platform team shipping many Laravel CRUD apps, this is a candidate seed for an internal template — a decision about convention, not about a vendor.
• Feature-level go/no-go on "multi-auth" as a requirement. It gives engineering a concrete, low-cost reference implementation to pressure-test whether the requirement is really authentication (separate identities) or just authorization (one identity, different permissions). Many "we need an admin login" asks collapse into the latter, which is a materially cheaper product decision.

When to Consider This Package

Consider it when:

• You are on a greenfield Laravel app using Breeze (Blade stack) and need a second guard in days, not weeks.
• The workload is internal tools, MVPs, prototypes, or agency client apps where a bespoke admin login is acceptable and no external IdP is in play.
• You are willing to own the generated code — read it, adapt it, and treat the package as a one-time template rather than a maintained dependency.
• Your team already knows Breeze and wants a worked example of Laravel's multi-guard wiring (providers, password brokers, auth:admin middleware, redirect behavior) rather than reverse-engineering it from docs.

Look elsewhere when:

• License and provenance matter. The repository carries a NOASSERTION license designation — legal/procurement will likely block it until clarified. Escalate before it reaches a production dependency list.
• Maintenance risk is unacceptable. Last release was February 2022 and the project has ~47 stars. Laravel and Breeze have both moved substantially since; verify compatibility against your target Laravel version before anything else, and assume no upstream fixes.
• You need real identity features: SSO/SAML, SCIM provisioning, MFA, social login, audit trails. That's an IdP (Auth0, WorkOS, Cognito, Entra) or at minimum Fortify/Jetstream territory, not a scaffold generator.
• The requirement is authorization, not authentication. If admins and customers are the same people with different permissions, use a single guard plus roles/policies (spatie/laravel-permission). Multi-guard adds session, redirect, and password-reset complexity you don't need.
• You're on Inertia/React/Vue or a non-Breeze front end — the generated views and flows won't line up.
• Multi-tenancy is on the roadmap; guard-per-tenant is a dead end you'll have to unwind.

How to Pitch It (Stakeholders)

For executives: This is a small, free code generator that shortcuts one specific piece of plumbing — letting an admin console and a customer-facing app share one Laravel codebase with separate logins. The strategic value is speed to a demo, not a platform commitment: we run it once, we own the output, and there is no runtime dependency to renew or replace. Two caveats belong in the same breath: the project is unmaintained since early 2022 and its license is undeclared, so I'd frame this as a time-boxed evaluation or internal reference implementation, not an approved production dependency. Expected saving is on the order of a few engineering days of boilerplate; the real decision it informs is whether we need separate identities at all, or just role-based permissions on a single login.

For engineering: Treat it as a scaffolding template, not a library. Generate into a branch, review every emitted file — config/auth.php guards and providers, password broker config, route middleware groups, the Authenticate redirect per guard, and session/CSRF interaction between guards — then delete the package. Confirm it runs against our Laravel and Breeze versions first, since it predates several Breeze installer changes. If it fights us for more than a day, fall back to hand-rolling the second guard using the generated output as a reference; we still come out ahead on the tricky redirect and broker details.

Recommendation: Approve a short spike. Gate any broader use on (a) a resolved license and (b) a documented decision on whether multi-guard is genuinely required versus role-based access on the existing guard.