Filament Local Logins Laravel Package

Getting Started

better-futures-studio/filament-local-logins adds one-click "log in as" buttons to a Filament panel's login screen, aimed squarely at local development so you stop copy-pasting passwords or tinker-ing your way into a session.

1. composer require better-futures-studio/filament-local-logins --dev (dev-only is usually what you want).
2. Register the plugin on the panel(s) you want it on — typically in a PanelProvider::panel() chain, next to your other plugins.
3. Make sure you have users to click: php artisan db:seed or a factory run, then visit /admin (or your panel path) and look below the standard login form.

Where to look first: the package README for the exact registration method and any publishable config, then the plugin class itself — it's small, and reading the user query it runs tells you more than the docs about what will show up in the list.

First use case: a fresh clone, migrate --seed, open the login page, click the "admin" button, and you're in. That's the whole value proposition; everything else is configuration around which users appear.

Implementation Patterns

Gate registration by environment, not by hope. The cleanest pattern is registering the plugin only when app()->isLocal() (or an explicit LOCAL_LOGINS_ENABLED flag), so a staging deploy that shares a database with production can't hand out sessions. If the plugin exposes an authorization callback, use it as a second layer rather than instead of the env check.

Per-panel registration. Multi-panel apps (e.g. Admin and App panels) need the plugin added to each panel separately, and each panel resolves users through its own guard. If your panels use different auth guards or models, verify the buttons respect that — a button that logs you into the wrong guard is a confusing afternoon.

Seed for clickability. The buttons are only as useful as the data behind them. Seed a handful of representative accounts (super admin, plain user, a user with a specific tenant/role) so the login screen doubles as a role switcher. Sort or limit the list via the plugin's query customization so you're not scrolling 5,000 factory users.

Browser tests and demos. Because the buttons are just links/forms on the login page, they're handy hooks for Dusk/Pest browser tests: hit the button instead of driving the login form, and your test setup gets shorter. Same trick makes screen-share demos less awkward.

Styling is now build-independent (1.5.1). Since 1.5.1 the buttons render full width on Filament 5 without you adding the package's Blade views to your Tailwind @source/content globs. If you maintain a custom Filament theme, you still rebuild it for your own changes — but the package no longer needs to be in your CSS pipeline.

Gotchas and Tips

• This is a production footgun by design. There is no password check; anyone who can reach the login page can become any listed user. Treat "is the plugin registered?" as a security question, and grep your PanelProviders before every deploy. A composer require --dev plus an env guard is the belt-and-braces version.
• Upgrading to 1.5.1: if you previously added the package's vendor view path to your Tailwind config to fix the button width, that workaround is now redundant. Remove it to avoid compiling the package's classes twice, then php artisan optimize:clear and rebuild assets. If the buttons still look wrong, it's your theme, not the package.
• Stale assets are the usual culprit. Filament caches compiled CSS/JS. After upgrading, run php artisan filament:assets (or filament:upgrade) plus optimize:clear before filing a bug about layout.
• Filament version support is 3–5. The 1.5.1 release explicitly preserves native styling across all three, so the package is fine on an older panel — but keep an eye on your filament/filament constraint when you bump majors; a plugin release that fixes v5 layout doesn't guarantee v5 APIs elsewhere.
• Tenancy and guards aren't magic. If your panel is tenant-scoped, a quick-login session may land without the tenant context the rest of your app assumes. Test the click-through on a tenant panel before assuming it behaves like a real login.
• Debugging checklist when no buttons appear: plugin registered on this panel, env guard passing, at least one user matching the plugin's query, and the panel's login page not overridden by a custom view that drops the plugin's render hook.