RuoYi-Vue-Plus: a multi-tenant admin backend for distributed clusters

The problem RuoYi-Vue-Plus solves, and who it is aimed at

RuoYi-Vue is a long-standing Chinese admin scaffold, and RuoYi-Vue-Plus is a rewrite of it aimed at distributed clusters rather than a single node. The README states the project is "重写 RuoYi-Vue 针对 分布式集群 场景全方位升级(不兼容原框架)", which is the sentence that decides whether you are in the target audience. The incompatibility is deliberate: the project is not a drop-in upgrade path for an existing RuoYi-Vue deployment, it is a parallel codebase with a different permission stack, a different ORM usage pattern and a different web container.

The audience is teams building an internal or commercial admin system that will run behind more than one application instance, that needs tenant isolation from the start, and that would rather assemble a backend from a documented scaffold than wire Sa-Token, MyBatis-Plus, Redisson and OSS clients together by hand. The README also lists a single-tenant variant maintained outside the core repository, RuoYi-Vue-Plus-Single, which removes multi-tenancy and workflow; if you do not need either, that is a signal the core project carries weight you would be paying for anyway.

It is not aimed at teams who want a library. This is an application skeleton: you clone it, rename packages, and build on top. The MIT licence permits commercial use, and the README states the code and documentation are free to use commercially provided the licence file is retained in the project.

What the module layout and the README's comparison table actually commit to

The repository root shows the shape of the thing: ruoyi-admin, ruoyi-api, ruoyi-common, ruoyi-extend and ruoyi-modules, plus a script directory and the Maven wrapper. The README describes the backend structure as "插件化 + 扩展包形式", plugin-oriented with extension packages, and contrasts that with RuoYi, which it calls mutually injected and hard to extend. In practice that means business modules depend on common modules rather than on each other, and cross-module calls go through the api module.

The substantive swaps are listed in the README's comparison table. Jetty replaces Tomcat as the web container. Sa-Token replaces Spring Security, and the README claims its annotations cover login, role, permission, second-level authentication, HTTP Basic and ignore checks, with AND, OR and role-or-permission expressions; RuoYi's are described as existence checks only. MyBatis-Plus replaces hand-written MyBatis XML, with pagination, optimistic locking and a data-permission plugin that the README says rewrites SQL transparently from mapper annotations. Redisson replaces Lettuce plus RedisTemplate, and the README notes that keys commands are converted to scan.

Two entries deserve a second look because they are easy to misread. The data-permission plugin is described as analysing and appending SQL without the caller writing it, which is convenient but means the SQL that reaches your database is not the SQL in your mapper. And the interface encryption entry, dynamic AES plus RSA over the request body with a fresh key per request, is a real mechanism with a real cost in debugging and in interoperability with any client that is not the bundled frontend. The README does not document how to disable it per route.

Installing RuoYi-Vue-Plus and running the backend for the first time

The README does not contain a step-by-step install block. It points to the documentation site at plus-doc.dromara.org, with a mainland accelerator at plus-doc.top, and the demo system is linked from the same README. The repository root does contain mvnw and mvnw.cmd, and the documentation site is where the project explains datasource, Redis and SQL script setup.

The build tooling the repository ships is the Maven wrapper at the root, alongside the top-level pom.xml. The JDK version to use is the one shown in the README badges: Spring Boot 4.1 with JDK 21 or JDK 25. Check `java -version` before you start rather than after the first compile error.

The runnable artifact is the admin module, ruoyi-admin, which is where the Spring Boot entry point lives. The README does not document the default port, the datasource keys or the Redis connection settings, so take those from the documentation site at plus-doc.dromara.org rather than guessing at application.yml values. The same applies to the SQL scripts: there is a script directory at the root, and the documentation is where the project explains what to execute and in what order.

The frontend is a separate repository. The README lists the Vue plus ElementPlus frontend and a React plus Ant Design variant, both maintained as their own projects, plus member frontends built on vben5 and soybean. Cloning the backend alone gives you an API, not a UI.

Where RuoYi-Vue-Plus is the wrong tool

The clearest limitation is stated by the project itself: the rewrite is not compatible with RuoYi-Vue. If you have an existing RuoYi-Vue codebase with custom modules, the README offers no migration path, and the permission annotations, the ORM style and the container have all changed. You are porting, not upgrading.

The second is the version cadence. The release history shows v5.6.1 in April 2026, v5.6.2 in June 2026, and v6.0.0 in July 2026, which the release title calls a major release. A major version in an application scaffold usually means the 5.x line and the 6.x line differ in ways that matter to anyone who has customised the framework internals. If your team depends on patching framework classes directly, expect that work to be redone at each major.

The third is environmental. JDK 21 or JDK 25 per the badges, Redis 6 or later, and a relational database from the set the README lists. That is a modern stack, and it is fine for a new internal system. It is a poor fit if you are required to deploy onto an older runtime, or if your organisation's Redis is a managed service pinned below version 6.

Finally, the README's comparison table is written from the project's point of view. Claims such as RuoYi's connection pool having frequent bugs, or Spring Security having poor extensibility, are the maintainer's characterisation, not a measured result. Read the table as a list of what changed, not as a verdict on the alternative.

RuoYi-Vue-Plus and RuoYi-Vue-Pro: two different answers to the same question

The most likely alternative you will weigh is RuoYi-Vue-Pro, and the difference is architectural rather than cosmetic. RuoYi-Vue-Plus takes the RuoYi-Vue lineage and rebuilds it around a plugin-oriented multi-module layout, Sa-Token for authentication, MyBatis-Plus for persistence and Jetty as the container, with multi-tenancy and workflow present in the core project. RuoYi-Vue-Pro is a separate codebase that grew from the same RuoYi ancestry but made its own choices about modules and about how much it bundles.

If you are already committed to Sa-Token and MyBatis-Plus, RuoYi-Vue-Plus keeps you in that idiom end to end, including the data-permission and data-translation plugins that are implemented as MyBatis-Plus and Jackson extensions. If your team's existing code and habits are elsewhere, RuoYi-Vue-Pro is worth reading before you commit, because the cost of switching later is the same porting cost the README already warns about for RuoYi-Vue.

A second alternative is the project's own single-tenant sibling, RuoYi-Vue-Plus-Single, which the README lists as a member project with multi-tenancy and workflow removed. If you want the stack but not the tenant machinery, that is a smaller surface to learn and to keep patched. Note that it is a member project, not the core repository, so its release cadence is not the one shown in the release list above.

Maintenance, licence and the cost of staying current

The repository is not archived, and the last push was on 2026-09-24, which is days before this writing. Releases arrive on a roughly two-month rhythm in the recent history, with dependency upgrades and vulnerability fixes appearing as their own releases, as the v5.6.1 title indicates. That is a project that is being pushed to, and the practical consequence for you is that dependency bumps arrive whether or not you are ready for them.

The upgrade cost is concentrated in two places. Major versions, such as the move to 6.0.0, are where framework-level customisation breaks. Dependency releases, such as 5.6.2, are usually mechanical but still require you to re-run your own integration tests against a new Spring Boot and Sa-Token combination. If you fork the framework internals rather than extending through the extension packages the README describes, you have chosen the more expensive of the two paths.

The licence is MIT, stated in the LICENSE file at the repository root and shown in the README badge. MIT is permissive: it allows commercial use and modification, and it requires that the copyright notice and licence text be preserved. The README repeats this in its own words, saying the code and documentation are free to use commercially as long as the licence file is retained. That is a statement about the project's own code. It says nothing about the licences of the dependencies you pull in, and nothing about the frontend repositories, which are separate projects with their own licence files. Check those individually before you ship; this is a description of what the repository states, not legal advice.

Editorial conclusion

Adopt RuoYi-Vue-Plus if you need a multi-tenant admin backend on JDK 21 or 25 and accept that it is incompatible with RuoYi-Vue, so existing RuoYi code will not drop in. Do not adopt it if you need a stable API surface, since the project ships major releases that change that surface, or if you run on JDK 17 or 11. Before starting, verify the exact JDK, Redis and MySQL or PostgreSQL versions your deployment target supports against the documentation at plus-doc.dromara.org, because the README states the stack requirements but the repository does not pin a deployment matrix.

Frequently asked questions

Official sources

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