Filament Breezy Laravel Package

Product Decisions This Supports

• Build vs. buy for the "account & security" surface. This package replaces what is typically 2–6 sprints of undifferentiated work — profile editing, password change with current-password re-auth, 2FA enrollment with recovery codes, passkey registration, Sanctum token CRUD, and browser session revocation. The decision it unlocks is: do we spend engineering capacity on our differentiator, or on table-stakes auth UI? For most teams the answer is the former.
• Roadmap sequencing / scope deferral. Security hardening is usually a "someday, before enterprise" epic. Adopting this collapses that epic into an install task, which lets you pull forward customer-facing features and still answer security questionnaires. It effectively converts a roadmap item into a dependency.
• Enterprise / procurement readiness. Forced 2FA (force: true), recovery codes, session management, and passkey support are the exact line items that appear in vendor security reviews and B2B RFPs. This is a sales-enablement decision as much as an engineering one: "we support 2FA and passwordless login" changes deal velocity.
• Multi-panel / multi-audience architecture. First-class authGuard support plus scopeToPanel on 2FA means one codebase can serve an internal staff panel and a separate customer panel with different auth postures — a real architectural decision point for B2B2C products, and one that's painful to retrofit later.
• Platform standardization (agency / platform-team decision). If you ship multiple Filament panels, this becomes a house standard rather than a per-project choice, which reduces per-project auth drift and review overhead.
• API strategy. Sanctum token management in the UI means you can expose a customer-facing API without building a separate token admin surface or support tooling.
• Customization depth as a decision gate. The plugin exposes concrete extension seams — myProfileComponents() to add or override, MyProfileComponent base class to extend, withoutMyProfileComponents() to remove, $sort to reorder, avatarUploadComponent() to swap, customMyProfilePage(), custom 2FA page class, custom auth middleware. That means you can commit to "buy" without committing to "never touch it," which is usually the blocker on buy decisions.

When to Consider This Package

Adopt when:

• You are on Filament v4+. This is explicitly a v4 package; v3 shops need a different answer (or an upgrade plan first).
• You need profile + security features as a panel concern, not a bespoke product surface. The value is in the pre-built Livewire components, not the underlying Laravel primitives.
• You have no dedicated identity engineer and no near-term plan to build one.
• Compliance or customer pressure makes 2FA / session management / token management a near-term requirement rather than a nice-to-have.
• You are comfortable with a two-step setup (composer + breezy:install, plugin registration, and adding Breezy's views to your Tailwind theme's @source) — small, but it touches your theme build and should be scheduled, not assumed free.
• You want a documented custom-theme step rather than pixel-perfect default styling.

Look elsewhere when:

• You need enterprise identity, not just authentication. SAML/OIDC SSO, SCIM provisioning, directory sync, and org-level policy enforcement are out of scope. If your buyer's IT department is the customer, this package is a component, not a solution.
• You need real teams/tenancy/RBAC. The package description mentions "teams support," but the v4 README documents profile, password, 2FA, passkeys, Sanctum tokens, and sessions — no team management. Treat "teams" as unverified and plan separately (you'll likely want filament-shield or your own tenancy model). This is the single biggest scope-misread risk in the package.
• You're not on Filament, or you have a headless API-first product where the auth UI is a separate frontend.
• You need audited, security-reviewed auth code. This is a convenience/integration package, not a security-hardened library with a published threat model. If you're in a regulated environment, budget internal review before exposing it externally.
• Single-maintainer concentration is unacceptable. The repository listing (Jacobtims/filament-breezy) and the package name (jeffgreco13/filament-breezy) do not match, which suggests a fork or ownership change. Combined with "0 dependents" in the metadata, that's a real diligence flag — the stars (~1k) and a 2026-08-04 release say "actively used," the dependents field says "unverified." Reconcile before committing.
• You need it to survive a maintainer going away. If that's a hard requirement, vendor it, fork it, or pick a commercial Filament auth product with support.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed add-on for our admin panel framework that delivers the security features enterprise buyers ask about — two-factor authentication, passkey/passwordless login, password policies, API tokens, and remote session logout — in days instead of a quarter. No license cost, no per-seat fee. It directly reduces friction in security reviews and lets the engineering team stay on revenue work. Risk is manageable: it's a plugin we can remove, it's open source, and it sits on top of standard Laravel auth rather than replacing it.

To engineering: Add the plugin to the panel, install, add one @source line to the theme CSS, and features become opt-in flags — myProfile(), enableTwoFactorAuthentication(force:, scopeToPanel:), passwordUpdateRules(). 2FA requires the TwoFactorAuthenticatable trait on the user model; avatars require an avatar_url column. Everything is overridable: swap the profile page class, override any of the five profile components individually, extend MyProfileComponent for custom sections, set $sort for ordering, and repoint the 2FA page or its middleware. Views are publishable as a last resort. Expect a 1–2 day spike to validate our theme build, guard configuration, and upgrade path — not a same-hour drop-in.

Caveats to raise proactively, not defensively:

1. Repo/package name mismatch and zero listed dependents — verify provenance and maintenance health before it lands in a critical path. Low blast radius if it goes wrong (it's a plugin), but do the check.
2. "Teams support" is claimed in the description and absent from the v4 docs. Don't let that phrase into a customer commitment or an internal scope estimate.
3. v4-only. If we have v3 panels, this doesn't unify them.
4. Security review still ours. Buying the UI is not buying the audit. Include a review of the 2FA and email-change-with-password-confirmation flows in our own test plan.
5. Keep the escape hatch. Publish views and prefer the override hooks over patching vendor code, so a maintainer handoff or version bump stays a config change rather than a rewrite.

Recommendation: Adopt, scoped to the panel account/security surface, contingent on resolving the provenance question and confirming no team/tenancy requirement is hiding behind the description. Treat it as a dependency with a defined exit path, not a foundation.