ruoyi-vue-pro: A Spring Boot Multi-Module Admin Platform With Optional ERP, CRM and IoT Modules

Which Problem the Full Version Actually Removes

The recurring cost in internal admin systems is not the login page. It is the second year: role changes, per-department data scoping, a second tenant, a workflow that legal wants to edit without a deploy. ruoyi-vue-pro targets exactly that layer. The README describes RBAC dynamic permissions with button-level control, data permissions, SaaS multi-tenancy with per-tenant permissions and a transparent multi-tenant wrapper underneath, plus Flowable workflow with dynamic forms and countersign or or-sign task assignment. Those are the pieces teams usually rebuild badly.

The audience is narrow and specific. It is a Java team building a back-office product for the Chinese market, where WeChat mini programs, WeChat official accounts, DingTalk and Alipay payment integration are expected rather than exotic. The README lists third-party login for WeChat mini program, WeChat official account, WeCom and DingTalk, payment and refund through Alipay and WeChat, and SMS channels on Alibaba Cloud and Tencent Cloud. If your product never touches those providers, a large part of the value proposition does not apply to you.

The Module Split Is the Architecture, Not a Detail

The backend is described as a Spring Boot multi-module architecture on MySQL with MyBatis Plus and Redis with Redisson. That sentence hides the decision that matters most. The project ships in two shapes. The full version, ruoyi-vue-pro, contains system functions, infrastructure, member center, data reports, workflow, mall, WeChat official account, CRM, ERP, WMS, MES, HRM, FMS, PMS, IM, AI large model and IoT. The trimmed version, yudao-boot-mini, contains only system functions and infrastructure.

The README points to a migration document that claims 5 to 10 minutes to move modules from the full version into the trimmed one on demand. That is the intended workflow: start from the full repository, delete or migrate what you do not want. It is a pragmatic approach, and it is also the main structural risk. A multi-module Maven or Gradle build only stays clean if module boundaries are enforced. Nothing in the README states whether cross-module dependencies are checked at build time, so a team that migrates three modules out may still be pulling transitive code from modules it removed. That is worth confirming against the build files before committing to the migration path.

Three JDK Branches and the Spring Boot Version You Inherit

Version selection is a branch selection, not a dependency bump. The README's version table maps three targets. The master branch is JDK 8 with Spring Boot 2.7. The master-jdk17 branch is JDK 17 or 21 with Spring Boot 3.5. The master-jdk25 branch is JDK 25 with Spring Boot 4.x. The same three-way split applies to yudao-boot-mini.

That is a clean answer to a messy question, and it is also a commitment. If you are on JDK 8 today because of an internal platform constraint, you are on the oldest Spring Boot line, and the migration to master-jdk17 is not a version bump you can do casually. Spring Boot 2.7 to 3.5 crosses the Jakarta namespace change, which touches persistence, validation and servlet imports throughout a multi-module codebase. The release notes for v2026.08 list three artifacts, one per JDK line, which confirms the branches are released in parallel rather than one being a legacy afterthought. Verify which branch your team can actually run before evaluating anything else; the rest of the review depends on that answer.

What the Frontend and Mobile Tiers Cost You

The admin frontend is not a single choice. Vue 3 is offered in an element-plus build and a vben (ant-design-vue) build, and Vue 2 is offered in an element-ui build. There are three demo addresses in the README, one per variant. The mobile side uses uni-app, described as one codebase adapting to multiple terminals: app, mini program and H5.

Supporting three frontend variants is generous to adopters and expensive for the project. It also means the documentation you follow may not match the variant you picked. If you adopt the Vue 2 element-ui build, you are on the oldest of the three while the backend moves toward Spring Boot 4.x on master-jdk25. Nothing in the README says the Vue 2 variant is deprecated, but the direction of travel is visible in the version table. For a new build, the Vue 3 element-plus variant is the safer default, and the README lists it first among the demo addresses.

Code Generation, WebSocket and the Infrastructure Assumptions

The code generator is the feature that changes day-to-day work. The README states it produces Java and Vue frontend and backend code, SQL scripts and API documentation in one pass, and supports single tables, tree tables and master-detail tables. For CRUD-heavy internal systems this is the difference between a two-week module and a two-day module, provided your tables follow the conventions the generator expects. Tree and master-detail support suggests the templates handle parent-child relationships, which is where hand-written generators usually stop.

Real-time communication uses Spring WebSocket with built-in token authentication and WebSocket cluster support. Cluster support matters because a single-node WebSocket server breaks the moment you run two application instances behind a load balancer. The README also states the database layer can run on MySQL, Oracle, PostgreSQL, SQL Server, MariaDB, Dameng DM and TiDB, and the message queue on Event, Redis, RabbitMQ, Kafka or RocketMQ. Those lists are broad, and breadth in a README is a claim about configuration surfaces rather than a statement that every combination is exercised. Treat the non-MySQL database options as something to validate on your own schema, especially Dameng DM if you are targeting a domestic database requirement.

Where the Full Version Becomes the Wrong Tool

The most concrete failure mode is scope. A team that clones ruoyi-vue-pro for an internal tool with ten screens inherits mall, CRM, ERP, WMS, MES, HRM, FMS, PMS, IM, AI and IoT modules in the tree. Even if those modules are never started, they appear in IDE indexing, in dependency graphs and in every upgrade merge. The documented answer is the migration into yudao-boot-mini, which the README says takes 5 to 10 minutes per module. That estimate covers the mechanical move; it does not cover re-testing the modules you kept after their neighbors are gone.

The second failure mode is upgrade cost. The v2026.08 release added HRM and FMS plus a standalone mobile client, across three JDK artifacts at once. A project releasing that much surface area in parallel branches will produce merge conflicts for anyone who has modified core modules. If your team plans to fork and edit the permission or tenant layers, budget for re-applying those edits each release. If you cannot, pin a release and accept the divergence.

The third case is a poor fit regardless of effort: a team without Java and Spring experience. Nothing in the README suggests a non-Java deployment path, and the stack assumes MySQL, Redis, Redisson and Spring Security knowledge.

How It Compares to a Cloud-Native Microservice Base

The project's own README positions a sibling, yudao-cloud, as the Spring Cloud microservice architecture version of the same platform. The difference is architectural rather than feature-level. ruoyi-vue-pro is a multi-module monolith: one Spring Boot application assembled from modules, with shared database access through MyBatis Plus and shared session and cache state in Redis. yudao-cloud splits the same functional surface into independently deployable services behind Spring Cloud infrastructure, which brings service discovery, configuration management and inter-service calls into the picture.

For a team of five to fifteen engineers running one product, the monolith is the lower-overhead choice: one deployable, one database schema, one log stream. The microservice version pays off when modules need independent scaling or independent release cadence, which is a real requirement in some organizations and an imagined one in most. Picking yudao-cloud because it sounds more scalable trades a simpler operational model for distributed tracing, network failure handling and cross-service transaction problems you did not have before. The project also lists Spring-Boot-Labs as a companion learning repository, which is a signal that the authors expect adopters to need Spring Boot and Cloud background rather than treating the platform as a black box.

Licence and the Maintenance Bill

The repository is MIT licensed, and the README states plainly that there will be no commercial version and that all code is open source, usable free by individuals and enterprises. MIT is permissive: it allows commercial use, modification and redistribution, with the licence and copyright notice retained. That is a favourable position for a company embedding this in a product. It is not legal advice, and your counsel should confirm how MIT interacts with the third-party SDKs the platform integrates, particularly the payment and SMS provider clients, which carry their own terms.

Maintenance cost has two parts. The first is upgrade frequency: releases arrive as named versions such as v2026.08, published simultaneously for three JDK lines, and each carries new modules. The second is the migration tax on the code you change. The README's own estimate of 5 to 10 minutes to migrate a module into yudao-boot-mini is a good baseline for a clean move, but it assumes you have not modified the module. Teams that customize the tenant or permission layers should plan to re-apply those changes on every upgrade rather than merging them once. The practical mitigation is to keep customizations in your own modules that depend on the platform, not inside the platform's modules, so an upgrade replaces code you never touched.

Editorial conclusion

Adopt ruoyi-vue-pro if you need a Chinese-market admin base with RBAC, data permissions and SaaS multi-tenancy already wired, and you are willing to prune modules rather than build them. Skip it if you want a small dependency surface, a non-Java backend, or a codebase you can read end to end in a week, because the full version carries ERP, CRM, MES, HRM, FMS, IM, AI and IoT modules you may never call. Verify first: which of the three branches (master, master-jdk17, master-jdk25) matches your JDK and Spring Boot version, whether the modules you want survive the documented 5 to 10 minute migration into yudao-boot-mini, and whether your database is on the supported list beyond MySQL.

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. YunaiV/ruoyi-vue-pro on GitHub