# django-vue3-admin: an RBAC admin scaffold with a FastAPI sidecar > django-vue3-admin is a full stack admin platform built on Django 5 and Vue 3 with vben-admin, offering dynamic menus, button level permissions, code generation and an added FastAPI ai_service subproject. It suits teams starting a Chinese language enterprise back office, and it will not fit a team that wants a bare permission layer rather than a full product. **XIE7654/django-vue3-admin** — django vue3 ts admin vben fastapi langchain - Repository: https://github.com/XIE7654/django-vue3-admin - Stars: 725 · Forks: 102 - Language: PLpgSQL - License: MIT - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/xie7654-django-vue3-admin ## What the project actually is: a full admin product, not a component The project is described as an enterprise grade back office management system built on Django 5 and Vue 3 with vben-admin, supporting dynamic menus, button level permissions, automated code generation and linked front end and back end permission enforcement. The intended scenarios are multi-role, multi-permission administration. That framing matters for how you evaluate it. This is not a reusable permission component you drop into your own application. It is a complete application whose model layer, admin screens, menu tables, permission tables and code generator are the product. The features listed cover the full administrative surface: department management, user management, role management, post management and menu management, each with its own screenshot in the readme, plus a front end view and a restricted employee view. The architecture is front end and back end separated. The back end is Django with Django REST framework, the front end is Vue 3 with the Composition API, TypeScript, Vite and vben-admin on Ant Design Vue. The database is MySQL by default and can be switched to PostgreSQL. The permission model is described as RBAC with granularity down to the column level, and the front end side adds a v-permission directive for button level control alongside dynamic routes. Whether column level enforcement survives contact with your own models is the first thing to check, since it is the most demanding claim in the feature list. The repository layout follows that split: backend/, web/, sql/, docker/, docs/, data/ and an ai_service/ subproject. ## The ai_service subproject is a separate FastAPI service A newer addition to the project is the ai_service subproject, built on FastAPI, which integrates AI conversation capability and can connect to large models such as DeepSeek, supporting intelligent dialogue and knowledge question answering, and is described as extensible to different AI scenarios. Architecturally this is the most interesting decision in the repository, and also the most questionable. A Django admin system has a natural home for an AI feature: a Django app with a model, a serializer, a view and a permission. Instead the project runs a second web framework alongside Django, which means a second process, a second configuration, a second set of deployment concerns, and a second place where the frontend's request routing has to be pointed. The readme does not describe how the two services are joined. It does not say whether the FastAPI service calls back into Django for permissions, whether it authenticates independently, whether requests pass through Nginx or the reverse proxy, or how the front end distinguishes a Django API path from a FastAPI one. The Docker section mentions the ai_service directory exists as a top level entry, but the compose files are documented only in terms of starting all services together. So the value of the ai_service addition depends on things the readme does not answer. If you are evaluating this project for an AI feature, that integration is the question to ask, and it is a question for the maintainer or the code rather than for the documentation. The repository description also names fastapi and langchain, and the primary language is recorded as PLpgSQL, which points to the database function and trigger work that goes with a generated permission and menu model. ## Getting the backend running from a SQL dump and a MySQL database The startup instructions are concrete, and they assume a specific environment: Python 3.12, and node v22.17.0 for the front end. The first step is editing the database configuration in backend/backend/settings.py, where the DATABASES block is edited to match the real host, port, user, password and database name. The documented default is a MySQL engine pointing at a database named django_vue on localhost with a root user and an empty password. The second step is to create the database and import the bundled schema, which lives at sql/django_vue.sql. The commands are run from inside the backend directory after installing the dependencies with pip install -r requirements.txt, and the create statement uses the utf8mb4 character set and the utf8mb4_unicode_ci collation. The documentation also notes that you can switch database engine by changing the same settings.py block. The service is then started with python manage.py runserver, which is the Django development server. For anything resembling production, the readme points at the Docker path instead, and the production compose file is the recommended route. The order matters and is easy to get wrong: the SQL import expects an empty database that already exists, and the settings file expects a name that matches. Do the database first, then the settings, then the import, then the server. ## Celery, beat scheduling and Flower as optional extras The task queue is documented as optional, and the three commands are the standard Celery trio. The worker is started with: ```bash celery -A backend worker -l info ``` Periodic tasks are configured in the CELERY_BEAT_SCHEDULE setting in backend/backend/settings.py, and the beat process is: ```bash celery -A backend beat -l info ``` Monitoring uses Flower, started with a port and a basic auth pair: ```bash celery -A backend flower --port=5555 --basic_auth=admin:admin123 ``` After that, the readme says you browse to http://localhost:5555 and enter the credentials to reach the Celery monitoring interface. Two practical observations. The Flower credentials in the documentation are the same weak pair as the demo login, so if you expose that port anywhere, change it, and note that basic auth over plain HTTP is not a security control, only a prompt. And the documented beat schedule example points at a task path for syncing a Temu order, which is a small window into how the project is actually used in production by its author. ## The front end: one vben-admin shell, and web-ele not yet supported The front end lives in the web/ directory, and the readme uses web-antd as the worked example, with an explicit caveat that web-ele is not currently supported and will be made compatible once components such as InputPassword are finished. That caveat tells you something a feature list would not. The project is a vben-admin monorepo with several UI targets, and the Ant Design Vue variant is the one that is complete. Choosing this project because you want Element Plus is choosing an unfinished path today. The toolchain is pnpm for installs and npm scripts for the dev server, with the antd target started by npm run dev:antd. The dependency set on the front end is Vue 3, Vite, TypeScript, Pinia for state, Ant Design Vue and the vben-admin component library, with dynamic routes and permission directives. The two space separated commands are worth separating mentally. pnpm install resolves the workspace, and npm run dev:antd runs a script from that workspace. The front end also needs to know where the Django API lives, and the readme covers that through the environment file templates in the docker/ directory rather than through a front end .env section, which tells you the deployment story is Docker-centric. The permission model shows up in the front end as dynamic routes built from the backend's menu table and a v-permission directive that hides or disables buttons the current role should not use. That is the mechanism behind the linked front end and back end permission enforcement claim, and it is the part to test against your own screen designs. ## Docker deployment, OSS uploads and a demo mode that locks writes The deployment story is Docker first, with two compose files, docker-compose.dev.yml and docker-compose.prod.yml, and the readme recommends the production route for real deployments. The sequence in both cases is to copy the environment template and then bring the stack up: ```bash cp docker/.env.example docker/.env.local ``` and the production stack is started with docker compose -f docker-compose.prod.yml up -d --build. Ports, the database and the Redis password are all set in docker/.env.local. Two configuration features are worth understanding before exposing the system. The first is Aliyun OSS upload for the front end, enabled through a block of VITE_ prefixed variables in docker/.env.prod, covering the region, access key id and secret, bucket and prefix, plus a flag for whether to delete the local file after upload. Those credentials are VITE_ prefixed, which means they are baked into the client bundle, so treat that key as a public credential and give it a bucket policy scoped to the prefix rather than full account access. The second is the demo mode, which is turned on with a single variable: ```bash DEMO_MODE=true ``` In that mode all modification and deletion operations are globally forbidden, only basic operations such as login and logout are allowed, any modify or delete request returns a 403, and the Django Admin interface is disabled. The point is to make the public demo safe. The point for you is that this is the safety net for a public instance, and the online demo at demo.ywwuzi.cn publishes two accounts, admin/admin123 and chenze/admin123. If you deploy this, change those credentials before it is reachable. ## Where this project fits badly Several realistic cases rule it out. The first is a small service. If you need a users table, a login and a couple of admin screens, inheriting a generated role, menu, post, department and permission model with column level control is a large commitment. The code generator and the dynamic menu system are features when you have dozens of entities, and overhead when you have four. The second is a team that does not read Chinese. The readme, the documentation site at docs.ywwuzi.cn and the in-code comments are all in Chinese. The identifiers in the code are English, but the guidance, the changelog and the support channels are not, and an international team will spend real time on that. The third is a team that wants to keep its own domain model intact. A permission model that reaches column level, with automatic menu and permission generation scripts tied to a particular data model, is a framework that expects to own your schema. Adopting it means accepting its models, or rewriting the generator. The fourth is the AI subproject, if AI is not what you are after. Adding a FastAPI process with its own model provider credentials and an undocumented integration boundary is pure cost for a project that does not need it, and the readme gives you no way to assess the integration without reading the code. The fifth is release discipline. There are no GitHub releases, and the last push was on 2026-05-21, more than five months before this article. The project may be in active use, but the repository offers no version tags to pin, no changelog to read and no upgrade path. For a foundation you are going to build a product on, that is the most serious of these limitations. ## Conclusion Adopt django-vue3-admin when you are building a multi-role enterprise back office, want a permission model that reaches button level, and prefer a shipped product to a hand assembled admin, since the RBAC model, the dynamic menu generation and the code generator are all included. Do not adopt it if your needs are a small CRUD service, if your team will not work in a Chinese language documentation ecosystem, or if the column level permission model and the accompanying data model are more than you want to inherit. Before you start, confirm the demo accounts are disabled on your instance, create the database and import the SQL file, and decide whether the ai_service subproject earns its extra FastAPI and model provider dependency. ## FAQ ### What stack does django-vue3-admin use? The back end is Django 5 with Django REST framework on Python 3.12 or later, and the front end is Vue 3 with the Composition API, TypeScript, Vite, Pinia and vben-admin on Ant Design Vue. MySQL is the default database and PostgreSQL is supported as an alternative. ### How do I set up the database for django-vue3-admin? Edit the DATABASES block in backend/backend/settings.py, create the database in MySQL, then import the bundled schema from sql/django_vue.sql before running the server. The import expects an empty database that already exists. ### What permission features does django-vue3-admin provide? It is built on an RBAC model with permission granularity down to the column level, with roles in a many-to-many relation to permissions, dynamic menus driven by the backend, button level control in the front end through a v-permission directive, and automated scripts that generate menus and permissions. ### Does django-vue3-admin include a frontend AI service? Yes, an ai_service subproject built on FastAPI that integrates AI conversation and can connect to large models such as DeepSeek. The readme does not describe how that service authenticates against Django or how the two services are routed. ### What is the demo mode in django-vue3-admin? Setting DEMO_MODE to true in docker/.env.prod globally forbids modification and deletion operations, allows only basic operations such as login and logout, returns 403 for modify and delete requests, and disables the Django Admin interface, so a public demo cannot be altered. ## Sources - [Issues](https://github.com/XIE7654/django-vue3-admin/issues) - [License: MIT](https://github.com/XIE7654/django-vue3-admin/blob/main/LICENSE) - [README](https://github.com/XIE7654/django-vue3-admin/blob/main/README.md) - [XIE7654/django-vue3-admin on GitHub](https://github.com/XIE7654/django-vue3-admin) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/xie7654-django-vue3-admin