FastAdmin: a ThinkPHP admin panel where one click writes a whole CRUD module

The generator writes eight artefacts at once

The feature list leads with permission management and then with generation, and generation is the part that defines this framework. One action produces a complete CRUD module: controller, model, view, JavaScript, language pack, menu entry and recycle bin.

That list is the specification, and each item has a consequence. Language packs mean an admin interface is translatable from the start rather than after someone hard-codes Chinese strings. Menu entries mean the permission tree is populated by the generator instead of by hand-editing a route table. A recycle bin means deletes are recoverable, which matters because the generator's default workflow is delete.

The same generator handles adjacent chores: producing controller menus and rules, generating API interface documentation, minifying and packaging JS and CSS in one step, and deploying static assets to a CDN.

What it does not generate is your domain logic. A generated controller gives you the conventional actions wired to the model and the view; the parts where your business differs from CRUD are yours to write. The README is honest by omission on this point, and it is worth being explicit with a team before they assume the generator solves their modelling.

Auth-based permissions with unlimited parent-child nesting

Access control is built on an Auth component, and the model it uses is more specific than a flat role list.

Parent-child permission inheritance is unlimited in depth, and a parent administrator can add, edit or delete child administrators and their permission settings. That is the feature teams building a reseller or franchise back office care about, because it maps to an organisation tree rather than to a list of job titles.

One administrator can hold multiple roles, which is what makes the tree workable: a person can be an operator in one department and an auditor in another without being two accounts.

The data scoping follows the same shape. Administrators can be restricted to managing sub-level data or to managing only their own data, which is the distinction between a regional manager and an ordinary operator.

The same account system is reused on the public side. The README describes a general membership module and API module, with the Web member centre and the API permission checks sharing one account system, so you are not building two login systems for the same users.

The npm dependency list is a list of forks

This is the detail that determines how you maintain the frontend, so read package.json rather than the feature list.

Several core libraries are installed under an npm alias pointing at a FastAdmin-maintained fork.

"bootstrap": "npm:fastadmin-bootstrap@^3.4.1",
"bootstrap-table": "npm:fastadmin-bootstraptable@^1.11.12",
"nice-validator": "npm:fastadmin-nicevalidator@^1.1.6",
"art-template": "npm:fastadmin-arttemplate@^3.1.4"

The same packages also appear under their own fastadmin- names, for example fastadmin-bootstraptable, fastadmin-nicevalidator, fastadmin-selectpage, fastadmin-layer, fastadmin-citypicker, fastadmin-dragsort and fastadmin-addtabs. So the project depends on Bootstrap 3, jQuery at ^3.7.1, Bootstrap-table 1.x, RequireJS for JS module management, Less for styles and AdminLTE as the base theme.

The practical consequence is that `npm update` does not do what you would like. When upstream Bootstrap-table or nice-validator ships a release, you do not get it, because your node_modules is bound to a fork. Updating means tracking the FastAdmin fork, which is a real ongoing maintenance relationship rather than a version bump.

The overrides section shows the project already does this kind of work: xmldom is pinned for canvg, xlsx is overridden with a specific package for the table export plugin, and moment-timezone is forced for the datetime picker. Those overrides exist because of transitive dependency problems, which is more evidence of the fork strategy's cost.

Uploads, exports and fixed tables are the everyday features

The list of operational features is where you can tell whether this was written for the work you have.

File upload covers large files in chunks, paste from clipboard, drag and drop, a progress bar, and client-side image compression before upload. Chunked upload matters whenever you accept video or archives, and clipboard paste is the feature that quietly changes how people use an admin panel.

Table handling includes fixed columns, fixed headers, selection across pages, Excel export and template rendering. Cross-page selection in particular is the thing that breaks in most hand-rolled admin tables, because it requires the selection model to live outside the current page of results.

Storage and messaging are integrated rather than left to you: cloud storage from Qiniu, Alibaba Cloud OSS, Tencent Cloud Storage and Upyun, with chunked upload to cloud, plus third party SMS through Alibaba Cloud and Tencent Cloud. Rich text editors supported are Summernote and the Baidu editor.

Logins and payments are also integrated, covering QQ, WeChat and Weibo sign-in, and WeChat and Alipay payments with WeChat supporting PC scan-to-pay.

None of these are deep integrations. They are working defaults so that a project does not begin with a week of SDK plumbing.

Where to install, and what the .env.sample tells you

The README does not carry installation steps. It links the documentation site at doc.fastadmin.net for installation and usage, and a demo at demo.fastadmin.net with the username admin and the password 123456. The demo carries a warning that its data cannot be modified and that you should download the source to try the full feature set.

What the repository does give you is the runtime configuration template, and it is short enough to read in full.

[app]
debug = false
trace = false

[database]
hostname = 127.0.0.1
database = fastadmin
username = root
password = root
hostport = 3306
prefix = fa_

The database block is INI style rather than the dotenv KEY=value you might expect from the filename. The table prefix of fa_ matters beyond installation: generated models, menu rules and permissions all assume it, so changing it later means touching generated code.

The repository root shows the shape of a ThinkPHP application: application/ for the app, addons/ for plugins, extend/ for extensions, public/ as the web root, runtime/ for generated output, tests/, plus the `think` console entry, composer.json, Gruntfile.js and package.json. The build script is simply `grunt`.

Package version is 1.6.7 and the default branch is 1.6.x-dev, so you are tracking a maintained minor line rather than a single stable tag. There are no GitHub releases, so composer.json is how you pin a version, and the gitee repository listed in the package metadata is the origin the project treats as its own.

When this is the wrong choice, and what you use instead

The clearest wrong-tool case is a team that wants a modern frontend. The stack here is Bootstrap 3 with jQuery, RequireJS modules and Less, and several of those libraries are pinned to forks. Building a 2026 admin product on that is a decision you should make deliberately rather than inherit from a tutorial.

The second case is a polyglot or non-PHP backend. FastAdmin is a ThinkPHP application with plugin addons/; the plugin marketplace is PHP addons, and while the README notes support for deploying to a second-level domain and binding domains to application plugins, nothing suggests it can front a non-PHP service.

The alternative worth naming concretely is generating an admin panel from your own API. You describe your resources, a generator emits typed API clients, and you assemble the interface with a component library of your choice. That costs you the membership module, the auth tree, the recycle bin, the upload pipeline and the plugin marketplace, all of which FastAdmin hands you already built and tested. What you get in return is a frontend you control, a schema that comes from your API rather than from a table prefix, and no fork maintenance.

The deciding factor is not features. It is whether you want an admin panel that is a ThinkPHP application with a bundled interface, or an interface that talks to a service. Those are different products, and FastAdmin is firmly the first one, licensed Apache-2.0 with third party copyright notices noted separately.

Editorial conclusion

Adopt FastAdmin if you are building a Chinese-market back office on ThinkPHP and your team wants the standard CRUD, menu, permission and upload plumbing assembled rather than hand-built, since the generator covers controller, model, view, JS, language pack, menu and recycle bin in one step. Do not adopt it if you need a modern frontend stack, because the npm dependencies are forked under the fastadmin- prefix and pinned to jQuery 3.7.1, Bootstrap 3 era components and RequireJS module loading. Before you start, work through the install guide at doc.fastadmin.net and copy .env.sample to .env, because the database block there, including the fa_ table prefix, has to match your MySQL instance before any code generator runs.

Frequently asked questions

Official sources

1. fastadminnet/fastadmin on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README