RuoYi-Cloud-Plus: a RuoYi-Cloud rewrite that drops the original's contracts

A rewrite, and the README says so in capitals

RuoYi-Cloud-Plus is a general purpose microservice permission management system under the Dromara organisation. Its self-description is that it rewrites all the functionality of RuoYi-Cloud with a full upgrade, and then the qualifier that decides everything: it is not compatible with the original framework.

That sentence determines how you should evaluate the project. This is not a patched RuoYi-Cloud with extra modules. It is a reimplementation that keeps the domain vocabulary, the menu-driven admin conventions and the Chinese enterprise feature set, and replaces the technical substrate almost everywhere. Anyone planning to migrate an existing RuoYi-Cloud deployment should read it as a rebuild of the platform layer, not an upgrade of it.

The stated motivation is a list of technologies integrated together: Spring Cloud Alibaba, Dubbo 3.0, Sa-Token, MyBatis-Plus, MQ, WarmFlow, Elasticsearch and Docker, with the project describing itself as synchronised with RuoYi-Cloud periodically. The middleware list is the point of the project. In the same breath the README gives the honest caveat about the author's own framing, that the code and documentation are open source, free and usable commercially provided the licence file is kept, and that the work is done out of interest and for learning.

For a reader outside the Chinese ecosystem there is an obvious limitation to name first. The README, the documentation site at plus-doc.dromara.org, the demo and the difference table are all in Chinese, and the default branch is `6.X` rather than `master` or `main`, which tells you the versioning is on a six-series scheme.

The version numbers tell the rest. v6.0.0 was tagged on 2026-07-30 with the announcement of a major release, v2.6.2 on 2026-06-17, and v2.6.1 on 2026-04-24 with the note that it covered dependency upgrades and vulnerability fixes. The last push was on 2026-10-09, so the 6.0.0 line is recent and still moving.

Nacos, Dubbo 3, Seata, Jetty and Sa-Token replace the familiar stack

The difference table in the README is where the real design decisions are visible, and it is worth reading row by row because each row is a deliberate change of component.

The service registry and the configuration centre are both Alibaba Nacos, matching the original RuoYi choice. The gateway is Spring Cloud Gateway in both, but the Plus version extends it with several added capabilities, including internal network authentication, request body caching, cross-origin configuration and request and response logging.

The RPC layer changes most sharply. Plus uses Apache Dubbo 3.X, where the original used Feign, and the README's stated reason is that Feign is limited in function, is written in a cumbersome way and is unstable under network fluctuation. Load balancing stays on Spring Cloud LoadBalancer but is extended with routing for development teams, which is a multi-team development concern rather than a generic feature.

Distributed transactions are Apache Seata in both. The web container changes: Jetty, described as a high performance container based on Netty, replaces Tomcat. That is the change most likely to surprise an existing operator, because servlet container behaviour, in particular around connection handling and headers, is not identical.

Authentication is the other big one. Sa-Token with JWT replaces Spring Security, and the README characterises the original as tedious to configure and poor to extend. The Plus version's permission annotation support is listed in detail: login checks, role checks, permission checks, secondary authentication checks, HTTP Basic checks and ignore checks, with role and permission conditions supporting compound expressions such as `AND`, `OR` or permission-or-role combinations, where the original only supported a single existence match.

The intent is a system where authorisation logic is expressed in annotations rather than in a filter chain, which is the pattern most Chinese enterprise admin frameworks converge on, and which is where Sa-Token's ecosystem strength lies.

MyBatis-Plus, Redisson and an extended Spring-Cache

The data access layer is rebuilt around MyBatis-Plus rather than MyBatis with XML, and the README contrasts the two directly: object-oriented operation with almost no hand-written SQL, and a large set of plugins, including multi-tenant, pagination and optimistic locking plugins. The original's XML-based handwritten SQL is the thing being replaced.

Two supporting pieces are worth calling out. The first is SQL monitoring. Plus ships a complete MyBatis SQL output tool that can print the full SQL, the mapper ID and the execution time, where the original only logged to output and required manually concatenating the SQL and parameters to debug a problem. For a system with hundreds of mappers, that is a real difference in day to day work.

The second is pagination. Plus uses the MyBatis-Plus pagination plugin, extended with an object-oriented pagination object, multiple ways of passing parameters, and support for multiple and complex sort orders pushed to the front end. The original uses PageHelper and, as the table puts it, supports only single-query pagination.

Caching is rebuilt too. Instead of writing Redis code by hand, Plus uses Spring-Cache annotations extended with expiry time, maximum idle time and maximum group size, so a single annotation triggers automatic caching. The underlying client is Redisson, the Redis-recommended Netty based client, which the README says supports more than 90 percent of Redis commands and optimises some incorrect usage patterns underneath, for example converting `keys` into `scan`. Redisson also covers standalone, sentinel, single master cluster and multi-master cluster modes, while the original's Lettuce plus RedisTemplate combination is described as supporting fewer modes, with a common-pool connection pool that has many bugs and causes problems frequently. Redis 6 or later is required for the distributed rate limiting and distributed queue features.

The claimed benefit of the annotation approach is that cache policy becomes declarative. The cost is that you are inside Spring's caching abstraction, so a cache configuration that the abstraction cannot express becomes something you have to work around.

Four databases natively, and heterogeneous switching

The database story is the one place where the Plus project claims a capability the original explicitly does not have.

Plus supports MySQL, Oracle, PostgreSQL and SQL Server natively, and can use them simultaneously with switching between them. The README adds that any database supported by MyBatis-Plus can be used by adding the JDBC driver, and that there are successful cases with domestic vendors such as Dameng and KingBase. The original is listed as supporting MySQL and Oracle, but not simultaneous use and not heterogeneous switching.

For organisations in markets where procurement requires a domestic database, that is the single most consequential line in the table. Switching from MySQL to a domestic database is a portability problem, and a framework that treats the choice as a configuration item rather than a rewrite changes how much that problem costs.

The honest caveat is that the support claim is broader than the test claim, and the README does not enumerate which versions of which engines are verified. The mention of successful cases with specific vendors is evidence of it having been done, not a statement of a test matrix. If a domestic engine is a hard requirement, the honest move is to run the project's own test suite against that engine before committing to it, and to check which MyBatis-Plus dialect and SQL features your own reporting queries rely on, since pagination plugins and multi-database switching both rewrite SQL.

The combination of these three layers, MyBatis-Plus for the ORM, Redisson for the cache and a switchable datasource, is what makes the feature set cohere. It is also what makes the project hard to reason about, because a bug in a paginated query under a non-default database is a three-way interaction rather than a single component issue.

One backend, several front ends, and the multi-tenant question

The front end is not in this repository, and the README lists the choices explicitly, which is unusual and useful.

The official Vue project, plus-ui, is built on Vue 3 with TypeScript and Element Plus, against the original's Vue 2 or Vue 3 with JavaScript. A React version exists as well, plus-ui-react, built on React with Ant Design. Community members maintain a vben5-based front end, ruoyi-plus-vben5, and a soybean-based one, ruoyi-plus-soybean. There is also a member project, RuoYi-Vue-Plus-Single, which removes multi-tenancy and workflow.

That last entry is worth pausing on, because it tells you something about the intended shape of the product. The full RuoYi-Cloud-Plus includes multi-tenancy and a workflow engine, WarmFlow, and both are substantial subsystems with their own data models, licence checks and menu wiring. A member has produced a variant with those removed, which suggests that a real share of deployments do not want them.

The backend structure is a plugin architecture with extension packages, described as decoupled and easy to extend, where the original has modules that inject into each other and are hard to extend. The repository layout shows the module boundaries:

ruoyi-api/
ruoyi-auth/
ruoyi-common/
ruoyi-example/
ruoyi-gateway/
ruoyi-modules/
ruoyi-visual/

The `ruoyi-visual/` module is the observability surface, the `ruoyi-auth/` module is the authentication service, `ruoyi-gateway/` is the gateway, and `ruoyi-modules/` holds the business services. The project is built with Maven, with `pom.xml` at the root and the `mvnw` and `mvnw.cmd` wrapper scripts committed, so a build does not need a locally installed Maven.

The README does not include installation or run commands, so the documentation site is the place to look for the deployment steps, and a domestic mirror at plus-doc.top is offered for faster access.

MIT licensing, a major version, and what an upgrade actually costs

The licence is MIT, and the README states that the code and documentation are open source, free and permitted for commercial use, provided the open source licence file is kept in the project. That is a straightforward commercial grant for a framework that many companies build their internal admin systems on.

The upgrade cost is the interesting part, and the README is blunt about it. Moving from RuoYi-Cloud to RuoYi-Cloud-Plus is a rewrite, not a migration, and every row in the differences table is a thing your team has to learn or re-learn. The servlet container changes under you. The RPC mechanism changes from Feign to Dubbo, which is a different programming model with its own service definition, invocation styles and failure semantics. The authentication framework changes from Spring Security to Sa-Token, which invalidates any existing security configuration and changes how authorisation is expressed and audited. The caching layer changes from hand-written Redis access to annotations, and the Redis client changes underneath.

None of that makes the project a poor choice. The rewrite is the point, and the table exists so you can see exactly what you are taking on. But it means the question is not whether Plus is better than RuoYi-Cloud in the abstract, it is whether you are starting fresh or migrating.

The maintenance state supports a reasonable answer. The 6.0.0 release on 2026-07-30 is recent, the 2.6.x line before it was carrying dependency upgrades and vulnerability fixes, and the last push was on 2026-10-09. The badges in the README indicate Spring Boot 4.1 and support for both JDK 21 and JDK 25, so the project tracks current Java releases rather than an old baseline.

The realistic adoption path is a greenfield admin system, or a rewrite of a legacy RuoYi-Cloud deployment, where a team is prepared to own the code and adapt it. The alternative approach, keeping the original framework and extending it, remains available, and for a system with deep customisation in the original's coupled modules it may still be the cheaper path.

Editorial conclusion

Adopt RuoYi-Cloud-Plus if you are building a Chinese enterprise admin system, you want a Spring Cloud Alibaba stack with Dubbo rather than Feign, and you are prepared to own the code rather than extend an existing RuoYi deployment, since the project states plainly that it is not compatible with the original framework. Do not adopt it as an in-place upgrade of RuoYi-Cloud, and do not expect the documentation to be available in English, since the docs site and the README are Chinese. Verify three things first: that the Spring Boot 4.1 and JDK 21 or JDK 25 combination matches your organisation's supported baseline, that your primary database and your Redis version are on the supported list, and that you have read the framework's own differences table, because the switch from Tomcat to Jetty, from Feign to Dubbo and from Spring Security to Sa-Token is a rewrite of the whole stack rather than a version bump.

Frequently asked questions

Official sources

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