Rapyd Admin writes your Laravel admin panel as plain Livewire and Blade files

An admin panel that is files in your repository

Rapyd Admin is described as an open source admin panel for Laravel, and as a light alternative to Nova, Filament and Backpack for teams building SaaS products and for development with AI agents. The phrase that explains the design is plain Livewire and Blade files that live in your codebase, with auth and multi-tenancy included, and one command to start.

The reason to build it that way is stated in the first bullet under Why Rapyd Admin: plain code, no DSL. There are no resource classes to learn, because the generators write ordinary Livewire components and Blade views into app/Modules and those are yours to edit. A unified x-rpd:: component set gives every table, form and detail page the same shape, so the pages look consistent without the framework owning your markup.

That is the whole bet of the project. An admin panel that hides your code behind an abstraction is convenient until the day a request falls outside the abstraction, and at that point you either extend the abstraction or leave. Rapyd Admin is designed so that leaving is a file copy.

The package is zofe/rapyd-admin on Packagist, the licence is MIT, the primary language is PHP, and the last push to the default branch was on 2026-10-16. The repository carries a CHANGELOG.md, a DEV.md, psalm and phpunit configuration, a php-cs-fixer setup, an evals directory and a docs folder, which describes it as a project with a working process rather than a script collection.

One setup command creates the admin and the first user

The quick start is short because the package does the setup work.

composer create-project laravel/laravel myapp && cd myapp
composer require zofe/rapyd-admin:^9 -W
php artisan rpd:make:setup     # .env, database, configs, migrations, admin user, home page
php artisan serve

The requirements are PHP 8.2 or newer, Laravel 12 or 13, and Livewire 4.

What rpd:make:setup does is listed in the comment: it writes the environment file, sets up the database, writes the configs, runs the migrations, creates an admin user and a home page. The created admin is admin@laravel and the command prints a random password once, so you log in with it and change it. If you would rather choose the password yourself, set RAPYD_ADMIN_PASSWORD in the .env file before running the command.

After that you get a sidebar with Users, Companies, Roles and Permissions and Logs, a landing page, and an app/Modules folder that is ready for your own modules.

Two details in the notes are worth reading before you copy the command. The -W flag lets Composer downgrade Guzzle to 7 on Laravel 13, because laravel/socialite still requires that version through league/oauth1-client. And Google sign-in appears on the login page as soon as GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET are set, with the details in docs/AUTH.md.

Seven bundled modules, all optional

The What's included table lists seven modules, and the second bullet in the Why section says they are all bundled and all optional.

Auth covers Fortify login, registration, password reset, email verification and 2FA, plus Google sign-in, pages for users, roles and permissions, and impersonation. Companies provides the multi-tenant company hierarchy of one to three tiers, an owner and member role, and data scoping through the Limit and Authorize pieces.

Addresses attaches postal addresses to any model with an embeddable editor. Workflow puts Symfony Workflow state machines on your models, with transition buttons and history embeds. Log is an application log viewer with error analysis by AI, alongside an activity log of what users did. Search puts a global search box in the navbar across the models you configure. Layout is the Bootstrap 5.3 admin shell with sidebar, topbar and dark mode, and the README calls it the reference theme.

The pattern to notice is that each module is a self-contained folder with its own Livewire components, views, model, authorizations, limits, config and routes. That is what makes the eject command work.

Nothing is hidden behind a service container of services. The configuration file inside a module holds the layout, the menu entry and the permissions, and the README notes that the view and edit permissions for a module are given to the operator role.

Your first module: a command, a folder, and a model

Generating a module is one Artisan command:

php artisan rpd:make Articles Article --module=Blog --fields="title,body:text,published_at:datetime"

The README says it creates app/Modules/Blog with a table, a detail page and a form for Article, its routes and a sidebar entry, and that when the model does not exist yet it is created with its migration from the fields you passed and then migrated. There are no prompts.

The resulting tree is worth reading because it shows what the framework considers a module:

app/Modules/Blog/
├── Livewire/ArticlesTable.php   ArticlesView.php   ArticlesEdit.php   (authorization and scoping built in)
├── Views/articles_table.blade.php   articles_view.blade.php   articles_edit.blade.php   menu.blade.php
├── Models/Article.php           uuid key, ShortId
├── Authorizations/ArticleAuth.php   Limits/ArticleLimit.php   record check and data scoping, yours to restrict
├── config.php                   layout, menu entry, permissions (view / edit articles, given to operator)
└── routes.php                   behind auth

The views stay short because the components do the work:

<x-rpd::table title="Articles" :items="$items">
    <x-slot name="filters">
        <x-rpd::input col="col-8" model="search" placeholder="search..." />
    </x-slot>
    <table class="table">
        <thead><tr><th><x-rpd::sort model="id" label="id" /></th><th>title</th></tr></thead>
        <tbody>
        @foreach ($items as $article)
            <tr><td>{{ $article->id }}</td><td>{{ $article->title }}</td></tr>
        @endforeach
        </tbody>
    </table>
</x-rpd::table>

And the edit form is two components:

<x-rpd::edit title="Article">
    <x-rpd::input model="article.title" label="Title" />
    <x-rpd::rich-text model="article.body" label="Body" />
</x-rpd::edit>

The rich text field is one of several third-party front-end pieces the package pulls in: the repository's package.json lists Quill for rich text, tom-select for selects, bootstrap-modbox for dialogs and livewire-sortable for ordering, alongside Bootstrap 5.3, Bootstrap icons, Sass and Vite.

Colours from .env, a different shell from a theme

Customisation is split into three levels, and the first one has no build step at all.

Colours come from environment variables, and the README notes that the values have to be quoted because an unquoted # starts a comment:

RAPYD_PRIMARY="#6a1c9a"        # buttons, links, active items
RAPYD_SIDEBAR_BG="#1e293b"     # optional: sidebar, topbar and content backgrounds
RAPYD_SIDEBAR_TEXT="#f8fafc"

Branding is next: RAPYD_BRAND, RAPYD_LOGO_SIDEBAR, RAPYD_LOGO_LOGIN, RAPYD_FAVICON and RAPYD_CUSTOM_CSS. RAPYD_THEME activates an installed theme, and RAPYD_THEME_SWITCH=true lets each visitor pick one from the navbar.

A whole different look is a theme as well, described as a folder of Blade layouts plus compiled assets. You can start from any Bootstrap 5 template, follow the contract in docs/THEMES.md, and check your result with php artisan rpd:theme:check. A ready made option is zofe/theme-tabler, based on the Tabler template, installed with composer require zofe/theme-tabler and selected with RAPYD_THEME=tabler.

Then there are the two escape hatches. For a single view you publish it to resources/views/vendor/rpd for components or resources/views/vendor/layout for layouts and edit the copy. For an entire module, php artisan rpd:eject Auth copies it into your application so you can change it deeply.

That progression, from environment variable to published view to ejected module, is the design of the package in miniature: it tries to make the easy path free and the hard path possible.

rpd:context and Laravel Boost are the agent story

Two of the three bullets under Why Rapyd Admin are about how the package is meant to be worked on, and the agent one is the most specific.

Agent-friendly means flat, self-contained module folders with consistent naming, a command that briefs an agent, and a verification loop the agent can run by itself. The brief command is:

php artisan rpd:context            # JSON brief: modules, routes, models, config, extension patterns
php artisan rpd:context --format=text --no-routes

The JSON brief lists the modules, routes, models, configuration and extension patterns, and the two flags let you take a shorter output for a context window that is already full, or drop the routes section.

The README goes further and points at the package's own guidelines and skills, with a note that Laravel Boost's php artisan boost:install picks them up from the package. The repository layout backs that up: there is a .claude directory, a CLAUDE.md at the top level and an evals directory.

The verification loop is the other half. The package.json defines the front-end build, with a dev script that runs vite build --watch --mode rapyd and a build that produces both the rapyd and bootstrap modes, and the repository has a phpunit configuration and a scripts directory, so an agent has commands to run and check its own work.

This is the clearest case of a Laravel admin package treating an AI coding agent as a first class consumer rather than as an afterthought.

What to check before you adopt it

Three limits are visible without running anything.

The version floor is firm: PHP 8.2 or newer, Laravel 12 or 13, Livewire 4. The -W flag in the install command is there because of a dependency conflict, and that is a small sign of how much of the Laravel ecosystem the package pulls in through Fortify, Socialite and Spatie.

The GitHub repository has no tagged releases. The versions live on Packagist, where the README's badges track the latest stable version and the total downloads, so you pin a Packagist version rather than a git tag, and the CHANGELOG.md in the repository is where you read what changed.

And the scope is the modules. Everything the panel can do, it can do because a module exists for it. A product with an unusual workflow, a specialised search or an unusual tenancy model will be extending or ejecting those modules, which is exactly what the package is built to allow, but it is work you will be doing rather than configuration you will be setting.

On the comparison the README offers with Nova, Filament and Backpack, it names them as the heavier alternatives and positions Rapyd Admin as the light one. The README does not spell out how each of them differs, so the useful comparison to make yourself is the one the package is built around: how much of the admin code ends up in your repository, editable, versus how much stays inside a dependency. Rapyd Admin answers that with files in app/Modules and an eject command, and it is the axis on which the choice should be made.

Editorial conclusion

Adopt Rapyd Admin when you want a Laravel admin panel whose code lives in your repository as files you can read, edit and eject, and when you would rather not introduce a resource DSL or a second framework to learn. Do not adopt it if you need features the bundled modules do not cover and would rather not extend them yourself, since the modules are the product here. Before you install, read the module list in the README and the contract in docs/MODULES.md, and note the version floor, since the package requires PHP 8.2 or newer with Laravel 12 or 13 and Livewire 4, and the -W flag that lets Composer downgrade Guzzle to 7 on Laravel 13.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. zofe/rapyd-admin on GitHub