Laravel Filament Starter Kit Laravel Package

Getting Started

This is a starter kit, not a library — you don't composer require it into an existing app. You bootstrap a new project from it:

laravel new my-app --using=ercogx/laravel-filament-starter-kit
# or
composer create-project ercogx/laravel-filament-starter-kit my-app

Then the three commands that get you to a working panel:

cp .env.example .env && php artisan key:generate
php artisan migrate --seed
npm install && npm run build
php artisan make:filament-user

Look first at three places, in this order:

1. app/Providers/Filament/*PanelProvider.php (or app/Filament/...) — this defines your panel ID, path (/admin by default), login, colors, and the discovery paths for resources/pages/widgets. Almost every "why is my page not showing up?" question is answered here.
2. app/Filament/Resources/ — the seeded example resource(s) are your reference implementation for v5 conventions (schemas, tables, forms).
3. database/seeders/ and .env.example — demo users, roles/permissions wiring, and any required env keys (mail, queue, filesystem) the kit expects.

First use case: log into /admin with the seeded super-admin, then generate one resource end-to-end to internalize the workflow:

php artisan make:filament-resource Post --generate --view

That single command produces the model-adjacent resource, form schema, table, and view page — the loop you'll repeat for the rest of the project.

Implementation Patterns

Generate, then strip. The kit's value is convention, not code you keep. Use make:filament-resource --generate to get a correct v5 scaffold, then delete the fields you don't need. Hand-writing a form schema from scratch on v5 is slower and more error-prone than pruning a generated one, because v5's schema API (Filament\Schemas\Schema) differs meaningfully from the older Filament\Forms\Form pattern in most tutorials you'll find.

Treat the panel provider as infrastructure, not config. Anything repeated across resources belongs here via ->resources([...]) narrowing, ->navigationGroups([...]), ->brandName(), ->colors(), and ->middleware([...]). If you're copy-pasting the same navigation group label into ten resources, move it up.

Authorization via policies, not visible(). Register policies normally (php artisan make:policy PostPolicy --model=Post) and let Filament auto-discover them; control per-action access with canViewAny, canCreate, etc. Reach for ->visible() / ->hidden() only for UI noise, never for security — those are display concerns and won't stop a direct Livewire call.

Multi-panel for admin vs. customer. The kit is laid out for a single admin panel, but the pattern scales: add a second PanelProvider (php artisan make:filament-panel app) with its own path, auth guard, and resource discovery path. Keep shared resources in app/Filament/Shared and register explicitly if you need them in both.

Widgets and relation managers as the "day two" layer. Once CRUD works, the incremental value is dashboard stats (make:filament-widget StatsOverview --stats-overview) and inline relation editing (make:filament-relation-manager PostResource tags title). Both are cheap to add and are where most admin panels actually earn their keep.

Ship through a real build step. Filament assets and your Vite bundle are separate concerns:

npm run build
php artisan filament:assets
php artisan filament:optimize   # caches components + icons in prod

Put these in your deploy script. On Forge/Vapor/Envoyer, filament:optimize in the deploy hook is what keeps panel boot times sane.

Gotchas and Tips

The version floor is the biggest risk. "Laravel 13 + Filament v5" means you're on the leading edge of both. Expect ecosystem packages (permission managers, media libraries, backup tools) to lag. Pin laravel/framework and filament/filament in composer.json rather than floating, and read the Filament upgrade guide before any minor bump — v4→v5 moved form/table APIs into schemas, and namespace churn breaks generated code silently.

You cannot retrofit this into an existing app. There is no composer require path. If you already have a Laravel app, use Filament's own installer and copy the parts of this kit you want (panel provider, theme, seeder structure) by hand.

Stale component cache is the #1 mystery bug. After adding a resource, if it doesn't appear: php artisan filament:clear-cached-components (or optimize:clear). In production, forgetting to re-run filament:optimize after deploying new resources yields 404s on routes that exist locally.

Missing storage:link and wrong APP_URL break uploads and asset URLs in ways that look like Filament bugs. Check both before debugging file upload code.

Queue-dependent notifications fail silently. Database notifications and mail from actions need a worker running; on a fresh local setup QUEUE_CONNECTION=sync hides this until deploy.

Seeder ordering matters. If the kit seeds roles before users, or users before permissions, a partial re-seed (db:seed --class=...) can leave you with a user that has no roles and an empty panel. Prefer migrate:fresh --seed locally over surgical re-seeds.

Theme customization goes through the panel's Vite theme, not by editing vendor CSS. Register a theme in the panel provider, and remember npm run build (or npm run dev) is required before color/tailwind changes appear — a class of "my changes don't show" reports that are purely build-related.

Extension points worth knowing: custom Field/Column classes for domain-specific inputs, ->authorize() closures on actions for one-off permission logic that doesn't deserve a policy method, and Filament::serving() in a service provider for anything that must run on every panel request (locale, tenant scoping, global banners).

Test the panel, not just the models. Filament ships Livewire testing helpers; a single livewire(CreatePost::class)->fillForm([...])->call('create')->assertHasNoFormErrors() catches more regressions than a stack of unit tests, and it's the fastest way to verify a policy change didn't lock admins out of their own panel.