Weave Code
Filament Accounts Auth Laravel Package
tomatophp/filament-accounts-auth
A Filament plugin from TomatoPHP that brings authentication to your accounts panel, with login, registration, password reset, and profile flows ready to drop into Laravel apps. Streamline user access and account management with minimal setup.
The auth package from DevDojo for Filament Account Builder.
Frequently asked questions about Filament Accounts Auth
- How do I install tomatophp/filament-accounts-auth in a Laravel app?
- Install tomatophp/filament-accounts version 5 first, then require tomatophp/filament-accounts-auth with Composer. Publish the package assets to public/auth/build as part of your deployment artifact, since assets are shipped prebuilt rather than compiled through your Vite pipeline. Your app must run PHP 8.2+, Laravel 12 or 13, Livewire 4 with Volt 1.10+, and Filament 5.
- Which Laravel, PHP, Filament and Livewire versions does this package support?
- Version 5.0.0 targets Filament 5, Livewire 4 (Volt 1.10 or newer), Laravel 12 and 13, and PHP 8.2 or later. It also depends on tomatophp/filament-accounts version 5, so that package must be installed and pinned first. Older branches exist, but the release notes only state that the 1.x line stays on the v3 branch.
- Is tomatophp/filament-accounts-auth compatible with Filament 4 or Laravel 11?
- The v5 release line is built for Filament 5 and Laravel 12 or 13, so teams still on Filament 4 and Laravel 11 have no clearly documented home. The only stated guidance is that the 1.x line remains on the v3 branch, without an explicit compatibility matrix. Confirm with the maintainer which exact framework combination that branch covers before planning an upgrade.
- Can I install it alongside devdojo/auth in the same project?
- No. The release declares a Composer conflict with devdojo/auth because both packages claim the Devdojo\Auth namespace. This package is a replacement, not a complement, so any existing install requires a clean-room swap with a hard cutover per application. Migration must be atomic rather than treated as a routine version bump.
- How do I migrate from devdojo/auth to this package?
- Start by inventorying your current auth surface: routes under /auth/*, published views and config, language files, 2FA enrollment data, and the guard and model backing it. Remove devdojo/auth along with its service provider registrations and any published views that collide with the Devdojo\Auth namespace. Then install and pin tomatophp/filament-accounts 5 followed by this package, publish assets to public/auth/build, port language strings with per-locale overrides, and re-verify your 2FA guard, account model, and existing secrets.
- Does the package store users, or does it use my existing model and guards?
- Authentication runtime is delegated to your host application's guards and account model, so the package does not own user storage. It acts as a presentation and orchestration layer over Laravel's native auth primitives, adding login, registration, password reset, 2FA, and profile pages. That boundary keeps your existing user schema and credential handling intact during adoption.
- How does two-factor authentication behave when my app has multiple guards?
- The 2FA challenge logs the user in on the accounts guard using the configured account model, so the guard and model must match your app's setup. In a multi-guard application, a misconfigured guard is a user-lockout class of failure rather than a cosmetic issue. Verify enrollment continuity and challenge flows in staging before rolling out, and raise the multi-guard resolution order with the maintainer if your setup is non-standard.
- Are the /auth/setup wizard pages safe to leave enabled in production?
- The setup wizard is intentionally separated from the runtime auth pages by an environment check plus a viewAuthSetup gate. That gate pattern is correct for a scaffold-generating UI, but you should confirm the gate is actually registered and denied by default outside local environments. Smoke-test that the setup routes return 403 or 404 in staging and production after deployment.
- Do I need to compile this package's assets with Vite?
- No. Assets are prebuilt and published to public/auth/build, which removes build-time coupling to your host application's Vite pipeline. The tradeoff is that asset provenance and freshness are managed by the package release, so re-publish the assets on every upgrade to avoid silently serving stale builds. Font fallback can partially mask an outdated build, so check the published files explicitly.
- Is the package tested and actively maintained?
- Quality signals are positive: a Pest test suite, PHPStan static analysis, and a CI matrix for Laravel 12 and 13 indicate disciplined maintenance. Coverage breadth and the PHPStan level are not published, so treat those as unverified until you review the repository. For production use, also ask the maintainer about the security-patch policy across the v5 and 1.x/v3 lines, since the 5.0.0 release was a version realignment rather than a small patch.
Weaver
How can I help you explore Laravel packages today?