django-vue3-admin: a Django and Vue 3 admin platform with column level permissions
Django-Vue3-Admin is a comprehensive basic development platform based on the RBAC (Role-Based Access Control) model for permission control, with column-level granularity. It follows a frontend-backend separation architecture, with
At a glance
- What is it?
- Django-Vue3-Admin is an open source rapid development platform that pairs Django and Django REST Framework with Vue 3, TypeScript, Pinia and Element Plus, and adds an RBAC model whose permissions reach down to individual table columns and buttons. It ships menu, department, role, user, dictionary, region, file and log modules, plus a plugin market, and it runs on SQLite by default or on MySQL and Redis.
- Who is it for?
- django-vue3-admin fits a team that wants to skip writing an internal admin console and start from a full RBAC skeleton with column level permissions and a Vue 3 frontend already wired up. It does not fit a product with its own design system, a team that cannot take on a framework with a Gitee-first workflow, or anyone planning to build a public facing application on top of it.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 38 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 24, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A permissions model that reaches the column level
Django-Vue3-Admin is described as a comprehensive basic development platform based on the RBAC model for permission control, with column-level granularity, following a frontend-backend separation architecture. Django and Django REST Framework serve the backend, and Vue3, the Composition API, TypeScript, Vite and Element Plus make up the frontend, with fast-crud and Pinia handling the data layer and state.
The feature that distinguishes it from an ordinary admin generator is the fifth item in the core function list, field column permission control, which authorises page field display permissions, specifically the display permissions of a certain column. That is finer than the usual role-to-menu mapping, and it is the thing to understand before you adopt the platform.
The surrounding permission machinery is conventional but complete. Menu management configures system menus, operation permissions, button permission flags and backend interface permissions. Department management configures the organisational structure of company, department and role. Role management assigns role menu permissions and data permissions, including setting role-based data scope permissions by department. Button permission control authorises role-specific button permissions and interface permissions, and enables authorisation of data scope for each interface.
Authentication uses Django REST Framework SimpleJWT, and the README notes it supports a multi-terminal authentication system, with support for loading dynamic permission menus.
The project describes itself as completely open source, provided free for personal use and authorised for group use, with no reservation for individuals or enterprises.
The modules you get on day one
The core function list has twelve entries, and reading them tells you what the platform has already built for you.
Beyond the permission modules already described, there is user management, which covers system users as the system operators. There is an API whitelist for interfaces that do not require permission verification, which is the escape hatch for the login and public endpoints. There is dictionary management for frequently used and relatively fixed data, and region management for provinces, cities, counties and districts, which is a Chinese administrative geography data set rather than a generic region table.
There is file management, described as unified management of all files and images on the platform, and operation logs, which record and query logs for normal system operations and exceptional system information.
The twelfth entry is the plugin market, a place for applications and plugins developed on top of the framework, hosted on the project's community site. The README marks the plugins market section as still updating, which is worth knowing if you plan to depend on it.
The remaining modules are the sort of thing an internal admin needs and a public application does not: the whole set is built around the idea of an internal back office with operators, roles and departments.
Running the backend
The prerequisites are listed as Python 3.11.0 or newer with a stated minimum of 3.9, Node.js 16.0 or newer, MySQL 8.0 or newer which is optional since the default database is SQLite3 with support for 5.7 and a recommendation of 8.0, and Redis which is also optional.
The backend setup sequence is:
4. install pip dependence
5. Execute the migration command:
6. Initialization data
7. Initialize provincial, municipal and county data:
8. start backendwith the pip install, the migration commands, the two initialisation commands and the runserver filling in the numbered lines. The two management commands do separate jobs: init creates the baseline data including the superadmin account, and init_area loads the provincial, municipal and county records that back the region management module.
The development server is started with `python3 manage.py runserver 0.0.0.0:8000`, and an ASGI option is given as well, using uvicorn with the application.asgi:application path, a port of 8000, a host of 0.0.0.0 and eight workers. The API documentation is served by the backend, with the default address given as http://localhost:8080.
The demo credentials are published in the README, superadmin with the password admin123456, for both the online demo and the local instance.
The frontend and the docker compose stack
The frontend lives in a web directory and uses Yarn:
# clone code
git clone https://gitee.com/huge-dream/django-vue3-admin.git
# enter code dir
cd web
# install dependence
npm install yarn
yarn install --registry=https://registry.npm.taobao.org
# Start service
yarn run devwith the note that the dev server listens on http://localhost:8080 and that boot port parameters are configured in the .env.development file. The production build is a commented-out yarn run build line in the same block.
The docker-compose file is more substantial and shows the intended deployment shape. There are four services: dvadmin3-web, which builds the frontend Docker image, publishes port 8080 and mounts an nginx configuration and the backend media directory, with a fixed IP of 177.10.0.11; dvadmin3-django, which builds the backend image, depends on the MySQL service, mounts the backend source and a logs directory, and exposes 8000; dvadmin3-mysql, which runs mysql:8.0 with the default authentication plugin set to mysql_native_password, a max connections of 1000, and long wait and interactive timeouts of 31536000 seconds, with the database named django-vue3-admin; and dvadmin3-celery, a fourth service for background work.
The compose commands in the README are the standard lifecycle, docker-compose up -d, then the initialisation commands run inside the container with docker exec, then down, restart, or up -d --build to rebuild. The frontend is served at http://127.0.0.1:8080 and the backend at http://127.0.0.1:8080/api, and the README notes to replace 127.0.0.1 with the server's own public address when deploying.
Where the project lives and who maintains it
The source is hosted in two places, and the README is explicit about which is primary. Gitee is listed as the main push location and GitHub as the secondary mirror, and the framework introduction links the Gitee repository directly for the clone command used in the frontend setup. The project description in the repository topics names django, django-rest-framework, dvadmin, fast-crud, vue3 and crud.
The documentation lives on a separate site at django-vue-admin.com, with a live demo at demo.dvadmin.com, a community forum and the plugin market at bbs.django-vue-admin.com. Communication happens through the forum, the plugin market and a QQ group.
The branch structure is conventional: master is the stable version and develop is the development branch, and the repository has a CHANGELOG, a LICENSE, a NOTICE file and both English and Chinese READMEs.
The release history is the part that deserves attention. The tagged releases are v3.0.0 on 2023-11-30 and v3.0.1 on 2024-01-01, while the last push to the repository was on 2026-09-17. So there is a large gap between the last release tag and the current state of the code, and the README also notes a licence badge that says MIT on the Gitee link while the licence field on the repository reads Apache-2.0.
Those two facts together are worth resolving before you build on it: which licence applies, and whether you should be tracking the master branch or waiting for a release.
Where django-vue3-admin is the wrong choice
The first limitation is that this is an admin console framework, not an application framework. Everything in the core function list, departments, roles, menus, button flags, dictionaries and provincial region data, is aimed at an internal back office. If you are building something customer-facing, the value of the platform drops sharply, because none of it applies to a public site.
The second is the column level permission model, which is the feature that attracts teams and the one that costs the most to own. Fine-grained column permissions are useful for a back office where different roles need different views of a customer record. They also mean every API response has to be filtered by the caller's permissions, every table needs a permission configuration, and a mistake in that layer leaks data silently rather than erroring. A platform with fewer permission knobs is easier to reason about, and a team that does not have a real requirement for column granularity is carrying complexity for nothing.
The third is the workflow shape. The primary source is a Gitee repository, the documentation site and community are Chinese, the region data is Chinese administrative geography, and the frontend install instructions point at the taobao npm registry. For a team outside China that means an extra mirror or proxy in the build, and it means the README is not the whole documentation.
The alternative worth comparing is a plain Django admin plus Django REST Framework, which gives you the same CRUD for internal use with none of the permission machinery, at the cost of the Vue 3 interface and the column control. For a small internal tool that is a serious option. The platform earns its place when you have many internal roles, many screens, and someone who will maintain the permission configuration.
Editorial conclusion
django-vue3-admin fits a team that wants to skip writing an internal admin console and start from a full RBAC skeleton with column level permissions and a Vue 3 frontend already wired up. It does not fit a product with its own design system, a team that cannot take on a framework with a Gitee-first workflow, or anyone planning to build a public facing application on top of it. Before adopting it, read the column permission model rather than the menu model, because that is where the platform differs from ordinary role based access control, decide whether the plugin market is part of your plan given the README lists it as still updating, and pin the version you start from, since the last tagged releases are v3.0.0 and v3.0.1 from late 2023 and the repository has moved on since.
Frequently asked questions
What is django-vue3-admin and what is unusual about its permissions?
It is an open source rapid development platform pairing Django and Django REST Framework with Vue 3, TypeScript, Pinia, Vite and Element Plus. Its RBAC model reaches down to individual table columns through field column permission control, alongside the usual menu, role, button and interface permissions, and it uses SimpleJWT for multi-terminal authentication.
How do I start the django-vue3-admin backend?
Copy ./conf/env.example.py to ./conf and rename it env.py, configure the database there, install the pip dependencies with `pip3 install -r requirements.txt`, then run `python3 manage.py makemigrations`, `python3 manage.py migrate`, `python3 manage.py init`, `python3 manage.py init_area` and finally `python3 manage.py runserver 0.0.0.0:8000`.
Which databases and services does django-vue3-admin need?
Python 3.11 or newer and Node.js 16 or newer are required. MySQL 8.0 is optional because the default database is SQLite3, and Redis is optional too. The docker-compose stack runs MySQL, a Django service, a Celery service and an nginx-fronted web service on a fixed internal network.
Which branches and releases does django-vue3-admin have?
The master branch is the stable version and develop is the development branch. The tagged releases are v3.0.0 from 2023-11-30 and v3.0.1 from 2024-01-01, and the source is pushed primarily to Gitee with a GitHub mirror, so the two hosts may differ in what they carry.
What modules come with django-vue3-admin out of the box?
Menu management, department management, role management, button permission control, field column permission control, user management, an API whitelist for endpoints that skip verification, dictionary management, region management covering provinces, cities, counties and districts, unified file management, and operation logs, plus a plugin market for framework-based plugins.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/huge-dream-django-vue3-admin)Was this useful?