FastapiAdmin: a full-stack admin scaffold on FastAPI and Vue 3

What FastapiAdmin assembles

FastapiAdmin is a fully open source rapid development platform, free to use, built on a modern stack: FastAPI and SQLAlchemy on the backend, and Vue 3 with TypeScript, Vite, Pinia and Element Plus on the frontend. Its stated purpose is to help developers build high quality back-office systems quickly.

The scope it claims is a full admin platform rather than a starter kit. The built-in features are described as more than 200 REST endpoints, with three database dialects in the form of MySQL, PostgreSQL and SQLite, and five storage protocols in the form of SFTP, S3, OSS, COS and OBS.

The core modules are always enabled and cannot be trimmed. They are the dashboard with a workbench and data analysis, system management covering users, roles, menus, departments, positions, dictionaries, parameters, notices, work orders and versions, monitoring management for online users, server monitoring and cache monitoring, log management for operation log auditing, and development tools for the interface documentation.

The permissions model is the piece the README's comparison table leads with: RBAC with three levels of menu, button and data permissions, against Django Admin's basic offering and a frontend template that has none of it.

The frontend is not a single app. There is a web client, a mobile client built with UniApp that covers H5, mini program and App from one codebase, and a VitePress documentation site. The repository root holds `backend/`, `frontend/`, `docker/`, `deploy.sh` and the `LICENSE`, alongside `AUDIT-REPORT.md`, `DEPLOYMENT.md`, `REQUIREMENTS.md`, `SKILL.md` and `TEAM-PLAYBOOK.md`.

The licence is MIT, and the repository is not archived with the last push on 2026-10-15. The release tags are v3.0 from 2026-07-27, V2.0 from 2026-04-30 and V1.0 from 2025-07-20.

The monorepo layout and the run command

The project structure in the README is a monorepo with five parts:

FastapiAdmin/
├─ backend/
├─ frontend/
│   ├── web/
│   ├── app/
│   └── docs/
├─ docker/
├─ deploy.sh
└─ LICENSE

The `backend/` directory is the FastAPI service, built on Pydantic 2.0, SQLAlchemy and Alembic. Inside `frontend/` there are three projects: `web/` for the Vue 3 web client with Element Plus and TypeScript, `app/` for the UniApp mobile client that shares one codebase across H5, mini program and App, and `docs/` for the VitePress documentation site. The `docker/` directory holds the Docker Compose deployment with Nginx and SSL, and `deploy.sh` is the one-click deployment script.

The local start is documented as a five minute path, and every command is given:

git clone https://gitee.com/fastapiadmin/FastapiAdmin.git
cp backend/env/.env.example backend/env/.env.dev
cp frontend/web/.env.development.example frontend/web/.env.development
cd backend && uv sync && uv run main.py run --env=dev
cd ../frontend/web && pnpm install && pnpm run dev

Two details in that snippet matter. The clone URL points at Gitee rather than GitHub, which is a deliberate choice for a project whose documentation site is also Chinese hosted. And the backend is started with `uv sync`, so the Python environment is managed by uv with the lockfile implied, and the backend entry point is `main.py` with a `run` subcommand and an `--env` flag rather than a bare `python main.py`.

The first run creates the tables and initialises the data automatically, and the README tells you to open the browser at `http://127.0.0.1:5173` and log in with `admin` and `123456`. The environment requirements are Python 3.12 or newer, Node.js 20.0 or newer with pnpm, MySQL 8.0 or newer or PostgreSQL 14 or newer, and Redis 6.x or 7.x.

ENABLED_MODULES trims the optional surface without deleting code

The extension modules are the part of the platform that a project usually does not need, and the trimming mechanism is the most interesting design decision in the repository.

The five extension modules are enabled by default and each has a switch. Task management covers scheduled task execution plus visual workflow orchestration with built-in business nodes, switched by `task`. The code generator turns a selected table into complete front and back end code, switched by `generator`. Data storage provides unified file and object storage across SFTP, S3, OSS, COS and OBS, switched by `storage`. AI chat is an agent conversation built on Agno, switched by `ai`. Internal chat is a plain-text private and group chat between system users with realtime WebSocket push and an unread badge, switched by `chat`.

The trimming happens through `ENABLED_MODULES` in `backend/app/config/setting.py`. The README is explicit about the mechanism: removing a list entry is enough, no code or menu needs to be deleted, and the corresponding REST endpoints, WebSocket endpoints and initialisation logic are simply not loaded.

ENABLED_MODULES = ["generator", "task", "storage"]

This is a meaningfully different approach from a template you copy and then delete from. A copied template accumulates the code you removed, because removing it by hand is tedious and reverting is impossible. Here the full feature set stays in the tree, so upgrading is a merge rather than a re-implementation, and the deployment only loads what you asked for.

The trade-off is that the code for a disabled module is still on disk and still in the repository, so the attack surface of a disabled module is present in the artefact even if it is not loaded. Whether that matters depends on how the modules are gated.

Deployment notes that describe the limits honestly

The deployment section of the README is short and unusually candid, and it is the part to read before adopting the project.

The chat boundary is stated first. Internal chat is positioned as lightweight internal communication supporting plain text messages only, with no file transfer, no recall, no read receipts and no multi-device sync. The recommendation for anyone with a real instant messaging requirement is to integrate a mature product such as WeCom, DingTalk or Feishu. And the chat module can be removed from `ENABLED_MODULES` at any time.

Single instance deployment is the second constraint. The realtime features, namely the internal chat WebSocket and the scheduled task scheduler, are implemented on in-memory connections and local scheduling, so the deployment must be single-instance. For horizontal scaling, the README says you would need to introduce Redis Pub/Sub or a message queue yourself.

Third, key management. All third-party secrets, for AI and cloud storage among others, are to be configured in the `backend/env/.env.*` environment variables, and the README says explicitly never to commit them to the repository or write them into the database.

Fourth, database migrations. In a production environment, schema changes should be managed with Alembic migrations run through `uv run alembic upgrade head`, and `create_all` is only a fallback for the first initialisation.

That last point is the one to plan for from day one. A project that starts with `create_all` and then needs a schema change has no migration history, and introducing Alembic into a database that already has tables is a unpleasant afternoon. The README's ordering of these notes suggests the authors have been burned by that path before.

Docker deployment and the documentation surface

The Docker route is two commands:

cp docker/.env.example docker/.env
./deploy.sh

The script builds the images and brings up the whole stack, and the README points to the Docker deployment document for ports, SSL certificates and the front end build details. The `docker/` directory is a Docker Compose deployment with Nginx and SSL, and the compose file lives beside a `README.md` in that directory.

The `deploy.sh` script at the repository root is the same idea for the whole monorepo, and there is a `deploy-artifacts.sh` beside it for build artefacts specifically.

Documentation is unusually extensive for a project of this type. The VitePress site in `frontend/docs` is the official documentation, and the README links it as the place for the complete development guide, architecture design and second-development tutorials. The sub-projects each have their own README, for the backend, the web frontend, the mobile client and the Docker setup.

Beyond that, the repository root contains a set of files that are not typical for an open source project: `AUDIT-REPORT.md`, `TEAM-PLAYBOOK.md`, `SKILL.md`, `REQUIREMENTS.md`, `DEPLOYMENT.md` and a `CHANGELOG.md`. A security audit report and a team playbook in the repository suggest a project with an internal organisation behind it, which is worth knowing about a codebase you may be inheriting.

There is a live demo at the project's service domain, with separate web and mobile entry points, and the documentation site is open without a login. The demo credentials are `admin` and `123456`, the same as the local seed data.

Where FastapiAdmin is the wrong choice

The first wrong case is a product that needs to scale horizontally. The internal chat WebSocket and the task scheduler are built on in-memory connections and local scheduling, so the deployment must be single-instance, and adding a message queue is work the README hands to you. If your product's realtime features have to run across several instances, this platform is a starting point you would have to unpick.

The second wrong case is a codebase that cannot accept a large generated surface. The platform ships more than 200 REST endpoints, five core modules and five extension modules, and a code generator that produces front and back end code from your tables. That is a lot of code to inherit, review and keep patched. A team that wants three screens and one table will spend more time understanding the scaffold than writing the application.

The third is a security-sensitive deployment that does not change the seed data. The local and demo credentials are `admin` and `123456`, published in the README, and the first run initialises the data with them. Any deployment that leaves the default password in place is trivially owned, and the README's key management note covers third-party secrets but not the initial account.

The fourth is a team that wants a product rather than an internal tool. The comparison table in the README is honest that the target is a back-office system, and the whole feature set, from departments and positions to work orders and version management, is built for internal administration rather than for a customer-facing application.

What the project does well is turning undifferentiated admin work into a clone, a config file and a deployment script, with the module trimming and the migration guidance showing that the authors have run it in production.

Editorial conclusion

FastapiAdmin suits a team that needs a working internal admin system, with users, roles, menus, departments, dictionaries, parameters, notices, tickets, monitoring, operation logs and a code generator, and that would rather start from a working reference than assemble those parts from scratch. It does not suit a product needing horizontal scaling of its realtime features, since the internal chat WebSocket and the scheduler are explicitly single-instance, and it does not suit a codebase that cannot accept published default credentials, because the demo and the local seed data use admin and 123456. Before adopting it, review the deployment notes in `DEPLOYMENT.md` and the `AUDIT-REPORT.md` in the repository root, plan your Alembic migration path from the first day, and decide which extension modules you actually need through `ENABLED_MODULES` in `backend/app/config/setting.py`.

Frequently asked questions

Official sources

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