yudao-cloud: three JDK branches, two editions, and no build command

The README has no build command, it has a documentation site and three demos

There is no clone command, no Maven invocation, no Docker command and no configuration file walkthrough anywhere in the README. What it offers instead is a starting point: startup documentation at cloud.iocoder.cn/quick-start/, video tutorials at cloud.iocoder.cn/video/, and three live demo consoles, one for Vue3 with element-plus, one for Vue3 with vben on ant-design-vue, and one for Vue2 with element-ui.

Those demos are also the fastest way to answer a question the text does not. Whether a module is usable and whether the console is pleasant are both visible in a minute, and both are decisions people get wrong from a feature list.

Hosting is split too. The canonical links in the README point at gitee.com/zhijiantianya/yudao-cloud, with GitHub as a mirror at github.com/YunaiV/yudao-cloud, and the tree carries both .gitee/ and .github/ directories. Anyone scripting a checkout has to pick one and pin a branch, because the branch name is where the version decision lives.

The branch name is the Spring Boot major version, not a compatibility detail

Three lines exist, and they differ in the framework major version, not just in the JDK:

The full edition on `master` is JDK 8 with Spring Boot 2.7. The `master-jdk17` branch is JDK 17/21 with Spring Boot 3.5. The `master-jdk25` branch is JDK 25 with Spring Boot 4.x. The same applies to the mini edition, which carries the matching three branches.

That matters because crossing from 2.7 to 3.5 or to 4.x is a source compatibility event, not a dependency bump. A team choosing the JDK 17 line is choosing a different Spring Boot generation and should expect to move its own modules across, whatever the README's feature list suggests is portable.

The release record follows the same split, with v2026.10(jdk8/11), v2026.10(jdk17/21) and v2026.10(jdk25) all published on 2026-10-31, each extending Xinchuang and multi-database compatibility, adding audio and video calls in the App and improving system stability. One detail to check rather than assume: the jdk8 release is named jdk8/11 while the version table lists only JDK 8 for the `master` branch.

Full versus mini is a module set, and the framework modules stay in both

Two editions exist. The full edition carries system functions and infrastructure, and adds workflow, payment, data reports, the WeChat official account, the mall, member centre, ERP, WMS, CRM, MES, HRM, FMS, PMS, OA collaborative office, the AI large model module, IoT and IM. The mini edition keeps only the system and infrastructure functions and excludes all of that.

The repository tree shows the size of the question. Nineteen business modules sit at the top level as `yudao-module-` directories, covering ai, bpm, crm, erp, fms, hrm, im, infra, iot, mall, member, mes, mp, oa, pay, pms, report, system and wms, alongside yudao-dependencies, yudao-framework, yudao-gateway, yudao-server and yudao-ui.

The shrink you get is therefore not smaller runtime. The dependency, framework, gateway and server modules are infrastructure and stay. What disappears is business functionality. A migration document at cloud.iocoder.cn/migrate-module/ states that moving from the full edition to the mini one takes 5 to 10 minutes, and that figure is for the one direction, from full down to mini.

Nacos, Sentinel, Gateway, XXL-Job and Seata are architecture, not plugins

The backend is described as a Spring Cloud Alibaba microservices architecture, and the named components are specific: Nacos for the registry and the configuration centre, XXL-Job for scheduled tasks, Sentinel for service protection, Gateway for the service gateway, and Seata for distributed transactions.

None of that is an optional integration in this edition. It is the shape of the thing, which means the cost of evaluating it is the cost of standing up that infrastructure first. A registry, a config centre, a gateway, a scheduler, a Redis and a database is the floor before any module runs.

This is also where the project names its own alternative, and the difference is architectural rather than cosmetic. The companion ruoyi-vue-pro is the Spring Boot multi-module version, so it carries the same feature set without Nacos, Gateway, Sentinel or Seata. Choosing yudao-cloud over it means choosing microservices and paying for the operational surface that comes with them, not choosing a bigger feature list.

Seven databases and five message queues, with no stated verification per dialect

The data layer is described broadly. MySQL, MariaDB, Oracle, PostgreSQL and SQL Server are named, plus domestic engines including DM, KingbaseES, openGauss, HighGo, OceanBase, TiDB, GaussDB, MogDB, Vastbase G100, PolarDB and Shentong, on top of MyBatis Plus with Redis and Redisson. For messaging, the list is Event, Redis, RabbitMQ, Kafka and RocketMQ.

Breadth that wide is a claim about the persistence layer, and the persistence layer is not the whole system. Flowable drives the workflow module. The README does not say which of the databases the workflow engine and the report designers are verified against, so a deployment onto DM or TiDB rests on your own testing rather than on a matrix published here.

The schema also arrives as SQL. There is a `sql/` directory at the top level with initialisation scripts per database, and for other databases and later table-structure changes the README points to the conversion tools in `sql/tools` and a table-structure-change (version upgrade) document.

The admin console is three separate repositories, not one switch

The desktop front end is not a setting. Vue3 ships in two flavours, yudao-ui-admin-vue3 built on element-plus and yudao-ui-admin-vben built on vben with ant-design-vue. Vue2 ships separately on element-ui, as the yudao-ui-admin directory of ruoyi-vue-pro. Each lives outside this backend repository.

The consequence is that a Vue2 shop and a Vue3 shop are not choosing a theme here, they are forking onto different front ends against the same Java services. Any customisation you make to the console is work you do twice if you later move between the element-plus and ant-design-vue builds, because the component vocabulary is different.

Mobile is handled once, with uni-app, one codebase targeting APP, mini program and H5, and the two uni-app repositories cover the admin side and the mall. That is the one place the project avoids the fork, and the 2026.10 release line added audio and video calls on the App side.

Nothing in the tree marks a module optional, and the code generator writes Vue

Nineteen business modules is the honest measure of what a full build contains, and none of them is flagged as something you can drop at build time. The documented route to a smaller system is the separate mini edition, which is a different repository rather than a flag.

The code generator is the other thing to evaluate early. It generates Java and Vue front and back end code, SQL scripts and interface documentation in one pass, and handles single tables, tree tables and master-detail layouts. Generated Vue is written against a component library, so its output is coupled to whichever console from the previous section you adopted. Running the generator before that decision means rewriting the generated components afterwards.

What it does not generate is the part teams forget. Authentication is Spring Security with Token and Redis, with multi-terminal and multi-user-type support and SSO, plus dynamic permission menus and button-level permission control cached in Redis. SaaS multi-tenancy allows per-tenant permissions behind a transparent multi-tenant wrapper. None of that is code generated, and all of it is the part that carries your security review.

MIT covers the licence question, and the support channel is an issue tracker

The licence is MIT, with a LICENSE file at the top level. The README also carries an explicit statement that there will be no commercial version, now or in the future, and that all code is open source, presenting the platform as free for individuals and enterprises alike. That is the maintainer's declaration rather than a warranty, but it removes the question a procurement team would otherwise ask first.

What it does not remove is the support question. Problems are routed to GitHub issues, and the README leans on Star counts as encouragement, which tells you where attention comes from but not what response you get. For context on how this project sits against comparable Chinese open source systems, the README points at a community-maintained comparison table hosted outside the repository, so that comparison is somebody else's document and can drift.

The last push was on 2026-11-01, a day after the 2026.10 releases, so the branch you clone can be ahead of what the tags describe.

Editorial conclusion

yudao-cloud fits a team that already runs Nacos, Redis, a gateway and a message broker, that needs ERP, CRM, MES, WMS, OA and payments in one codebase, and that is willing to maintain a multi module Maven build. It does not fit a team that wants a monolith, or one evaluating it on a single machine, because the microservices edition assumes infrastructure the README never sets up for you. Before cloning anything, settle two questions: which JDK line you are on, which decides the Spring Boot major version, and whether you want the full or the mini edition, because that choice is a module set rather than a build flag. Then open the quick start documentation, because the README contains no command that starts this project.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. YunaiV/yudao-cloud on GitHub