Orchid: a Laravel admin panel where the panel is PHP code

Hotwire supplies the page transitions, not your code

The speed claim in the README is not about Orchid's PHP. It names the Hotwire project, and the dependency list confirms what that means: `@hotwired/turbo` at `^8.0.2` and `@hotwired/stimulus` at `^3.1.0` sit in the package's own dependencies, next to `stimulus-vite-helpers`.

The README's formulation is that transitions can be made without reloading a page and require no additional code. Read strictly, that means you inherit a single page feel without writing the JavaScript that produces it, which is the same bargain as the rest of the package: you give up markup control in exchange for not having to build the interface layer at all.

For an internal tool that trade is usually right. For a customer facing admin area where spacing, copy placement and empty states are designed decisions, it removes the handles you would normally reach for.

The frontend is a private Vite project with one script

The repository's `package.json` is marked private and carries a single script:

npm run build

which runs `vite build` through `vite` at `^8.0.0` and `laravel-vite-plugin` at `^3.0.0`. That tells you the JavaScript here is an asset pipeline for the package's own screens, not a library you install into your application. Two plugins give a hint at the audience: `vite-plugin-rtl-css` with `rtlcss` for right to left layouts, and `vite-plugin-manifest-sri` for subresource integrity on the built assets.

The layout of the package follows the same split, with Laravel conventions on one side and the panel's own resources on the other:

config/
database/
routes/
src/
stubs/
resources/
public/
tests/

A long dependency list arrives with every install

The package's own dependency list is the part to read before installing. Beyond Hotwire and Bootstrap at `^5.3.8`, it includes `cropperjs`, `dropzone`, `flatpickr`, `inputmask`, `leaflet`, `quill`, `sortablejs`, `tom-select` and `@orchidsoftware/charts`, plus five CodeMirror language packages covering C++, CSS, HTML, JavaScript and Markdown, along with the CodeMirror state, view, commands and search modules.

That is a complete widget set shipped to every application that installs Orchid, whether or not your back office has a map, a chart or a rich text field. The README presents the same idea from the other side, claiming many form elements work out of the box so you do not reinvent forms.

Permissions are identity plus role membership

Access control is described in one line: permissions are based on a user's identity and corresponding role membership. That is a narrower model than a general policy engine, and it is worth being precise about what it does and does not give you.

What it gives you is the part admin panels actually spend their time on. A screen checks whether the signed in user holds a role, and the role decides what is shown. What it does not describe is field level rules, record level scoping or attribute based checks, and the README does not claim them.

For a panel whose rows all belong to one tenant, that is enough. For a back office where a support agent sees only their own tickets, the row filtering has to come from the Eloquent queries you write rather than from the permission layer.

Filtering, sorting and search are delegated, not built

Three of the listed features hand the hard part to something else, and each delegation has a consequence.

Filtering and sorting of table data use an Eloquent based approach, so the queries stay in the Laravel layer you already know rather than in a new query language. Full-text search is described as Laravel Scout based and global, covering all available content with results shown almost instantly. That makes the search engine whatever Scout is configured against, not something the package bundles, so search quality and search availability become your infrastructure decision.

Notifications are the third delegation, described only as various types that keep users informed. The README links documentation for the alert types rather than enumerating them here, which means choosing among them is a documentation task.

Master is ahead of the newest tag by months

The release history is short and uneven:

| Version | Published | | --- | --- | | 14.53.0 | 2026-03-21 | | 14.52.5 | 2025-12-01 | | 14.52.4 | 2025-08-13 |

Two patch releases in 2025, then a minor bump in March 2026, while the last push to the repository is dated 2026-10-22. That gap matters in a specific way: the default branch is receiving commits that no tag covers, so installing from a release and tracking the branch are two different experiences of the same project.

The version numbering is also worth noting. At 14.x the package has crossed a double digit major line many times, which means the upgrade notes in `CHANGELOG.md` are the thing to read rather than the version number itself.

Five separate configs guard the codebase

The top level of the repository shows how the project is checked, and there is a config file for each kind of check rather than one combined setup:

psalm.xml
pint.json
phpunit.xml
_typos.toml
.prettierrc
CHANGELOG.md

Psalm handles static analysis on the PHP side, Pint is Laravel's code style fixer, PHPUnit runs the suite in `tests/`, and `_typos.toml` guards against spelling mistakes in source and prose. Prettier covers the JavaScript and stylesheets with its own ignore file. So a contributor runs a PHP formatter, a static analyser, a test runner, a JavaScript formatter and a typos check, which is a heavier local setup than a single lint command.

The `stubs/` directory is the publishing counterpart: it holds what gets copied into an application, which is why the repository carries both `src/` and `stubs/` for the same package.

The repository carries no install command

There is no `composer require` line in the README and no quick start to copy. Installation is a documentation task: the README points at the quick start guide on orchid.software, and the package is published on Packagist as `orchid/platform`.

That has a knock on effect for anyone reading the repository as documentation. Requirements are not stated in prose, so which Laravel and PHP versions are supported cannot be answered from the source, and neither can the migration path when the panel's schema changes. The README also documents no upgrade procedure and no rollback for a version bump.

What it does state is the licensing and funding position: the MIT license covers Orchid, and thanks to backer support it is available for both private and commercial purposes, free of charge, with voluntary donations arranged through OpenCollective.

Editorial conclusion

Orchid fits a Laravel team whose back office is CRUD with roles, forms and tables, and who would rather not maintain Blade templates and a frontend build for internal screens. It does not fit a product where the admin interface is a designed, bespoke surface, because the panel is generated rather than styled by you. Check two things before installing: which Laravel and PHP versions your application already runs, since the README states none and only the documentation site covers requirements, and whether the widget set the package pulls in, from CodeMirror to Leaflet, matches what your panels actually need.

Frequently asked questions

Official sources

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