django-vue-admin: a Django and Vue admin skeleton with RBAC already wired

A starter kit, described honestly as a skeleton

The project presents itself as a front end and back end separated admin platform built on an RBAC permission model, and it says plainly that it is suited as a development skeleton for small and medium business systems. That framing matters more than usual for a project of this kind, because the code you get is the code you maintain.

The stack is conventional and specific. The back end is Django with Django REST Framework, the web front end is Vue 2 with Element UI, and a separate mobile directory carries an implementation built on uni-app and uView, published as an H5 site or as a mini program. The README is written in Chinese, and the pinned versions are listed: Django 4.2.27, Django REST Framework 3.14.0, Simple JWT 5.5.1, django-celery-beat 2.5.0, django-simple-history 3.4.0 and drf-yasg 1.21.7, with Redis in the back end, and Vue 2.6, Element UI 2.15, Vue Router 3, Vuex 3 and Axios 1.6 on the front.

The repository layout is three directories, client/ for the web admin, client_mp/ for the mobile implementation, and server/ for the Django code, with a docker-compose.yml at the root. A specification.md sits at the top level as well, which is where a project like this would describe its API contract.

The licence is MIT, which still requires keeping the copyright and licence notice.

Permissions are enforced twice, and only one of them counts

The access control design is the part of the project with the most substance, and the README describes it in a way that deserves care. The project uses front end routes plus back end permission codes. In the router configuration the front end uses fields such as meta.perm to decide which pages and buttons to show, and the back end checks the user's permission codes at the API layer with RbacPermission.

The data layer is handled separately, in has_object_permission, where the project implements a set of basic rules and expects you to extend them for your own business. The rule set the README lists is the familiar one for Chinese admin systems: all data, the current level and below, the same level and below, and the person's own records. That last rule is the one that usually decides whether the skeleton fits your business, because it encodes an org tree where a manager can see a subtree and a person can see themselves.

The three files that matter are named in the README, and they are worth reading before you accept the model. The back end permission class is at server/apps/system/permission.py, the front end guard is client/src/permission.js, and the front end route and permission generation lives in client/src/store/modules/permission.js.

The honest reading is that the browser-side check is a convenience for the user interface, and the API-side check is the one that decides whether a request is allowed. A deployment that only wires up the front end has no permissions at all.

The module list is the actual feature list

Rather than describing capabilities in prose, the project lists the modules it ships, and that list is a good summary of what you get.

There is organisational structure, user management, role management, post management, permission management, a data dictionary, a file library, scheduled tasks, a workflow and system monitoring. On top of that sit a handful of platform features: JWT authentication using djangorestframework-simplejwt by default, audit trails that can be combined with django-simple-history, scheduled jobs through Celery with django-celery-beat, and an interface documentation page built in with Swagger through drf-yasg.

The workflow module is the one with a caveat attached to it, and the caveat is stated twice. It follows the ideas of loonflow but is a simplified implementation, with the back end code in server/apps/wf. The README advises that if you need stable use of the complex workflow capability, PostgreSQL is the better choice, and that SQLite is fine for a preview or a light trial but leaves some JSON query capability limited.

That is a real constraint rather than a caveat in the documentation sense. If your workflow depends on querying inside JSON fields, the SQLite path will not carry it.

For larger ambitions, the README points at a related project, xt_server, which rewrites the same back end with more complete permission control, a workflow engine, operations management and WebSocket support.

Running the back end: a venv, migrations, and a database file in the repo

The requirements are listed up front: Python 3.10 or newer is recommended, Node.js 16 or higher, Redis 6 or newer if you intend to use the scheduled tasks, and PostgreSQL if you want the full workflow module.

The back end is a standard Django project in server/. You create a virtual environment, install the pinned requirements, and on Windows you activate it with the Scripts path.

python -m venv venv
.\venv\Scripts\activate
pip install -r requirements.txt

Database settings and the debug flag are read from server/server/conf.py, and conf_e.py next to it is the template to copy when you first initialise a configuration. Then the standard Django steps: migrate, optionally load the seed data, and create a superuser.

python manage.py migrate
python manage.py loaddata db.json
python manage.py createsuperuser

The seed load is optional, and the README notes that the repository already contains server/db.sqlite3, so you can run the project locally against the bundled file without setting up a database server at all. That is the fastest way to see the project, and it is also the moment to decide whether you are going to run on PostgreSQL, because the workflow module's behaviour differs between the two.

The development server is then started on port 8000.

python manage.py runserver 8000

The front end, the API address and the three URLs that matter

The web admin lives in client/ and is a Vue 2 project. The README gives the install command with an explicit registry mirror, and the dev script serves the application.

npm install --registry=https://registry.npmmirror.com
npm run dev

Three addresses come out of that. The front end development server usually runs on port 9528, and in the default development configuration it calls the API at http://localhost:8000/api, which is the Django server you started on 8000. If you front the front end with Nginx, everything is reachable on a single port, 8012, with a small configuration that proxies media to the back end and everything else to the Vue dev server.

listen 8012;

location /media {
    proxy_pass http://localhost:8000;
}

location / {
    proxy_pass http://localhost:9528;
}

The back end also exposes two of its own pages, the Swagger interface at http://localhost:8000/api/swagger/ and the Django admin at http://localhost:8000/django/admin/. The Swagger page matters more than usual in a project like this, because it is the fastest way to see what the API surface actually looks like before you write a single line of front end code against it.

The Docker Compose file is a development setup in production clothing

The root docker-compose.yml defines three services. The backend builds from ./server, publishes port 8000 against container port 80, mounts the server directory into the container at /code and links to redis, and it sets the DJANGO_ENV environment variable to dev. The frontend builds from ./client with the development Dockerfile and publishes 8012 against 80. The third service is Redis, started with appendonly enabled.

docker-compose up -d

After that the back end answers on port 8000 and the front end on 8012, and the README shows the pattern for running a management command inside the running back end container.

docker-compose exec backend python manage.py makemigrations

The project is upfront that this file leans towards development mode and that a single machine production deployment should switch to the production image and production configuration instead. The mechanism for that is the DJANGO_ENV variable, and the compose file even carries a comment saying to remove it and rebuild the back end image for production. Read that as the boundary of the packaging work you are accepting.

The production notes list what to check: the database connection, DEBUG and host settings in server/server/conf.py, the static and media directories, the Nginx reverse proxy, and the network reachability of Redis, Celery and the database. The front end and back end can be deployed separately, or the front end can be built and its dist output dropped into server/dist to be served by the back end, followed by collectstatic. The documented Gunicorn command runs five workers on port 2251, and WebSocket support is handled with Daphne under Supervisor.

Celery, the workflow back end, and a repository that has been quiet since April

Scheduled tasks run on Celery with django-celery-beat, and they need Redis running first. The worker and the beat scheduler are separate processes, started with two commands.

celery -A server worker -l info -P eventlet
celery -A server beat -l info

The README notes that on Linux you usually do not need the eventlet pool flag, which is the kind of platform difference that otherwise shows up as a failed start on a server. The workflow back end lives in server/apps/wf, and as noted earlier it is a simplified implementation, so the database choice is part of the design rather than an afterthought.

On the state of the project, the facts are worth stating without embellishment. The repository has no GitHub releases, so there is no version to pin from a tag, and the last push was on 2026-04-08, more than six months before the date of this writing. That does not make the code unusable, and it does not make it maintained either. It means the pinned dependency versions in the README are your best guide to the state of the code, and that the audit trail you get from django-simple-history is more about your own deployment than about upstream fixes.

There is also a public demo environment listed in the README, running Django's development server with the default admin credentials, and the README asks visitors not to change that password. Treat the demo as a preview rather than as an installation guide, since a development server behind a public address is not what you want in production.

Editorial conclusion

django-vue-admin fits a small or medium business system that needs an admin console with users, roles, dictionaries, scheduled jobs and a workflow in the first week, and whose team is willing to take ownership of the code afterwards, because the value is the assembled skeleton rather than a maintained framework. It does not fit a team that wants a product with support, that needs the workflow module to be complete, or that plans to run the Docker Compose file unchanged in production. Verify three things before you build on it: that the Vue 2 and Element UI front end is still the shape your team wants, since a rewrite is a rewrite, that the permission checks in the browser and in the API are both in place in your deployment, and that the workflow module behaves as documented against PostgreSQL, because the SQLite path is explicitly described as limited.

Frequently asked questions

Official sources

1. caoqianming/django-vue-admin on GitHub
2. Issues
3. License: MIT
4. README