filament-breezy, the security pages a Filament panel leaves to you

The screens a Filament panel does not give you

Filament gives an application a panel, and a panel gives it resources, tables and forms, but the account area of the application is where the framework stops and the application has to take over. filament-breezy fills that gap for Filament v4 and later, and the feature list in the README is a good inventory of what a panel operator ends up building by hand. There is a My Profile page with personal information and avatar support, an update password form, two factor authentication with recovery codes, and a password confirmation modal action for protecting sensitive operations. There is a mode that forces a user to enable two factor authentication before they can use the application at all. There is Sanctum personal access token management, so a user can create and revoke their own API tokens, and there is a screen for active browser sessions with the ability to log out the other ones. On top of that there is passkey support for passwordless authentication. The audience is a Laravel developer who has a Filament panel and needs those pages to exist, with a consistent look, without writing a resource for each one.

Two commands and one plugin registration

Installation is the shortest part of the documentation. The package is required with composer and then an artisan command runs its installer.

composer require jeffgreco13/filament-breezy
php artisan breezy:install

The plugin is then registered on a panel by adding the class to the panel's plugin() or plugins([]) method, and the configuration is a chain of calls on the object the factory returns.

use Jeffgreco13\FilamentBreezy\BreezyCore;

public function panel(Panel $panel): Panel
{
    return $panel
        ->plugins([
            BreezyCore::make()
        ])
}

There is one more step that is easy to skip and expensive to debug. Filament recommends that developers create a custom theme to support the additional Tailwind classes a plugin introduces, and after doing so the plugin's views have to be added to the theme stylesheet, normally at resources/css/filament/admin/theme.css, with a source directive pointing at the vendor directory.

@source '../../../../vendor/jeffgreco13/filament-breezy/resources/**/*';

The views can also be published and overridden, with the vendor publish command for the views tag.

php artisan vendor:publish --tag="filament-breezy-views"

The auth guard decides whose account this is

Breezy uses the authGuard that is set on the Filament panel, and you may change it as you please with the panel's authGuard method. This matters for any application with more than one kind of user, where a customer panel and an internal panel are guarded by different guards and the models behind them are different classes. The configuration in the README sets the guard on the panel provider and then registers the plugin.

class CustomersPanelProvider extends PanelProvider
{
    public function panel(Panel $panel): Panel
    {
        return $panel
            ...
            ->authGuard('customers')
            ->plugin(
                BreezyCore::make()
            )
    }
}

The documentation is explicit about the constraint that comes with this, and it is a real one. The model used in your guard must extend the Authenticatable class, otherwise the profile and session features have no user object to work with. A project that has a custom user model that does not follow the framework's base class will need to adjust that before the plugin will behave, which is worth checking early rather than after a failed profile page.

Configuring the profile page, and the password rules

The My Profile page is enabled and shaped through the myProfile method, and every option has a documented default. shouldRegisterUserMenu puts the account link in the panel user menu and defaults to true, userMenuLabel customises that link's text, shouldRegisterNavigation adds a main navigation item and defaults to false, navigationGroup sets where that item appears, hasAvatars turns on the avatar upload form and defaults to false, and slug sets the page URL, which defaults to my-profile.

BreezyCore::make()
    ->myProfile(
        shouldRegisterUserMenu: true,
        userMenuLabel: 'My Profile',
        shouldRegisterNavigation: false,
        navigationGroup: 'Settings',
        hasAvatars: false,
        slug: 'my-profile'
    )

If the page needs to look different from the default, a custom page class can be registered instead, by extending the default one and passing the class to customMyProfilePage. The password update form has its own configuration. By default it uses the default password rules defined in your Laravel project, and the validation can be replaced by passing an array of validation strings or an instance of the Password rule class from Illuminate\Validation\Rules. A team with a password policy that differs from the Laravel default therefore has one place to change it, and a team that wants to inherit the application's own policy has nothing to do.

Avatars need a column and an interface

Turning on avatars is not a flag on a form, it is a small piece of application work, and the README is precise about what is required. The users table needs a column named avatar_url, and the recommendation is to add it in a new migration rather than editing an existing one, which keeps the schema history readable.

php artisan make:migration add_avatar_url_column_to_users_table

Schema::table('users', function (Blueprint $table) {
    $table->string('avatar_url')->nullable();
});

The column has to be fillable on the user model, and the model has to implement the Filament HasAvatar contract with a getFilamentAvatarUrl method that returns the stored URL or null.

class User extends Authenticatable implements FilamentUser, HasAvatar
{
    public function getFilamentAvatarUrl(): ?string
    {
        return $this->avatar_url ? Storage::url($this->avatar_url) : null;
    }
}

The upload component itself is replaceable, either by adjusting the one Breezy provides or by returning your own FileUpload with your own disk, which is how the example moves the file to a profile-photos disk. The upstream Filament documentation on setting up user avatars is the reference for the rest.

A small JavaScript layer for the passkey flow

The plugin is a PHP package with a small front end of its own, and the package.json shows how that front end is built. The manifest is marked private, since it is not published to a registry, and it has two scripts, dev and build, that both call node bin/build.js with an optional --dev flag. The build tool is esbuild, and the one runtime dependency is @simplewebauthn/browser at version 13.3.0 or later, which is the browser side of the WebAuthn flow that passkey authentication needs. That is a useful signal about the scope of the plugin, since the passkey screens are not just server rendered forms but a browser conversation with the platform authenticator. The rest of the repository is a normal Laravel package layout, with src/ for the PHP classes, resources/ for views and assets, routes/ for the routes the plugin registers, database/ for migrations, and tests/ for the test suite. The quality tooling is visible too, with phpunit.xml.dist, phpstan.neon.dist and a phpstan-baseline.neon for static analysis.

Two release lines and a permissive licence

The default branch is 3.x, and the release history shows two lines being maintained in parallel. On 2026-08-04 the project published v3.2.8 and, a couple of minutes apart, v2.6.6, and before that v3.2.7 on 2026-07-25. Publishing a patch on the older line alongside the newer one is a deliberate signal that applications still on Filament v3 are still supported, which is the difference between a package that helps and a package that forces a framework upgrade before it can be used. The repository is not archived, and the last push was on 2026-09-11. The licence is MIT, recorded in LICENSE.md, which is permissive and appropriate for a plugin that will be installed into a commercial application. Two process documents sit alongside the changelog and are worth reading before you upgrade, SECURITY.md for the reporting process and UPGRADING.md for what changed between versions. The package is published on Packagist under the name jeffgreco13/filament-breezy, and the composer command in the installation instructions is the same name.

Editorial conclusion

filament-breezy fits a Laravel team running a Filament v4 panel that needs real account management screens, especially one that has to hand out Sanctum personal access tokens to a mobile client and wants a user to see and revoke them. It does not fit a team on Filament v3, since the plugin targets v4 and later, and it does not fit a project that wants passwordless login with no password at all, since the passkey support sits alongside passwords rather than replacing them. Verify three things first: that the model behind your panel's auth guard extends the Authenticatable class, which the documentation calls out as a requirement, that the storage column for avatars exists before you turn the avatar form on, since the component assumes an avatar_url attribute, and that your Tailwind theme sources the plugin's views, because without that the additional classes in the plugin's markup are not generated and the pages render unstyled.

Frequently asked questions

Official sources

1. Issues
2. Jacobtims/filament-breezy on GitHub
3. License: MIT
4. README
5. Releases