CatchAdmin: a Laravel and Vue3 admin framework built around modules

Laravel as an API layer only, with business features pushed into modules

CatchAdmin is built on Laravel 12 and Vue 3 as a separated front end and back end admin system for enterprise back office work. The architectural decision that shapes everything else is stated plainly in the project description: Laravel serves as the API service layer only, and coupling between business modules is deliberately kept weak. Every module has its own controller, routes, model and database table structure, so a module can be split out, loaded on demand and evolved on its own.

That is the difference from a conventional Laravel admin package that treats your application as one code base with a shared migration folder and a shared routes file. Here the unit of work is the module, and the framework ships the parts that every back office needs anyway.

The stack around it is visible in the badges and the repository contents: PHP 8.2, Laravel 12, Vue 3.x, Element Plus, Vite 7 and Apache 2.0, with a modules directory, a routes directory, a config directory, a database directory, lang files, tests and phpunit configuration. The primary language is PHP, and the project also carries an AGENTS.md file and a .claude directory at the top level.

Permissions are modelled at menu, button and data level at once

The permission system is the reason most teams would look at this project. Three kinds of permission are separated, which is what makes a back office usable rather than merely functional.

Menu permissions decide which parts of the system a user sees, and the menu module configures system menus, routes and button resources visually, with ordering, hierarchy and hiding, so that the front end and the back end stay consistent about what a role can reach. Button permissions are the finer layer, assigned per role inside a tree structured role system. Data permissions sit above both, and the role module holds role menus, button level assignments and data scope configuration together.

Two supporting structures feed the identity layer. The department module maintains a multi-level tree of companies, departments and groups with personnel assignment, and the position module manages posts and positions, including primary and multiple positions per person. Because the menu is data rather than code, changing what a role can reach does not require a deployment.

Dynamic routes, dynamic tables and a pagination wrapper for list screens

Beyond permissions, the framework provides the mechanics that back office screens usually need. Dynamic routing and dynamic tables are named as first-class features, together with a pagination wrapper, resource level permission control, unified responses, exception handling and resource wrapping, so that list screens behave the same way across modules without each module reinventing them.

Around that sit the operational modules a team would otherwise write. Operation logs record key actions and change trails with search by user, module and time, which is the audit trail an admin system is usually judged on. Login logs record login history and access information such as time, IP and device. The dictionary module centralises enumerations, statuses and types so that values are not hardcoded in each module. System configuration centralises common parameters with categorised storage and dynamic reads.

Data maintenance is included too, with table fragmentation cleanup and optimisation plus a recycle bin for deleted data, which is a detail that separates a framework from a tutorial project but also a feature that carries its own risk, since a recycle bin holding deleted records is a data retention question your compliance owner will ask about.

Code generation for php and vue, plus Vue rendering without a build step

The code generator produces the php and vue sides of a module together with the database migration file, and it can write the result straight into a module directory. For a team whose modules follow a regular shape, that removes the most repetitive part of adding a screen.

The second feature is faster Vue rendering, which lets a Vue change take effect without compiling. In development that means an edit to a component shows up without a build step, and in production it means the front end can be served without a separate compile pipeline for many cases. The project lists both features together, and the second one is the one with the bigger architectural consequence, since it changes what you need to run in order to see a change.

The plugin system is the third extension path, and it follows Composer rather than a custom registry: a plugin is a Composer package that integrates deeply with the Composer ecosystem and can be added module by module. For teams that already publish internal Composer packages, this is a natural fit, since the same packaging and version constraints apply to an admin plugin as to a library.

Installation is a composer create plus one artisan command

The quick start is two steps and is documented in the README with Chinese text.

composer create catchadmin/catchadmin

cd catchadmin

php artisan catch:install

The install command is the part that matters. The example compose file shows what it does, since the container command chains the environment file copy, the installer and a dev server.

    php:
        container_name: catchadmin
        image: jaguarjack/php82
        ports:
            - "8001:8001"
            - "9000:9000"

The compose file also brings up MySQL with the root password set in the environment and a node service that installs the front end dependencies and starts a dev server on port 8000.

    node:
        container_name: dashboard
        image: node:latest
        ports:
            - "8000:8000"
        command: yarn install && yarn dev

Here is the practical catch. The front end has its own repository, catchadmin-vue, and the README links it separately, so the composer install gives you the API and the admin modules but not the user interface. You either clone that second repository as well, or you accept that the admin panel has no front end until you do.

The .env template shows exactly which knobs the framework expects

The .env.example file in the repository root is a good map of what the framework expects to be configured, and it lists the usual Laravel keys plus a set that belongs to this project.

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
VITE_BASE_URL=${APP_URL}/api/
OCTANE_SERVER=swoole

Three things stand out. APP_KEY is empty in the template, so it must be generated before the app will encrypt anything, and the same file ships APP_DEBUG=true with LOG_LEVEL=debug, which is a development default that has no business being copied into a production .env.

Second, storage choices are listed explicitly: the cache driver is file with the prefix catch_, sessions use the file driver, the queue connection is sync, and the filesystem disk is local. The upload feature supports local storage plus Qiniu, Alibaba and Tencent cloud back ends, each with its own keys in the template. The framework can also run under Octane with the server set to swoole.

Third, the presence of Redis and Memcached keys in the template tells you which directions the project can grow, without any of them being required for a first run.

Chinese first documentation, an AI-oriented workflow and no tagged releases

The project is maintained in Chinese, with README.md and README-en.md side by side and documentation hosted at doc.catchadmin.com. The description, the feature list and the install notes are written in Chinese, so an English speaking team is working from the translated README and the docs site rather than from a fully parallel set of sources.

The project also makes its tooling stance explicit. It supports Skills extensions for packaging reusable AI capabilities such as code generation, permission queries and user lookup, it follows the AGENTS.md convention so coding assistants can read the project structure and conventions, and its documentation is wired into the Context7 MCP service so that an IDE can pull current API documentation and practices. That is a real differentiator for teams using assistants heavily, and it is also a coupling: the assistant workflow depends on conventions the project maintains.

On maintenance, the last push was on 2026-10-19 and the default branch is v5, but the repository has no GitHub releases at all, so there is no tag to pin a deployment to. The licence is Apache-2.0, held in LICENSE.txt, and the project states that commercial use is permitted as long as the copyright notice is kept. For a framework you plan to extend with plugins, the absence of tagged releases is the item to plan around.

Editorial conclusion

Adopt CatchAdmin when you are shipping a CRM, CMS or OA style back office and want token authentication, menu, button and data permissions plus a code generator already in place. Do not adopt it when you need a single artifact to deploy, since the frontend lives in its own repository and the Docker example in the repository still runs a node service, or when your team will not read Chinese first because the project documentation and the README are Chinese first with an English README alongside. Before the first run, confirm the branch you clone is the v5 default branch, fill in APP_KEY and the database credentials in .env, and check that the MySQL version you use matches the one in the example compose file, since it pins mysql:5.7.

Frequently asked questions

Official sources

1. Issues
2. JaguarJack/catch-admin on GitHub
3. License: Apache-2.0
4. Project website
5. README