Yudao Cloud: a Spring Cloud Alibaba admin platform that ships ERP, CRM, MES and IoT modules

The problem Yudao Cloud solves, and the teams it fits

Most admin platforms stop at users, roles and menus. Yudao Cloud starts there and keeps going. The repository holds modules for system and infrastructure, workflow, pay, mall, member, ERP, WMS, CRM, MES, HRM, FMS, PMS, OA, AI, IoT, IM, report and the WeChat integration modules. For a team that has to stand up an internal business system, that list removes months of scaffolding: you get the RBAC layer, the multi-tenant plumbing and the business modules in one codebase.

The audience is narrower than the module list suggests. This is a Java backend with a Spring Cloud Alibaba stack, so the people who benefit are backend engineers who already know Spring Boot and are comfortable with a service registry. The README frames the project as a quick development platform, and the code generator (single tables, tree tables, master-detail tables, producing Java, Vue, SQL and API docs) is aimed at teams that expect to extend the schema rather than use it as is.

It is a poor fit for a solo developer who wants a monolith. The project relationship table in the README is explicit: ruoyi-vue-pro is the Spring Boot multi-module version, yudao-cloud is the Spring Cloud microservice version. If you do not need independent services, the cloud edition adds operational surface you will not use.

How the architecture is wired: Nacos, Gateway, Seata and the module layout

The top-level layout tells most of the story. yudao-dependencies holds dependency management, yudao-framework holds shared starters, yudao-gateway is the service gateway, and yudao-server is the assembly point. Everything else is a yudao-module-* directory, one per business domain, which means the deployment unit and the module boundary line up.

The README names the supporting stack: Nacos as registry and config center, XXL-Job for scheduled tasks, Sentinel for service protection, Gateway for the entry point and Seata for distributed transactions. Persistence is MyBatis Plus over MySQL, Oracle, PostgreSQL, SQL Server, MariaDB, DM (达梦) and TiDB, with Redis and Redisson for caching. Messaging can be Event, Redis, RabbitMQ, Kafka or RocketMQ, so the queue is a configuration decision rather than a hard dependency. The topic list on the repository matches this: dubbo, nacos, seata, rocketmq, sharding-sphere, skywalking, zookeeper.

Two design choices deserve attention. Authentication uses Spring Security with token and Redis, and the README states it supports multi-terminal and multi-user authentication plus SSO. Multi-tenancy is described as a transparent lower-level wrapper with per-tenant permissions, which is the pattern you want if tenants should not see tenant logic in every query. Neither is unusual, but both are places where a fork will diverge from upstream quickly if you customize them.

Installing Yudao Cloud and running the mini edition first

The README does not put a shell script in front of you. It points at the quick start document at cloud.iocoder.cn/quick-start/ and a video tutorial at cloud.iocoder.cn/video/, and those are the authoritative setup steps. What the repository does give you is the layout to work from: a Maven root pom.xml, a sql/ directory for schema and seed data, and a script/ directory for supporting scripts.

Because the stack depends on Nacos, the practical first move is to bring up the infrastructure the README names before touching the Java build. The README does not include a compose file or a startup command, so the exact commands come from the quick start document rather than from the repository:

# the quick start document at cloud.iocoder.cn/quick-start/ gives the startup steps
# the repository gives the layout: pom.xml, sql/, script/, yudao-server/

After the build, the runnable entry point is the yudao-server module, which aggregates the business modules. Service registration and configuration both come from Nacos, so a server that starts but never appears in the Nacos console is a configuration problem, not a code problem.

The README offers a shortcut worth taking. The mini edition, yudao-cloud-mini, contains only the system and infrastructure functions. The migration document claims 5 to 10 minutes to move from the full edition to the mini edition on demand. Starting from the mini edition gives you a smaller surface to debug, and you add workflow, pay, mall, ERP, CRM, MES, HRM, FMS, PMS, OA, AI, IoT and IM only when you need them.

For the front end, the README lists three admin options: Vue3 with element-plus, Vue3 with vben (ant-design-vue), and Vue2 with element-ui. The mobile side uses uni-app, described as one codebase adapted to APP, mini program and H5.

Where Yudao Cloud gets in the way

The breadth is real, and so is the weight. A Spring Cloud Alibaba deployment here means Nacos, a gateway, Sentinel, Seata and XXL-Job alongside your database, Redis and a message queue. That is a lot of moving parts before the first business feature exists, and each one is a place where a local run can fail for reasons unrelated to your code. A team without someone who has operated Nacos and Seata will spend its first week on infrastructure.

The version matrix is the second constraint, and it is easy to get wrong. The README maps master to JDK 8 with Spring Boot 2.7, master-jdk17 to JDK 17/21 with Spring Boot 3.5, and master-jdk25 to JDK 25 with Spring Boot 4.x. These are separate branches, not build profiles. If you clone the default branch and your team standardizes on JDK 21, you are on the wrong branch, and the recent releases are published per JDK line (v2026.08 exists in jdk8/11, jdk17/21 and jdk25 variants), which confirms the split is maintained rather than incidental.

The third limitation is documentation scope. The README is a feature catalogue and a set of links. It does not document rollback, upgrade procedures, or the operational limits of the multi-tenant wrapper. The release notes for v2026.08 mention new HRM and FMS modules and standalone mobile operation, which tells you the feature set is still expanding, but nothing in the README describes how a schema change is migrated across an existing deployment. Plan to read the migration document and the quick start before assuming an upgrade path exists.

Yudao Cloud versus ruoyi-vue-pro and yudao-cloud-mini

The honest alternative is the project's own sibling. ruoyi-vue-pro is the Spring Boot multi-module version, and the README's comparison table puts it beside yudao-cloud as a different architecture rather than a different product. The difference is concrete: one process with modules versus services behind a gateway with a registry. If your team is five people and the deployment target is a single VM, ruoyi-vue-pro removes Nacos, Gateway and Seata from your life while keeping the same business modules. Choosing the cloud edition for a monolith-shaped problem is the most common way to make this stack harder than it needs to be.

The second alternative is yudao-cloud-mini, which the README describes as containing only system and infrastructure functions and excluding workflow, pay, report, WeChat, mall, member, ERP, WMS, CRM, MES, HRM, FMS, PMS, OA, AI, IoT and IM. That is not a stripped-down fork for hobby use. It is the same architecture with a smaller module set, and the migration document is the bridge between the two. If you are evaluating whether the platform fits, the mini edition is the cheaper way to find out.

Beyond the project family, the README links a community-maintained comparison table of domestic open source projects, which is the right place to look if you are weighing this against other Chinese admin platforms rather than against a different architecture of the same codebase.

Licence, maintenance and upgrade cost

The licence is MIT, and the README states there will be no commercial edition, with all code open source and free for individuals and enterprises. MIT is permissive, so the usual obligations apply: keep the copyright notice, and understand that the licence grants no warranty. That is a statement about the licence text, not legal advice for your situation.

Maintenance is visible. The last push was on 2026-09-19, and the v2026.08 releases shipped on 2026-09-02 across three JDK lines. The repository is not archived. What the README does not give is a support commitment, a deprecation policy, or a documented upgrade path between releases. The JDK branch split is the main upgrade cost: moving from JDK 8 to JDK 17/21 or JDK 25 is a branch migration, not a dependency bump, and any local changes you made to framework or module code have to be replayed.

The second cost is customization drift. Multi-tenancy, authentication and the gateway are the components most teams touch first, and they are also the components the framework owns. Every change there makes the next upstream merge more expensive. Budget for that before you fork.

Editorial conclusion

Adopt Yudao Cloud if you want a Spring Cloud Alibaba admin platform whose module list already covers system, infra, workflow, pay, mall, ERP, CRM, MES, HRM, FMS, OA, AI and IoT, and you are willing to run Nacos, Gateway, Seata and XXL-Job alongside it. Do not adopt it if you need a small service you can reason about in an afternoon, or if the business modules you want live only in the full edition and you have not read the migration document yet. Verify first that your JDK matches the branch: master is JDK 8 with Spring Boot 2.7, master-jdk17 is JDK 17/21 with Spring Boot 3.5, and master-jdk25 is JDK 25 with Spring Boot 4.x. Then decide between yudao-cloud and yudao-cloud-mini by reading the migration document at cloud.iocoder.cn/migrate-module/ before you clone anything.

Frequently asked questions

Official sources

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