Filament Breezy Laravel Package

Technical Evaluation

Architecture fit

• Breezy is a Filament v4 Panel plugin (BreezyCore::make() registered via ->plugins([])), which means it sits at the same architectural layer as your panel providers — not in your domain layer. It adds Livewire page components (My Profile, 2FA challenge, passkey auth) and a TwoFactorAuthenticatable trait on the Authenticatable model.
• This is a "buy the commodity auth UX" decision. Profile editing, password rotation, TOTP + recovery codes, passkey/WebAuthn, Sanctum token management, and browser-session revocation are all non-differentiating security surface. The package consolidates ~6 screens you would otherwise hand-build and then maintain forever.
• Fit is strong if you are already on Filament v4 with a single or multi-panel setup. It is weak-to-hostile if you have an existing auth stack with its own 2FA implementation (Fortify, Google2FA, custom TOTP), because you will end up with two competing sources of truth for the second factor.
• Caveat: the description advertises "teams support," but the README documents profile, 2FA, passkeys, Sanctum tokens, and browser sessions only. Treat teams as unverified until you find it in code or changelog — that gap suggests either doc drift or a fork that has diverged from the upstream package.

Integration feasibility

• Installation is genuinely low-ceremony: composer require, php artisan breezy:install, add the plugin to the panel, add Breezy's views to your Tailwind v4 theme via @source '../../../../vendor/jeffgreco13/filament-breezy/resources/**/*', optionally publish views.
• Configuration is fluent and explicit — myProfile(shouldRegisterUserMenu:, userMenuLabel:, shouldRegisterNavigation:, navigationGroup:, hasAvatars:, slug:), passwordUpdateRules(rules:, requiresCurrentPassword:), enableTwoFactorAuthentication(force:, action:, authMiddleware:, scopeToPanel:). That is a well-designed escape-hatch surface: you can swap the profile page class (customMyProfilePage), the 2FA page, the auth middleware, the avatar upload component, and individual profile sub-components by key (personal_info, update_password, two_factor_authentication, sanctum_tokens, browser_sessions).
• Avatars are opt-in and require your own migration (avatar_url), $fillable, and HasAvatar on the User model. That is your schema change, correctly, not a package migration you inherit.
• Main feasibility cost is brownfield reconciliation: existing custom auth pages, existing profile pages, existing token UI, and any bespoke 2FA must be decommissioned in the same change, or users see duplicate/conflicting controls.

Technical risk

• Security blast radius is the dominant risk. This package owns 2FA enforcement, passkey auth, password confirmation for sensitive actions, Sanctum token issuance, and session termination. A defect here is a P1 security incident, not a UI bug. It warrants a real threat-model review, not just a smoke test.
• Enforcement footguns. scopeToPanel: true (the default) means 2FA is enforced only for that panel — other panels, and all API routes, stay unguarded unless you extend coverage. Passing authMiddleware: false silently disables enforcement unless you register MustTwoFactor yourself. force: true without a recovery communications plan produces a lockout wave on deploy.
• Override contract is fragile. The README explicitly warns that if you override getProfileFormComponents(), you must keep getCurrentPasswordComponent() in the returned array — otherwise the email-change re-authentication guard silently disappears. That is a security regression that passes code review and tests unless someone tests the exact flow.
• Filament major-version coupling. This plugin tracks Filament v4. Filament ships majors on a roughly annual cadence; a v5 will force a coordinated Filament + plugin upgrade. Because the plugin is registered inside PanelProvider, an incompatibility is a panel boot failure — high blast radius, zero graceful degradation.
• Supply chain / provenance. Composer vendor is jeffgreco13/... but the repository is Jacobtims/filament-breezy. Combined with Dependents: 0 against a badge showing substantial downloads, provenance and adoption evidence both need independent validation before you make it a dependency of an admin surface.
• Runtime dependencies implied but not stated: Sanctum for the token screen, a session driver capable of enumeration for browser sessions, WebAuthn RP-ID/HTTPS for passkeys. Missing any of these yields runtime errors or dead screens, not install-time failures.

Key questions

1. Is Jacobtims/filament-breezy the canonical upstream, a maintained mirror, or a fork? Who has commit rights, and how are security advisories disclosed?
2. What is the PHP/Laravel/Filament support matrix, and is it enforced in CI? Is there a SECURITY.md?
3. Does "teams support" exist in code, and is it documented anywhere?
4. Are the 2FA secret and recovery codes encrypted at rest, and is there an artisan-level recovery path for a locked-out user?
5. Does the browser-sessions component require the database session driver, and what does it show under Redis/file sessions?
6. Is scopeToPanel: true intentional guidance, or a default we should override in a multi-panel install?

Integration Approach

Stack fit

• Required: Laravel 11/12, PHP 8.2+, Filament v4, Livewire 3, Tailwind v4 with a custom theme. Optional-but-expected: Sanctum (HasApiTokens), database sessions for browser-session management, HTTPS + configured RP ID for passkeys.
• Breezy inherits authGuard from the panel. For a multi-panel product (e.g., admin + customers), you must confirm that each guard's model extends Authenticatable, and decide deliberately whether 2FA is scoped per panel or global.

Migration path

1. Spike in a disposable branch: install, publish config, run one panel with defaults, and exercise every screen — password change, 2FA enroll/verify/recover, passkey register/authenticate, token create/revoke, session logout-others, and the email-change re-auth guard.
2. Inventory existing auth surface and write a decommission list. Any second 2FA implementation must be removed in the same release to avoid credential drift.
3. Add the TwoFactorAuthenticatable trait and the avatar_url migration as a forward-only, nullable migration; backfill nothing.
4. Wrap all Breezy config in a single BreezyConfig service provider or config class so every setting is reviewable in one diff and portable if you ever replace the package.

Compatibility

• Highest-risk compatibility axis is the Filament major. Pin the plugin and Filament together in composer.json, and treat Filament upgrades as joint, gated changes.
• The Tailwind @source line is a build-pipeline contract: add it, commit the theme, and add a CI check that the compiled CSS contains Breezy classes so a missing rebuild fails the build rather than shipping an unstyled profile page.
• If you publish views, you own them forever and upstream fixes stop flowing. Recommend: do not publish; use component overrides and the documented extension points instead. Reserve publishing for a specific, tracked reason.

Sequencing

• Phase 0 (1 sprint, security + spike): spike, threat model of 2FA/passkey paths, provenance validation, decision memo.
• Phase 1: My Profile page without 2FA, plus password rules aligned to your policy (Password::default()->mixedCase()->uncompromised(3)), requiresCurrentPassword: true. Ship to internal/admin panel first.
• Phase 2: 2FA optional (force: false), with recovery-code UX and a published help article.
• Phase 3: flip force: true only after user comms and after an ops recovery runbook exists; scope explicitly and consciously.
• Phase 4: passkeys opt-in (needs HTTPS/RP-ID config), then Sanctum tokens and browser sessions if and only if Sanctum and the session driver support them.
• Phase 5: remove bespoke auth code; add regression tests that assert the email-change re-auth guard and the 2FA middleware are actually active.

Operational Impact

Maintenance

• Ongoing cost is upgrade tax, not bug-fixing: expect a meaningful chunk of one sprint per Filament major, plus minor-release reviews. Subscribe to releases and advisories; the plugin touches auth, so pin exact versions and upgrade deliberately rather than on ^ ranges.
• Your own maintenance surface is the config wrapper, the User trait + columns, and any Livewire component overrides. Keep overrides to a minimum and document each one with the security invariant it must preserve.

Support

• The real recurring cost is account recovery as a helpdesk function: lost 2FA device, exhausted recovery codes, passkey-only user on a new machine, locked-out admin. This requires a written runbook and a restricted artisan/tinker path to reset a second factor — designed and audited before force: true ships.
• Second support theme: users confused by email-change re-authentication ("why is it asking for my password again?"). Pre-empt with copy in the UI.

Scaling

• Runtime overhead is negligible — these are per-request admin pages, not hot paths. No scaling concern.
• Scaling pressure is organizational: the more panels and guards you attach, the more combinations of scopeToPanel / authMiddleware you must reason about. Standardize on one pattern early.

Failure modes

Each of these needs a named owner and a rollback step; the 2FA ones need a kill switch you can flip without a code deploy.

Ramp-up

• A Filament-fluent engineer can reach a working default install in under a day and a production-grade, customized install in 1–3 days. A team new to Livewire/Filament plugins and Tailwind v4 theming should budget 1–2 weeks including the security review.
• Given the mid-range composite score (42.6) and the fact that the value here is consolidation of commodity security UX rather than differentiation, fund it as an accelerator with a security gate. The build-vs-buy math favors buy only if you accept the Filament-version coupling and can staff account recovery — otherwise hand-roll 2FA and profile on Filament primitives and keep control of the enforcement boundary.