Weave Code
Laravel Admin Laravel Package
dcat-x/laravel-admin
Laravel Admin is a full-featured admin panel toolkit for Laravel, offering CRUD scaffolding, form and grid builders, widgets, authentication, and permission management. It helps developers rapidly build data-driven backends with minimal code and a rich, extensible UI.
dcat-x/laravel-admin is a Laravel admin panel builder for creating data-driven backends with minimal boilerplate. It provides reusable form and table components to speed up common admin workflows.
- Rapid CRUD scaffolding for Laravel models
- Configurable form and grid builders
- Built-in authentication and permission support
- Extensible architecture for custom admin tools
- Laravel-friendly setup and conventions
Frequently asked questions about Laravel Admin
- How do I install dcat-x/laravel-admin in a Laravel application?
- Pull it in with Composer, then publish its config and assets and run the migrations that create the admin user, role, and permission tables. The install mechanics are trivial because it is MIT licensed and Composer distributed, but the real decision is whether your team is prepared to own the package long term. Many teams vendor it as a VCS or path repository so they can patch it directly. Verify the actual release tag, commit, and CI status before pinning, because the listed last release date is future-dated.
- Which Laravel and PHP versions does dcat-x/laravel-admin support?
- There is no clearly published CI version matrix, so check composer.json and the CI configuration in the repository before committing to it. The codebase uses declare(strict_types=1) and is governed by PHPStan level 5 plus Rector, which suggests relatively modern PHP, but that is a code-quality signal rather than a support guarantee. Assume you own Laravel and PHP version currency if you adopt the fork.
- Can I use dcat-x/laravel-admin alongside Filament, Nova, or Backpack?
- No. Running two admin frameworks in one Laravel app means duplicate auth guards, overlapping routes, conflicting asset pipelines, and two upgrade paths to maintain. dcat-x/laravel-admin is meant to be the single admin surface of a conventional or modular monolith. If you already run Filament, Nova, or Backpack, plan a migration rather than coexistence.
- How do I turn an Eloquent model into an admin CRUD screen with dcat-x/laravel-admin?
- You create a controller that implements a grid builder for listing, filtering, sorting, and row actions, and a form builder for create and edit screens. Repositories bind your Eloquent models to those builders, so a typical CRUD screen is a small amount of declarative code. You then register the route and menu entry so the screen appears in the panel navigation, and add widgets or Blade views where needed.
- How does authentication and permission handling work in the dcat-x/laravel-admin panel?
- The package ships its own admin authentication plus role and permission management backed by migrations, so the panel has a separate user model from your application users. Permission checks are enforced inside controllers, grid actions, and form fields rather than relying only on route middleware. Auth, permissions, file upload, and export are the highest-risk admin surfaces, so verify test coverage on those paths in your fork instead of assuming it exists.
- Do I need to rebuild frontend assets after upgrading dcat-x/laravel-admin?
- Yes. It uses a Laravel Mix asset pipeline, and resources/dist/ is a compiled build artifact, so any change requires running npx mix --production. Production builds must ship without sourcemaps, which turns a JavaScript regression in production into log-correlation work rather than a readable stack trace. Theme customizations such as the inherited Layer popup shade option must be applied as overrides in your own sources and rebuilt, never edited directly inside dist.
- Is dcat-x/laravel-admin actively maintained and safe to depend on?
- Treat it as an internally maintained fork rather than a vendor dependency you can lean on. It has zero dependents and very few stars, meaning no external maintainers, no community security advisory channel, and no downstream compatibility signal. Its lineage runs through dcat/laravel-admin back to encore/laravel-admin, and the merge cadence from those upstreams is unverified. The strongest positive indicator is the active quality governance, with strict types, Pint, Rector, and PHPStan level 5, which materially lowers defect risk but does not replace ownership.
- Who handles security disclosures and CVE triage for dcat-x/laravel-admin?
- There is no evidence of a public security advisory process for this fork, so assume your own security team owns CVE triage. With no dependents and a minimal community, you will not get a timely upstream patch notification. Subscribe to the dcat/laravel-admin and encore/laravel-admin upstreams, monitor your lockfile, and keep a patch path ready in your vendored copy.
- How do I write tests for admin screens built with dcat-x/laravel-admin?
- The package tests on Orchestra Testbench through Dcat\Admin\Tests\TestCase, so you can extend that base class to boot the panel in your own suite. The ongoing refactor of closures into named protected methods suggests testability gaps that already needed remediation, so test your own controllers, grid definitions, and form definitions directly rather than relying on package internals. Prioritize auth, permission, upload, and export paths, and run a clean Rector and PHPStan pass as part of CI.
- Is dcat-x/laravel-admin suitable for an API-first or SPA application?
- No. It is a server-rendered admin builder built on Blade views, Eloquent, and a compiled asset pipeline, so adding it to a headless or SPA-fronted product means accepting a second rendering stack. It fits a conventional Laravel monolith or a modular monolith that needs an internal back office for ops, CMS, or support tooling on standard LAMP or LEMP hosting. For API-first products, a separate admin client consuming your API is usually the cleaner boundary.
Weaver
How can I help you explore Laravel packages today?