RuoYi-Vue-fast is the single application edition of the RuoYi admin scaffold

One application instead of the full RuoYi deployment

RuoYi is a family of Java and Vue admin frameworks, and this repository is a specific member of it. The README states that this repository is the single application version of RuoYi-Vue and is kept updated in step with it. The description line calls it the official RuoYi repository, a separated front end and back end permission management system built on SpringBoot, Spring Security, JWT, Vue and Element.

That single application framing is the first decision to make. A separated front end and back end system with a shared admin layout is a different deployment shape from one where the whole thing runs as one deployable unit, and the choice determines how you configure the gateway, where your session state lives and how you roll out a change. The README is explicit that this repository is the single application variant, so the two are not interchangeable and picking the wrong one is an expensive mistake.

The stack is mainstream and the topic tags confirm it: spring, springboot, springsecurity, jwt, redis via the druid and quartz tags, mybatis on the server side, and vue, element, element-ui, axios, vuex and vue-cli on the client side, with swagger2 for API documentation. The primary language of the repository is Java, the licence is MIT, and the project home is ruoyi.vip.

The audience is developers building an internal back office: an operations console, a content management system, an order or inventory tool. The value proposition is that the boring, mandatory parts of an admin system are already written.

JWT token authentication with button level permissions

The permission model is where an admin framework either earns its place or does not, and this one is specific about it.

Authentication is JWT based. The README lists Spring Security and Redis alongside JWT on the back end, and states that token authentication based on JWT supports seamless access from multiple terminals, naming Web, App and mini program clients. The practical consequence is that the same login endpoint serves a browser console, a phone app and a mini program, and the server does not care which one is talking to it. Redis is the piece that makes that work in practice, holding the token state so a session can be invalidated rather than living until the token expires.

Authorisation is dynamic rather than static. The system supports loading dynamic permission menus, with permission control done in multiple ways, down to the granularity of individual buttons. That is a meaningful claim: many admin templates ship role based menu visibility but leave the actual button level check to the front end, which is a UI convenience rather than a control. Here the menu tree itself is loaded per user, and the button level identifiers are part of the menu configuration, since the menu management module is described as configuring system menus, operation permissions and button permission identifiers.

The role module is where the model becomes concrete. Roles get menu permission assignments, and roles are also given a data scope division by organisation, so the same role can see different rows depending on which department tree branch it is attached to. Department management exists to configure the organisation structure, shown as a tree, and supports data permissions. That pairing of a role with a data scope is the mechanism behind row level filtering, and it is the part of the framework that takes real thought to configure for a specific organisation.

Eighteen built in modules, including a code generator

The built in feature list is long, and it is the clearest picture of what you get for free. User management handles system user configuration. Department management builds the organisation tree. Post management assigns job positions to users. Menu management covers menus, operation permissions and button permission identifiers. Role management assigns role menu permissions and data scopes. Dictionary management maintains the fixed lookup data the system uses. Parameter management holds dynamic configuration. Notice management publishes announcements. Operation logs record and query normal operations, and separately record and query exception information. Login logs record login activity including failed logins. Online users monitors the state of currently active users.

The scheduled task module manages job scheduling online, with add, modify and delete, and keeps execution result logs. The code generation module produces front end and back end code, in java, html, xml and sql, with the generated CRUD available for download. The system interface module generates API documentation from the business code. Server monitoring watches CPU, memory, disk and heap. Cache monitoring queries cache information and command statistics. The online builder lets you drag form elements to generate the corresponding HTML. The connection pool monitor watches the database connection pool state and can analyse SQL to find performance bottlenecks.

The code generator is the module with the highest leverage. Generating the java entity, the mapper, the service, the controller, the vue page and the SQL for a table, then downloading that as a CRUD skeleton, is the difference between a week of boilerplate and an afternoon. The catch is that the generated code is opinionated, so the second thing to do after generating is to agree where your own conventions start.

Branch and front end choices you have to make up front

The version table in the README is the part that determines whether your build works on day one, and it is easy to skim past because it describes the wider RuoYi-Vue family rather than this repository alone.

On the server side there are parallel maintained branches. The master default branch is Spring Boot 4.x with JDK 17 or above. The springboot3 branch is Spring Boot 3.x with JDK 17 or above. The springboot2 branch is Spring Boot 2.x with JDK 8 or above. So the framework supports three generations of Spring Boot at once, and choosing the branch is choosing the runtime baseline. A team on JDK 8 and an existing Spring Boot 2 estate would use the springboot2 branch, while a team starting fresh would take master and its JDK 17 floor.

On the client side the front end comes in three flavours, and the README says they can be mixed and matched. RuoYi-Vue2 is Vue 2 with JavaScript, built with Vue CLI, using Element UI, Vuex and Vue Router 3. RuoYi-Vue3 is Vue 3 with JavaScript, built with Vite, using Element Plus, Pinia and Vue Router 4. RuoYi-Vue3-TypeScript is Vue 3 with TypeScript, Vite, Element Plus, Pinia and Vue Router 4, positioned for enterprise team development where type hints reduce communication cost.

Here is the catch that the tables make easy to miss. The front end is not in this repository. The three front end projects live in their own repositories, RuoYi-Vue2, RuoYi-Vue3 and RuoYi-Vue3-TypeScript, so adopting this repository means adopting one of those alongside it. And the README's own note on the Vue 2 column says the current maintenance focus has already moved away from it, with Vue 3 described as the actively promoted version, which is a signal to start there unless you have a Vue 2 constraint.

Trying it and running it locally

The README documents no install commands, and the fastest way to see the system is the online demo, which it lists with a fixed credential pair:

admin/admin123

The demo address is vue.ruoyi.vip and the documentation is at doc.ruoyi.vip. The README also notes that the demo server was upgraded with donated funds, which is a small but real signal about who runs it and how much to trust it with production data.

For a local run, the top level of the repository is where the moving parts are. There is a pom.xml for the Maven build, src/ for the Java sources, sql/ for the database scripts, doc/ for documentation, bin/ for build and deployment helpers, and two start scripts, ry.sh and ry.bat, which are the Unix-like and Windows entry points for the application. The SQL folder is the piece to look at first, because an admin system with users, roles, menus, dictionaries and parameters needs its schema and seed data in place before anything renders.

A realistic first session is: read the SQL, create the schema, start the application with the packaged script, log in with the seeded administrator account, then open the code generator and point it at a table of your own. The last step is where you find out whether the generated code fits your conventions.

Licence, maintenance and the limits of a Chinese first project

The licence is MIT, which means you can modify the framework, ship it inside a commercial product and keep the licence text, and that is the easiest part of the decision.

The maintenance signals are mixed in a way that is worth separating. The repository is not archived and the last push was on 2026-08-26. The releases are v3.9.2 from 2026-03-26, v3.9.1 from 2025-12-17 and v3.9.0 from 2025-05-28, which is a steady release cadence for an admin framework and a version number that has been public for a while. The parallel Spring Boot branches are actively kept, which is unusual and useful.

The real limit is the language and the shape of the deliverable. The README, the documentation site and the interface itself are Chinese, and there is no English documentation in this repository. For a team that reads Chinese, that is a non issue. For a distributed team that does not, it means every menu name, every validation message and every configuration key is something you will be translating, and the operational knowledge of the framework lives in a community you may not be part of.

The second limit is architectural, and it is the one you should think about before you build. This is a system built around a menu tree, a role and a data scope, with the front end delivered as a separate project that you have to assemble and keep in step. That is a good fit for a back office with conventional CRUD screens. It is a poor fit if what you need is an API first service consumed by several clients, or a multi application deployment where the single application shape is the wrong starting point.

Editorial conclusion

Adopt RuoYi-Vue-fast if you need a Chinese language RBAC admin console with user, department, role, menu, dictionary, audit, scheduled task and code generation modules already written, and pick the branch and front end variant that match your JDK and Vue plan before you start, since master is Spring Boot 4.x while the springboot3 and springboot2 branches carry the older runtimes. Do not adopt it if your team needs an English interface, a multi application deployment or a modern API first architecture. Verify the local start path with ry.sh or ry.bat and the sql/ folder against your database before you build on the code generator, and note that the last push was on 2026-08-26 with the newest release v3.9.2 from 2026-03-26.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. yangzongzhuan/RuoYi-Vue-fast on GitHub