# RuoYi-Vue: a Spring Boot and Vue admin scaffold with a code generator at its centre

> RuoYi-Vue is an MIT-licensed, front-end/back-end separated permission management system built on Spring Boot, Spring Security, JWT and Vue. Its real draw is the generator that turns a database table into Java, Vue, XML and SQL files, but the front end living in separate repositories is the part that catches people out.

**yangzongzhuan/RuoYi-Vue** — :tada: (RuoYi)官方仓库 基于SpringBoot，Spring Security，JWT，Vue & Element 的前后端分离权限管理系统，同时提供了 Vue3 的版本

- Repository: https://github.com/yangzongzhuan/RuoYi-Vue
- Website: http://ruoyi.vip
- Stars: 3,228 · Forks: 1,707
- Language: Java
- License: MIT
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/yangzongzhuan-ruoyi-vue

## The problem RuoYi-Vue solves, and for whom

Almost every internal business system needs the same first two weeks of work: a user table, a role table, a menu tree, a login flow, a way to hide a button from the wrong person, and an operations log. RuoYi-Vue ships that layer already assembled. The README describes it as a rapid development platform that is fully open source and free for individuals and enterprises, built on Spring Boot, Spring Security, Redis and JWT on the server and Vue with Element on the client.

The target reader is a Java team starting an admin-facing product, not a library author. The built-in feature list is the giveaway: user, department, position, menu, role, dictionary and parameter management, notifications, operation and login logs, online users, scheduled tasks, code generation, API documentation, service and cache monitoring, an online form builder and connection pool monitoring. Eighteen items, and none of them is a novel idea. The value is that they already exist and already talk to each other.

The second audience is teams that need more than a web console. The README states the JWT token authentication supports multi-terminal access from web, app and mini-program clients, which matters if the same permission model has to serve a mobile app later.

One caveat belongs here. The README is written primarily for a Chinese-speaking audience and points at http://doc.ruoyi.vip for documentation. If your team cannot read that documentation, you are adopting a framework whose written guidance you cannot fully use, and you will be reading source instead.

## How the permission model and code generator actually fit together

The repository is a multi-module Maven project. The top level contains ruoyi-admin, ruoyi-common, ruoyi-framework, ruoyi-generator, ruoyi-quartz, ruoyi-system, plus sql/, bin/, doc/, pom.xml, ry.bat and ry.sh. That layout tells you the architecture without running anything: ruoyi-admin is the entry point, ruoyi-framework holds the security and web plumbing, ruoyi-system holds the business modules, and ruoyi-generator and ruoyi-quartz are separable concerns.

Authentication is stateless. Spring Security handles the filter chain, JWT carries the identity, and Redis backs the token state. That combination is why the README can claim multi-terminal access: there is no server-side session to share, so a web client, an app and a mini-program can all present the same token type.

Authorization is menu-driven. The menu management module configures menus, operations and button permission identifiers, and the role module assigns menus to roles and scopes each role's data range by organisation. The README describes this as dynamic permission menus with fine-grained control down to the button level. In practice that means the permission model is data, not code, and an administrator can change what a role sees without a redeploy.

The generator is the piece that saves the most time, and it is also the piece most likely to be misunderstood. According to the README, it generates front-end and back-end code (Java, Vue, XML, SQL) from a table and supports CRUD download. It is a scaffolding tool, not an ORM. It writes files you then own and edit. Nothing in the README suggests it re-generates over your edits or keeps generated code in sync with later schema changes, so treat the output as a starting point that immediately becomes your code.

## Installing RuoYi-Vue and generating your first CRUD module

The README does not contain a step-by-step install section. It gives the repository layout, the branch table, the demo credentials admin/admin123 and a documentation link at http://doc.ruoyi.vip, and it says the SQL scripts live in the sql/ directory. Anything below the level of branch selection has to come from that documentation, so what follows is the shape of the setup rather than a verified transcript.

The first decision is the backend branch, because it determines your JDK. The README's branch table states that master is Spring Boot 4.x on JDK 17 or newer, springboot3 is Spring Boot 3.x on JDK 17 or newer, and springboot2 is Spring Boot 2.x on JDK 8 or newer. Pick before you clone. The README gives the repository address as https://gitee.com/y_project/RuoYi-Vue, and ry.bat and ry.sh at the top level are the scripts the project ships for starting it on Windows and on Linux or macOS respectively.

Next, load the schema. The sql/ directory at the repository root holds the scripts the application expects; the README names the directory but not the individual files, so read what is in there before executing anything.

The front end is not in this repository. The README's front-end table lists RuoYi-Vue2 (Vue 2, JavaScript, Vue CLI, Element UI, Vuex, Vue Router 3), RuoYi-Vue3 (Vue 3, JavaScript, Vite, Element Plus, Pinia, Vue Router 4) and RuoYi-Vue3-TypeScript (Vue 3, TypeScript, Vite, Element Plus, Pinia, Vue Router 4), each in its own repository. The README also states the back end and front end can be mixed and matched freely, so a Spring Boot 3 back end with the Vue 3 front end is a supported combination.

Once both halves are running, the first real task is the generator. Point it at a table, let it produce the Java, Vue, XML and SQL files, download the CRUD output, drop it into the project, and restart. The README states the generator produces exactly those four artifact types and supports CRUD download; it does not document what happens if you regenerate over modified files.

## Where RuoYi-Vue is the wrong choice

The front-end split is the sharpest limitation. Three front-end repositories, one back end. The README's own table says of RuoYi-Vue2 that its maintenance focus has already shifted, and describes RuoYi-Vue3 as the officially promoted active version. If you standardise on Vue 2 because your team knows it, you are standardising on the branch the project has publicly deprioritised. That is a deliberate trade-off by the maintainers, not an accident, but it is your risk to carry.

Branch sprawl is the second issue. Three backend branches and three front-end repositories means six moving pieces, and a fix applied to springboot2 does not automatically appear on master. The README presents parallel maintenance as a feature. It is also a multiplication of the surface you have to track when you upgrade.

The generator has a boundary the README never draws. It emits CRUD scaffolding. It does not describe generating workflow or approval logic, and nothing in the README suggests it handles multi-table transactions or domain rules. Teams that read "code generator" as "application generator" will be disappointed at the second screen.

Finally, the documentation is Chinese-first. The README, the demo, the QQ group list and the documentation link all assume a Chinese-reading audience. For a team that does not have one, the effective documentation is the source tree, and that changes the adoption cost considerably. Nothing in the README claims an English documentation set exists.

## Alternatives and the difference in approach

The related searches around this project name several adjacent products, and the naming is genuinely confusing. RuoYi-Vue Plus, RuoYi-Vue Pro and RuoYi-Vue3 are distinct projects with distinct maintainers and repositories; they are not branches of this one. The README of yangzongzhuan/RuoYi-Vue links only to RuoYi-Vue2, RuoYi-Vue3 and RuoYi-Vue3-TypeScript, all under the same author. If you arrived here looking for Plus or Pro, you are in the wrong repository.

The more useful comparison is against the general-purpose Java admin scaffolds, and the difference is one of philosophy. A Spring Boot plus Vue scaffold typically hands you a login page, a layout and a router, and leaves the permission model to you. RuoYi-Vue hands you a data-driven permission model: menus, roles, departments and button identifiers stored in tables and edited through the UI. That is more opinionated and more immediately useful, and it is harder to swap out later if your authorisation model does not map onto menu trees and organisational data scopes.

The front-end split is the other axis. Most scaffolds assume one front end. RuoYi-Vue treats the front end as a swappable component with three published variants, which is unusual and useful precisely because Vue 2 to Vue 3 migration is the problem most teams are currently living with. You can keep the back end and change the front end without touching the server.

What RuoYi-Vue does not offer is a lighter footprint. Eighteen built-in modules, Quartz, Redis and a connection pool monitor come as a package. If you want a minimal Spring Boot service with a handful of endpoints, this is more machinery than the problem requires.

## Maintenance cadence, licence and upgrade cost

The repository is not archived, and the last push was on 2026-08-26. The most recent release listed is v3.9.2 on 2026-03-26, preceded by v3.9.1 on 2025-12-17 and v3.9.0 on 2025-05-28. That is roughly one minor release per six months, with commits landing between releases.

The branch table is the real upgrade story. Spring Boot 2.x, 3.x and 4.x are maintained in parallel, which means an upgrade is a branch change rather than a version bump. Moving from springboot2 to springboot3 is not a dependency edit; it is a different codebase with a different baseline JDK, and your own modifications have to be carried across. The README documents that these branches exist but does not document a migration path between them, and it does not document rollback. Budget for a re-application of your customisations, not a merge.

The licence is MIT. That is permissive: it allows commercial use, modification and redistribution provided the copyright notice and permission notice are retained. The README separately states the platform is fully open source and free for individuals and enterprises. MIT is a well-understood licence and this is not legal advice, but note that the README also carries Alibaba Cloud and Tencent Cloud promotional links, which are commercial arrangements unrelated to the licence terms. If your organisation has a policy on vendor links inside dependencies, that is a question for your legal team, not for the source code.

## Conclusion

Adopt RuoYi-Vue if you are a Java team that needs a working admin shell, JWT login, menu and button-level permission control, and generated CRUD code within days rather than months. Do not adopt it if you need a Vue 2 front end guaranteed to receive the same attention as the Vue 3 line, or if you expect a single repository to contain everything. Before committing, confirm which backend branch matches your JDK, check that the front-end repository you pick is the one the README points to, and read the sql/ directory to see what the schema expects.

## FAQ

### Does RuoYi-Vue include the Vue front end in the same repository?

No. The back-end repository contains the Java modules, and the README lists three separate front-end repositories: RuoYi-Vue2 for Vue 2, RuoYi-Vue3 for Vue 3 with JavaScript, and RuoYi-Vue3-TypeScript for Vue 3 with TypeScript. The README states the back end and front end can be mixed and matched freely.

### Which Java version does RuoYi-Vue need?

It depends on the branch. The README's branch table states that master is Spring Boot 4.x on JDK 17 or newer, springboot3 is Spring Boot 3.x on JDK 17 or newer, and springboot2 is Spring Boot 2.x on JDK 8 or newer.

### What does the RuoYi-Vue code generator produce?

The README states it generates front-end and back-end code in Java, Vue, XML and SQL, and that it supports CRUD download. It is a scaffolding tool whose output you then own and edit.

### How do you try RuoYi-Vue without installing it?

The README gives a demo at http://vue.ruoyi.vip with the credentials admin/admin123. The documentation is linked at http://doc.ruoyi.vip.

## Sources

- [License: MIT](https://github.com/yangzongzhuan/RuoYi-Vue/blob/master/LICENSE)
- [Project website](http://ruoyi.vip)
- [README](https://github.com/yangzongzhuan/RuoYi-Vue/blob/master/README.md)
- [Releases](https://github.com/yangzongzhuan/RuoYi-Vue/releases)
- [yangzongzhuan/RuoYi-Vue on GitHub](https://github.com/yangzongzhuan/RuoYi-Vue)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/yangzongzhuan-ruoyi-vue
