Dante Cloud: a Spring Cloud base that runs as a monolith or as microservices from one codebase

The gap Dante Cloud is trying to fill

Starting a Spring Cloud project from scratch means assembling a registry, a configuration centre, an authorization server, a gateway, a tenant model, and a security layer before anyone writes a line of business logic. Dante Cloud's stated goal is to remove that phase. The README describes it as a base platform that lets users skip architecture selection, technology research and infrastructure construction, and go straight to business development. That framing matters because it tells you what the project is optimising for: not feature breadth, but a defensible starting point.

The README is unusually direct about who should walk away. It lists six user profiles it does not serve, including people who only work with MySQL and MyBatis and do not want new technology, people who want a drag-and-drop code generator, and people who want a visually polished admin interface. The front end is described as hand-built from a component library with no professional designer involved, offered mainly so that back end developers have a gentler path into front end work. That is an honest constraint, and it should be read as one.

The intended audience is narrower than the topic list suggests. It is teams building multi-tenant enterprise systems, IoT or smart-device platforms, or digital transformation projects where the infrastructure decisions have already been made for them and the remaining work is domain logic.

One source tree, two runtime topologies

The central design claim is that the microservice architecture and the monolith architecture are not two separate codebases or two separate projects. According to the README, they are fully merged into a single set of code, and you choose at runtime whether to start in microservice mode or monolith mode. The stated benefit is that an early-stage project can run as a monolith for fast local development, then move to microservices as user numbers and concurrency grow.

This is the part worth scrutinising. A codebase that can run in both modes has to keep its module boundaries clean enough that the monolith does not accidentally depend on service-discovery-only paths, and loose enough that splitting later does not require rewriting call sites. The README attributes this to a modular and componentised design that also gives functions a pluggable quality. The architecture diagram is published as a GIF in the repository's readme directory, so the exact module graph is something you should inspect there rather than take on trust.

What the material does not give is a migration procedure. There is no documented list of configuration changes required to switch modes, no statement of which modules must be excluded in monolith mode, and no worked example. Treat the switch as a design property of the code layout rather than a one-command operation until you find the relevant documentation page.

The security surface is the actual differentiator

Feature lists in this category tend to blur together. Dante Cloud's security claims are more specific than most. The README states support for authentication of smart televisions and IoT devices, alignment with China's Classified Protection Level 3 (等保三级) requirements, and SM-series national cryptographic envelope encryption and decryption at the interface level. The repository topics confirm the MQTT and IoT angle.

Envelope encryption at the API boundary is not a common default in Western Spring stacks, and it changes how you write controllers and clients. Classified Protection Level 3 alignment implies audit logging, access control and data protection controls that a generic Spring Security setup does not provide out of the box. If your product needs either of those, the value proposition is concrete. If it does not, you are carrying configuration and dependency weight for controls you will never exercise.

The project also describes itself as a multi-tenant solution and lists Spring Authorization Server among its topics, which points to OAuth2-based authorization as the identity layer. The README does not document the tenant isolation model, so whether tenancy is enforced by schema separation, row-level filtering or a discriminator column is something you would need to confirm from the source before designing your data model around it.

Runtime requirements and the version treadmill

The badges state 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. That is a leading-edge combination. JDK 25 is not a casual upgrade for teams still running Java 17, and Spring Boot 4.x is a major line with its own migration surface.

Release cadence is fast. Three releases appear in the supplied list between July and August 2026: v4.1.0.3 on 2026-07-01, v4.1.0.4 on 2026-07-15, and v4.1.1.0 on 2026-08-21. The project is actively maintained, and the version numbers move in lockstep across the companion repositories: Dante Engine, ThingsBrain, and the two UI projects all carry the 4.1.1.0 label. That lockstep is convenient when upgrading but means you cannot mix a newer core with an older engine without checking compatibility.

Budget for upgrade work. A base platform that tracks Spring Boot and Spring Cloud release trains will pull you forward whether or not your business needs it, and the further you have customised the modules, the more that pull costs.

Getting it running starts with the environment, not the code

Because the project has not been installed here, the following is drawn from the repository's stated requirements rather than from a verified run. The prerequisites are JDK 25 or later and a Nacos 3.2.3 instance acting as both registry and configuration centre. Spring Cloud Alibaba and Spring Cloud Tencent are both listed, so the service-discovery and governance layer has more than one supported provider.

The repository is organised as a monorepo, and the topics list confirms this. The practical consequence is that you clone one repository and build the modules you need rather than resolving a set of separate artifacts. The companion projects live outside it: Dante Engine, ThingsBrain and the UI projects are separate repositories under the dante-compass organisation, each versioned to match.

What the supplied material does not contain is a quickstart command sequence, a docker-compose file, or a list of required configuration keys. The README points to the online documentation at herodotus.cn as the primary reference. Anyone evaluating this project should read that documentation for the startup procedure before cloning, because the module count and the Nacos dependency mean a naive clone-and-run will not get you to a working system.

Where the design choices will cost you

The most significant limitation is stated by the project itself: it is a base platform, not a feature-complete back office. The README says the team does not believe it can make functions both rich and genuinely general-purpose, and that stacking non-universal features becomes a burden and a distraction. If your evaluation criterion is a long list of ready-made admin modules, this project will score badly by design.

The second cost is the technology floor. The README explicitly warns away users who are comfortable only with MySQL and MyBatis and do not want new technology. Between JDK 25, Spring Boot 4.1.1, reactive WebFlux support, RSocket, gRPC, MQTT, Loki and Spring AI in the topic list, the surface area is wide. The README claims roughly 80 percent of the core components are native Spring ecosystem components and that usage follows standard patterns, which softens the learning curve, but a base platform that supports both blocking and reactive services in parallel means you will meet both programming models.

The third cost is front end. The UI is hand-built, and the README says plainly that it cannot guarantee it will match your aesthetic expectations. If the interface is customer-facing, plan to replace or heavily restyle it.

How it compares to assembling your own Spring Cloud stack

The realistic alternative is not a competing product but the manual route: start from Spring Initializr, add Spring Cloud Gateway, Spring Authorization Server, Nacos and a tenant model yourself, and integrate each piece as your requirements appear. That approach gives you exactly the components you need and nothing else. It also gives you the version-compatibility research, the security configuration, and the integration debugging, which is precisely the work Dante Cloud claims to have already done.

The trade-off is control against time. A hand-assembled stack has no imposed module boundaries and no upstream release cadence pulling it forward. Dante Cloud has both, plus a documented security posture you would otherwise have to design from scratch. If your team has already built two or three Spring Cloud systems and has internal libraries for the common parts, the manual route is likely cheaper, because you would spend more time removing Dante Cloud's opinions than benefiting from them.

If you are starting from zero and your requirements include multi-tenancy, device authentication or SM-series encryption, the assembly work is substantial enough that a base platform is the more economical starting point.

Licence terms and the maintenance you are signing up for

Dante Cloud and its Dante Engine subproject are licensed under Apache License Version 2.0, changed permanently from v3.3.6.0 onward. The README states that this permits personal study, graduation projects and commercial use, and prohibits re-open-sourcing. It also adds supplementary terms in the licence file, including a prohibition on republishing the code to download platforms such as CSDN for sale. The supplied README is truncated mid-sentence in that supplementary section, so the full set of additional conditions is not visible here. Read the complete LICENSE file in the repository before you build a product on it. Nothing in this article is legal advice.

The maintenance picture is a fast-moving upstream. Version 4.1.1.0 shipped on 2026-08-21, six weeks after 4.1.0.4 and seven weeks after 4.1.0.3. Expect to track Spring Boot and Spring Cloud releases rather than choose when to upgrade. The mitigation is to keep your changes in modules outside the core rather than patching core modules, so that pulling a new upstream tag stays a merge rather than a rewrite. The repository's modular design is what makes that possible, and it is the reason the dual-architecture claim is worth taking seriously even without a documented migration path.

Editorial conclusion

Adopt Dante Cloud if you are building a multi-tenant Spring system that needs IoT device authentication, national Classified Protection Level 3 alignment, or SM-series envelope encryption already wired in, and you accept JDK 25 plus Spring Boot 4.1.1 as your floor. Do not adopt it if you want a feature-rich admin product, a no-code generator, or a stack you can run without reading the documentation. Before committing, verify three things in your own environment: that JDK 25 is available on every build and deploy host, that your chosen registry and configuration centre is Nacos 3.2.3, and that the Apache-2.0 supplementary terms in the repository's licence file permit your intended distribution model, since the project states commercial use is allowed but re-open-sourcing is not.

Official sources

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