Weave Code
Crud Laravel Package
orchid/crud
Orchid CRUD is a screen-based toolkit for building admin panels and CRUD interfaces in Laravel. Define screens, fields, and layouts in PHP to create customizable back-office apps with forms, filters, sorting, and actions, all within your Laravel codebase.
Build CRUD apps in fewer lines of code for Laravel Orchid.
Frequently asked questions about Crud
- How do I install orchid/crud in a Laravel application?
- Install it with Composer using composer require orchid/crud. It depends on orchid/platform, so the Orchid admin panel must also be installed and configured in the same Laravel application. You then define CRUD behavior by creating screen classes rather than hand-building controllers and Blade views. Confirm your Laravel and PHP versions meet Orchid's requirements before installing.
- Does orchid/crud support Laravel 12?
- Yes, orchid/crud 4.4.0 adds first-class Laravel 12 support, which removes the hard gate that previously kept teams on Laravel 11 for admin support. It remains a non-breaking minor over 4.3.0 with three changes. The Laravel 12 support should be treated as part of your Laravel 12 migration workstream, not as a standalone feature. Check that your orchid/platform version also supports Laravel 12, because CRUD cannot outrun its host.
- What PHP version and database drivers does orchid/crud require?
- The package targets Laravel 11 and 12 with PHP 8.2 or newer, and orchid/platform is a hard dependency. Database support follows the underlying Laravel and Orchid stack rather than being defined by CRUD itself. Validate the specific PHP version and database driver combination in your Laravel 12 target matrix before committing to a build.
- Is orchid/crud a standalone CRUD package or does it require Laravel Orchid?
- It is the screen-generation layer of Laravel Orchid, not a general-purpose CRUD library, so it sits on top of orchid/platform. It inherits Orchid's layout system, admin guard, permission model, routing, and screen lifecycle. If Orchid is already in your stack, CRUD lowers the marginal cost of each back-office entity. If Orchid is not installed, adopting CRUD really means adopting Orchid first and then CRUD.
- How do I build a CRUD screen with orchid/crud?
- You define a screen class in PHP and declare its fields, columns, filters, sorting, and actions instead of writing controller and view pairs by hand. Orchid renders the server-side Blade screens from that definition, including forms, filters, and action buttons. Authorization hooks let you gate actions and fields within the screen. This declarative approach is why each new internal admin entity costs much less than a hand-built equivalent.
- What changed in orchid/crud 4.4.0?
- Version 4.4.0 is a non-breaking minor release over 4.3.0 with three changes. It adds first-class Laravel 12 support, introduces a hide method for declarative per-role or per-state action visibility, and fixes request()->user() being null inside displayInNavigation. The navigation fix affects menus rendered without an authenticated user, including guest-reachable admin entry points, tenant-scoped navigation, and support impersonation flows. Re-test those flows after upgrading.
- Does orchid/crud's hide method replace permission checks?
- No. The hide method controls declarative per-role or per-state action visibility, but hiding is not authorizing. You must still enforce the server-side permission check so that hidden actions cannot be invoked directly. Applied without review, hide can silently over- or under-expose admin operations, so treat it as security-adjacent and review its use in access reviews.
- Can I use orchid/crud with Inertia, React, Vue, or an API-first admin?
- Orchid CRUD is a poor fit for Inertia, React, Vue, API-first, or headless-admin architectures because its entire value is generated server-rendered Blade/Orchid screens. It fits conventional internal, operator-facing tooling such as ops consoles, support dashboards, and back-office admin. If your admin roadmap is trending toward a SPA, this package is the wrong direction regardless of quality. Settle that architectural question before any build work starts.
- Is orchid/crud actively maintained and safe for production?
- It is community-maintained by a small base with irregular cadence, no commercial SLA, and no scheduled security backports, and the package shows zero dependents, which is a thin ecosystem signal. That means few external battle-tests and little downstream pressure to catch regressions, so you would be an early, self-supporting consumer. It also tracks Orchid's release cadence, so an Orchid major bump can change CRUD behavior without a CRUD version change. Keep both dependencies version-locked, name an owner accountable when Orchid ships a major, and define a fallback if upstream stalls.
- When should I choose orchid/crud and when should I avoid it?
- Choose it when Orchid is already in your stack and you need internal, operator-facing CRUD screens for ops consoles, support dashboards, or back-office admin; the value does not transfer to customer-facing or brand-differentiated surfaces. Avoid it for SPA, Inertia, React, Vue, API-first, or headless-admin architectures, where generated server-rendered screens are the wrong direction. If Orchid is not already installed, budget for two onboarding efforts, because adopting CRUD means adopting Orchid first. Also confirm that your Orchid version supports Laravel 12 before planning the work.
Weaver
How can I help you explore Laravel packages today?