BuildAdmin: a Vue 3 and ThinkPHP 8 admin system with visual CRUD generation

What BuildAdmin solves, and for whom

The repetitive part of an admin panel is the same in every project: a table, a filter bar, a create form, an edit form, a delete button, and a permission check on each of them. BuildAdmin's answer is to let you describe that shape visually and emit the code. The README describes CRUD generation as starting from scratch, from an existing data table, or from an AI-designed data table, with up to 25 form components, row drag sorting, and permission-controlled edit and delete actions.

The audience is narrower than the feature list suggests. This is a PHP project. The backend is ThinkPHP 8 and the repository carries composer.json, app/, config/, database/ and a think entry file, so the person adopting it needs a PHP 8 runtime and MySQL. The frontend is Vue 3 with setup syntax, TypeScript, Vite, Pinia and Element Plus, which means a frontend developer can work in web/ without touching PHP until the API contract changes.

The pitch that matters most for a small team is the combination: generated CRUD plus an infinite-level permission tree plus a global data recycle bin. Building those three by hand is where admin projects usually lose a week.

How the generator, the permission tree and the terminal fit together

The architecture is a separated frontend and backend. The README states that web/ contains both clean frontend files (without backend code) and complete frontend files, and that the two halves can be developed and deployed separately. The backend follows ThinkPHP 8 and PSR conventions, which the README cites as the reason server-side loading is on demand.

The permission model is the connective tissue. Permissions are managed visually, and routes, menus, pages and buttons (called permission nodes) are registered dynamically from that data. Menu nodes support unlimited parent and child levels. This is why generated CRUD is more than a code template: a generated page arrives with its own permission nodes, so the access control does not have to be retrofitted.

The web terminal is the unusual piece. The README says it is integrated into the local development environment and that it can call any command available in the environment variables. Two concrete consequences are stated: installing the system does not require running npm install by hand, and after CRUD generation the terminal invokes prettier to format the generated code. That is a real design decision, not a gimmick, and it also explains why the terminal is described as a local development feature rather than a production one.

The recycle bin works at field level. The README describes a global data recycle bin with per-field modification records and modification comparisons, so a change can be rolled back. Treat that as the safety net for the generated edit forms, which are otherwise just direct writes.

Installing BuildAdmin and generating the first CRUD screen

The README does not inline installation commands. It points to the documentation, with a quick-start path for people who already know ThinkPHP and Vue, and step-by-step guides for Windows, Linux (BT panel) and MacBook. Use those rather than improvising, because the terminal-based installer is part of the flow.

The repository root gives a hint about configuration: there is a .env-example file, which is the conventional ThinkPHP way of supplying environment settings. Copy it to .env and fill in your database connection before running the installer.

cp .env-example .env

After the environment file is in place, the documented path is to run the installer from the project root and follow the browser prompts. The repository ships a think console entry, which is the standard ThinkPHP command runner.

php think

Once the system is installed and you are logged in, the CRUD generator is where the value shows up. The README describes three starting points: from zero, from an existing data table, or from an AI-designed data table. Pick the existing-table route first if you already have schema, because it produces a table that matches your columns instead of a table you then have to reconcile.

The generated output is Vue files under the frontend plus backend controller and model code. The README states that the built-in terminal then runs prettier over the result, so the first thing to check after generation is whether formatting ran, which tells you the terminal is wired correctly. If it did not, the terminal is the thing to debug, not the generator.

Finally, the module market installs packages by maintaining package.json and composer.json automatically and pulling dependencies through the built-in terminal. That is the same mechanism, so a working terminal is a prerequisite for modules too.

Where BuildAdmin is the wrong choice

The hard constraint is the runtime. If your infrastructure is Node, Go or Python, BuildAdmin is not a candidate; the backend is ThinkPHP 8 and there is no documented path to run the admin API without PHP. The README does mention a separate Golang version published as a distinct product with its own documentation page, which is a fork in the road rather than a configuration option.

The resident-memory story needs reading carefully. The README claims that built-in features can run in resident memory with a large performance gain, but the mechanism is a separate module: the Workerman module provides the resident-memory HTTP service and a WebSocket service. So the fast path is an add-on you install, not the default state of a fresh install. Anyone expecting the base install to be a long-running process should check that module first.

Deployment is another boundary. The terminal executes arbitrary commands from the environment, which is useful locally and unacceptable as a production surface. The README frames it as part of the local development environment, and that framing should be taken literally.

There is also a licensing nuance worth checking rather than assuming. The repository carries Apache-2.0 and the README says commercial use is free without authorization, but the module market contains separately distributed modules whose terms are not described in the README. If you plan to build on market modules, read their terms individually.

BuildAdmin against CatchAdmin, FastAdmin and MineAdmin

These four names come up together because they occupy the same slot: a PHP admin framework with code generation. The differences are in the frontend and in how much is generated.

FastAdmin is the older, Bootstrap-era model. Its admin UI is server-rendered rather than a Vue 3 single-page application, so the interaction model and the way you extend a page are different in kind. If your team writes jQuery and PHP templates, FastAdmin is closer to that habit; BuildAdmin is not, and the TypeScript plus Vite toolchain is not optional.

CatchAdmin and MineAdmin are the closer comparisons, since both target a modern PHP backend with a separated frontend. The distinguishing feature to check when comparing is BuildAdmin's built-in web terminal and its automatic maintenance of package.json and composer.json during module installation. That is the part of BuildAdmin that is hardest to replicate elsewhere, and it is also the part most tied to a local development workflow.

None of these comparisons can be settled from a README. The practical test is to take one real table from your project and generate its CRUD screen in each candidate, then look at what the generated permission nodes and menu entries look like. BuildAdmin's unlimited-level permission grouping is where that test will differentiate it.

Maintenance, releases and the cost of upgrading

The repository is not archived, and the last push was on 2026-09-17, the same date as the v2.3.9 release. The preceding releases were v2.3.8 on 2026-07-27 and v2.3.7 on 2026-06-06. That is a steady cadence of roughly six to eight weeks between releases, with the default branch named v2.

Upgrade cost is shaped by the generator. Generated CRUD code lives in your repository as ordinary Vue and PHP files, so an upgrade does not rewrite it, but it also does not fix it. If a release changes how permission nodes are registered or how the frontend loads components, generated pages from an older version may need regeneration rather than patching. The CHANGELOG.md file in the repository root is where that would be documented, and it is the first file to read before upgrading across a minor version.

There is a second upgrade surface: the module market. Because modules install through the terminal and touch package.json and composer.json, a module upgrade can pull dependency versions with it. Pin your dependency versions before installing or updating market modules if you care about reproducible builds.

On licensing, the repository is Apache-2.0 and the README states that commercial use is free without authorization. Apache-2.0 includes a patent grant and requires that you retain notices. That is a general property of the licence, not advice about your situation; if you redistribute BuildAdmin as part of a product, have someone confirm the notice requirements and check the terms of any market module you bundle.

Editorial conclusion

Adopt BuildAdmin if your team already runs PHP 8 with ThinkPHP and wants a Vue 3 admin shell with generated CRUD screens and a permission system that registers routes from menu nodes. Do not adopt it if you have no PHP runtime, if you need a Node-only stack, or if you want a frontend-only template: the web folder does ship a clean frontend without backend code, but the generated CRUD and the permission data live in the PHP side. Verify before committing: that your PHP and MySQL versions satisfy the install guide, that the licence file in the repository matches what you need for commercial use, and that the module market components you plan to use are installable through the built-in terminal.

Frequently asked questions

Official sources

1. build-admin/buildadmin on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases