Laravel Orchid: a code-driven admin panel package for Laravel

What Laravel Orchid replaces, and for whom

Every Laravel application that grows a back office ends up with the same screens: a list with filters and sorting, a create form, an edit form, a delete confirmation, a permission check, and a handful of notifications. Orchid's README calls the package an abstraction of "standard business logic" for back-office applications, admin panels, user panels and dashboards. That is the promise: you describe the screen in PHP and the package supplies the rendering, the routing glue and the interaction layer. The intended reader is a Laravel developer who is comfortable in PHP and does not want to hand-write Blade templates, CSS and JavaScript for each new table. The README is explicit that the goal is to "Focus on PHP development and don't lose time with HTML, CSS, or JavaScript." If your team is not already a Laravel team, the package has nothing to offer you, because every screen it generates is a class in your application.

The mechanism: PHP classes, Eloquent queries, Hotwire in the browser

Orchid is not a separate application you deploy next to Laravel. It is a package inside your Laravel app, and the repository layout reflects that: src/, routes/, config/, database/, resources/, stubs/ and tests/ sit alongside your own code, and the package's front-end dependencies are declared in its own package.json. The README names the pieces that do the work. Forms are built from a set of field types that ship in the package, described as supporting many form elements "out of the box." Tables get filtering and sorting through what the README calls an "Eloquent based filtering/sorting approach," which means the query is a query builder object in your class rather than a configuration array. Access control is based on "a user's identity and corresponding role membership." Search is wired to Laravel Scout, so full-text search depends on whichever Scout driver you have configured, not on Orchid itself. On the browser side the package depends on @hotwired/turbo and @hotwired/stimulus, and the README credits Hotwire for the SPA-like transitions that "can be made without reloading a page and require no additional code." That is the architectural bet: the interactivity lives in Turbo frames and Stimulus controllers shipped by the package, so you inherit its behaviour and its upgrade path rather than writing your own.

Installing Laravel Orchid and rendering a first screen

Orchid is distributed on Packagist as orchid/platform, and the README points to the quick start guide at orchid.software/en/docs/quickstart/ for the full setup. The repository does not spell out the install commands in its README, so treat the guide as the source of truth and confirm the exact steps there before running anything. The package is installed with Composer like any other Laravel dependency:

composer require orchid/platform

Because the package ships migrations, configuration and assets of its own, the next step in a typical Laravel package install is publishing those resources and running the migrations. The repository contains config/, database/ and public/ directories, which is consistent with that pattern, but the README does not list the exact artisan commands, so take them from the quick start guide rather than from guesswork. The package's own front-end build is driven by Vite, as the scripts block in package.json shows:

npm run build

That script maps to "vite build" and compiles the package's Bootstrap, Turbo, Stimulus and CodeMirror dependencies into the assets the panel loads. After installation the first real use is a screen class: a list screen that queries a model, exposes columns, and attaches filters. The README's quick start and the filtering guide at orchid.software/en/docs/quickstart-sort-filter-table/ are where the class names and method signatures live. What you should see once it is wired up is a route in your application that renders the panel layout, with the table, its sort controls and its filter controls already styled.

Where Orchid pushes back

The package owns a lot of your front end. Its package.json pulls in Bootstrap 5.3, Turbo 8, Stimulus 3, CodeMirror 6, Flatpickr, Dropzone, Quill, Tom Select, Sortable, Leaflet, Frappe Charts and Cropper, among others. If your application already has a design system, or if you are running a different CSS framework, Orchid's markup and its Sass pipeline will sit alongside yours rather than merge with it. The build also assumes Vite and the laravel-vite-plugin, and the package ships a vite.config.js of its own. Teams on an older asset pipeline face a migration before they face an admin panel. The second constraint is version coupling. Orchid releases track Laravel, and the recent releases listed for the package run from 14.52.4 in August 2025 to 14.53.0 in March 2026. A major Laravel upgrade is therefore a coordinated Orchid upgrade, and the CHANGELOG.md at the repository root is the file to read before you start. Finally, Orchid is the wrong tool when the people who own the screens are not developers. There is no evidence in the repository of a visual builder; the whole model is code-driven, which the README states plainly as its selling point and which is exactly the limitation for a non-technical admin team.

Orchid against Nova-style admin packages

The obvious alternative category is Laravel's first-party admin packages, and the difference is not cosmetic. Those packages tend to keep the front end as a Vue or React single-page application that talks to JSON endpoints, so the UI is a separate build with its own dependency tree and its own upgrade cadence. Orchid goes the other way: the README describes the transitions as coming from Hotwire, which means server-rendered HTML with Turbo intercepting navigation, and the interaction code is Stimulus controllers rather than a JavaScript framework. The practical consequence is that a screen is a PHP class returning HTML, and you debug it with Laravel's own tooling. The cost is that you are inside Orchid's layout and asset bundle, and swapping the look means working with its Sass and Vite setup. If your team is fluent in Vue and already has a component library, the SPA-style packages will feel more familiar. If your team is PHP-first and wants the admin panel to be ordinary Laravel code, Orchid's approach is the shorter path.

Version cadence, licence and the cost of staying current

Orchid is MIT licensed, and the README states that this covers private and commercial use at no charge, with voluntary donations through Open Collective. There is no dual-licence split and no paid tier described in the README, so the licence itself imposes no commercial restriction. The maintenance question is different from the licence question. The repository is not archived and the last push was on 2026-09-16, so the codebase is being touched, but the release tags are sparse: 14.52.4 in August 2025, 14.52.5 in December 2025, and 14.53.0 in March 2026. Between those tags, work lands on master, which means anyone tracking the branch is running ahead of the tagged releases. For an upgrade plan, the honest cost is threefold: read CHANGELOG.md before each bump, re-run the package's Vite build because the front-end dependencies move with it, and re-check any config file you published into config/ against the package's own copy. The repository ships pint.json and psalm.xml, so static analysis and formatting rules exist if you want to hold your own screen classes to the same standard.

Editorial conclusion

Adopt Orchid if your team already writes Laravel and wants admin screens defined in PHP classes rather than assembled in a browser, and if you accept that the package owns its own asset pipeline and layout. Do not adopt it if you need a drag-and-drop screen builder or a panel that stays out of your front-end build. Before committing, verify the install path against the quick start guide on orchid.software, check that your Laravel version is supported by release 14.53.0, and confirm which of the package's published config files you are prepared to keep in sync across upgrades.

Frequently asked questions

Official sources

1. License: MIT
2. orchidsoftware/platform on GitHub
3. Project website
4. README
5. Releases