Dante Cloud: a Spring microservice base that runs as a monolith too

What Dante Cloud actually is, and who it is not for

Dante Cloud describes itself as an enterprise cloud-native microservice base, and the word base is doing real work. It is not a business application with users, orders and dashboards. It is the layer underneath one: service registry, configuration, authentication, authorisation, multi-tenancy, security hardening and the module structure that a team would otherwise spend months assembling.

The README is unusually direct about the intended audience. It lists who should use the project (teams moving off a traditional monolith, digital transformation projects, complex domain problems, small teams that want to start on the monolith path, and people who want to study Spring ecosystem practice) and who should not. The negative list is more informative than the positive one. If you are committed to a monolith-only worldview, if your product will only ever have a web front end, if you only want MySQL and MyBatis and no new technology, if you want a feature-rich out-of-the-box admin system, or if you want to build an application without reading documentation, the README says plainly that this project is the wrong fit. It also states that the front end is hand-built on component libraries without a dedicated designer, so it does not promise to match your visual standards.

That framing matters because the project deliberately refuses to compete on feature count. The README says it will not stack up large numbers of features that cannot be genuinely generic, calling them a burden and a distraction. Judged on that promise, the interesting question is not what features exist but how the modules are cut and what the security layer actually enforces.

One codebase, two architectures: how the module split works

The headline claim is that the microservice and monolith forms are not two projects and not two branches of the same project. The README states they are one fused codebase, and you choose at runtime which mode to run in. The mechanism behind that is module granularity: the repository is organised into dante-cloud-dependencies, dante-cloud-modules, dante-cloud-packages, dante-cloud-platform and dante-cloud-services, with configurations and documents alongside them. A modular layout at that level is what makes a mode switch plausible, because the same domain modules can be composed into a single deployable or distributed across services.

The practical consequence is a migration path rather than a rewrite. A team can start in monolith mode for local development and early delivery, then move to microservice mode as concurrency and user scale demand it, without porting code between repositories. The README frames this as the project's main distinguishing feature and recommends it explicitly to small teams and to teams still on a traditional stack.

There is a trade-off the README does not paper over. Supporting two run modes from one codebase constrains how aggressively any single module can assume a distributed environment. Code that is safe in both modes has to avoid relying on network boundaries being real, which is a different discipline from writing a service that only ever runs in a cluster. The README does not document what happens to a module that needs a genuinely distributed capability, so that boundary is something a team has to discover in the module sources.

The security surface: device authentication, graded protection and SM envelope encryption

Security is positioned as the second core concern after code quality, and the scope is broader than a typical Spring Security setup. The README names three specific areas: authentication for smart televisions and IoT devices, conformance with China's Level 3 classified protection requirements (国家三级等保), and interface-level encryption using the national SM cryptographic digital envelope.

Those three are not interchangeable. Device authentication is about credential types and flows that differ from browser sessions, which is why MQTT appears in the repository topics alongside RSocket. Level 3 classified protection is a compliance regime with requirements that reach into logging, auditing and access control, not just the login path. The SM digital envelope is a concrete cryptographic construction applied at the interface layer, using China's national algorithms rather than the more common international ones.

For a team outside China, the compliance requirement is likely irrelevant and the SM envelope may be unnecessary, but neither is harmful if the modules are optional. For a team inside China selling to regulated customers, these are the parts that would otherwise be the most expensive to retrofit, and they are the strongest reason to look at this project rather than assembling a stack yourself. The README does not quantify how much of the Level 3 checklist is covered, so treat the claim as a design goal and verify coverage against your assessor's actual requirements.

Getting started: what the README pins and where the documentation lives

The README does not provide a step-by-step install guide. Its link block points to the online documentation at herodotus.cn, and that is where setup instructions belong. What the README does pin down is the toolchain: JDK 25 or later, Spring Boot 4.1.1, Spring Cloud 2025.1.3, Spring Cloud Alibaba 2025.1.0.0, Spring Cloud Tencent 2.1.2.0-2025.0.2, and Nacos 3.2.3. Those versions come from the badge block at the top of the README, and they are the constraint that will decide whether your existing environment can host the project at all.

Because the repository is a Maven multi-module build with a root pom.xml, the first thing to confirm is that the parent POM resolves and the modules compile on your JDK. The README does not list the exact commands, so follow the documentation site rather than improvising flags. What you should expect to see on a successful run is every module under dante-cloud-dependencies, dante-cloud-packages, dante-cloud-modules, dante-cloud-platform and dante-cloud-services installed into your local repository.

Before any service can start, Nacos 3.2.3 has to be running, since it serves as both the registry and the configuration source for the platform modules. The README does not specify a port for it, so take the port from the Nacos documentation rather than guessing. Once Nacos is up and the build has succeeded, the README's own advice for newcomers is to begin in monolith mode. That is the sensible first run: it removes the need to get several services, a registry and a gateway all healthy before you see anything work.

The repository also publishes a companion front end, Dante Cloud UI, at version 4.1.1.0, in both a Quasar-based and a Vuetify-based variant. The README does not document how to start either one, so treat the UI as a separate setup task with its own documentation.

Where Dante Cloud is the wrong tool

The most concrete limitation is the one the project states about itself: it is a base platform, not a feature-rich admin system. If your evaluation criterion is how many ready-made business modules you get, this project will score badly by design, and the README says so. Teams that need a working back office on day one should look elsewhere rather than trying to grow one out of this.

The second limitation is the toolchain floor. JDK 25, Spring Boot 4.1.1 and Spring Cloud 2025.1.3 are a recent line, and the README explicitly warns users who are attached to MySQL and MyBatis that the underlying technology set may feel alien. That is not a bug, but it does mean the project cannot be dropped into an organisation that standardises on older Spring Boot releases without a version migration first.

The third is operational weight. Running in microservice mode means Nacos, a gateway, multiple services and their configuration, which is a real cost for a small team. The monolith mode exists precisely to defer that cost, and the README recommends it for early-stage work.

Finally, the project's own positioning is a warning about expectations. It states that microservices are no longer a mandatory choice but a trade-off, and that its goal is to reduce maintenance investment caused by security holes, technical debt and low-quality code. A team looking for a framework that makes distributed systems easy has misread the pitch. Dante Cloud assumes you already accept the trade-off and want the infrastructure decisions made for you.

Alternatives and how the approach differs

The natural comparison is with the Spring Cloud Alibaba sample ecosystem and with the many Chinese open-source admin platforms built on top of it. The difference is one of intent. Those projects typically optimise for breadth: a large catalogue of business modules, a code generator, and a UI that covers common administrative screens. Dante Cloud optimises for the base layer and explicitly declines to compete on breadth. If you want a generator and a full admin console, the other family of projects is the better fit, and the README says as much.

A second comparison is with assembling Spring Cloud yourself from the individual starters. That gives you complete control and no framework-specific abstractions, but it also means owning version compatibility across Spring Boot, Spring Cloud, Spring Cloud Alibaba and Spring Cloud Tencent, plus the security and multi-tenant plumbing. Dante Cloud's value proposition is that this assembly is already done and pinned to specific versions. The cost is that you inherit its abstractions, which the README acknowledges have accumulated over many iterations and refactors.

A third option, for teams that do not need the Chinese compliance and cryptography features, is a lighter Spring Boot service template with a managed registry. That avoids Nacos and the full microservice apparatus entirely. Dante Cloud's counter-argument is the mode switch: the same code can later run distributed without a rewrite. Whether that future option is worth the present complexity is a judgement each team has to make, and the README's own advice to start in monolith mode suggests the project expects you to defer that decision.

Licence, maintenance and upgrade cost

Dante Cloud and the Dante Engine subproject moved to Apache License Version 2.0 permanently from v3.3.6.0. The README states that personal study and graduation projects are permitted, commercial use is allowed, and redistribution as open source is prohibited. It also forbids uploading the project to platforms such as CSDN for sale. The README mentions supplementary terms that must be observed, so read the full licence text in the repository rather than relying on the summary, and take legal advice if the redistribution restriction affects your plans.

The maintenance picture is favourable on the evidence available. The repository is not archived, and the last push was on 2026-09-10. Releases are frequent: v4.1.1.0 on 2026-08-21, v4.1.0.4 on 2026-07-15 and v4.1.0.3 on 2026-07-01. That cadence means upgrades arrive often, and because the project pins a full Spring stack, each upgrade pulls a coordinated set of framework versions. Budget for that: a base platform that tracks Spring Boot 4.x closely will move faster than an application team typically wants to.

The larger upgrade risk is the mode switch itself. Because one codebase serves both architectures, a change that affects module composition has to be correct in both. The README does not document a rollback procedure for a failed mode migration, so a team planning to move from monolith to microservices should test that path in a non-production environment before depending on it.

Editorial conclusion

Adopt Dante Cloud if you are building a Java 25 Spring Cloud platform and want the module boundaries plus the security and multi-tenant plumbing decided for you. Do not adopt it if you want a feature-complete admin product, a drag-and-drop generator, or a plain MySQL and MyBatis stack. Before committing, verify two things yourself: that a build succeeds on JDK 25 against the Spring Boot 4.1.1 and Spring Cloud 2025.1.3 line the README pins, and that the supplementary licence terms in the README are acceptable for your distribution model. The README itself points users migrating from a traditional project to read the first chapters of Alibaba's middle-platform book before starting, which is a fair signal of the intended audience.

Frequently asked questions

Official sources

1. dromara/dante-cloud on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases