SpringBlade: A Spring Boot 4 Microservice Platform for Multi-Tenant SaaS

The multi-tenant groundwork SpringBlade ships instead of leaving to you

SpringBlade targets a specific situation: a Java team that has decided on microservices and multi-tenancy, and would rather start from a working skeleton than spend the first two months wiring a registry, a gateway, a token system and a tenant filter together. The README describes it as a microservice architecture upgraded from a commercial-grade project, built on Spring Boot 4, Spring Cloud 2025 and Java 21, and following the Alibaba coding standard. It also states the project has run in production for nine years, through the Camden, Hoxton and 2025 generations of Spring Cloud and through fat jar, Docker, and Kubernetes with Jenkins deployments.

The README says the multi-tenant layer is deliberately thin: "极简封装了多租户底层，用更少的代码换来拓展性更强的SaaS多租户系统", which translates roughly to a minimal encapsulation of the multi-tenant foundation in exchange for a more extensible SaaS system. That is a design stance worth reading carefully. It means SpringBlade gives you the tenant plumbing and expects you to build the tenant-aware business rules on top. If you want a framework that decides your tenant isolation strategy for you, this is not that.

The audience is narrower than the feature list suggests. Documentation, the question-and-answer community, the membership plan and the official product pages are all in Chinese, and the repository links to Gitee as the primary backend home alongside GitHub. A team without Chinese-reading engineers will be working from source code and community posts.

How the modules fit together: gateway, auth, Nacos and the self-built Secure module

The repository layout is explicit about the split. blade-auth provides authorization, blade-gateway is the Spring Cloud gateway, blade-common holds shared utilities, blade-ops carries operational modules (blade-admin for Spring Cloud administration, blade-develop for code generation, blade-report, blade-resource and two Seata distributed transaction demos), blade-service holds business modules (blade-demo, blade-desk, blade-log, blade-system), and blade-service-api holds the matching API packages such as blade-user-api, blade-dict-api and blade-scope-api. That api/service pairing is the pattern the project wants you to copy: interfaces in one module, implementations in another, so services depend on contracts rather than on each other.

Nacos serves as both registry and configuration center, which the README frames as a way to slim the project down while strengthening coordination between modules. Sentinel handles flow control, circuit breaking and system load protection. The core framework is split out into BladeTool, published to Maven Central as blade-core-bom, so the main repository stays closer to business code.

Authentication is the part that departs most from stock Spring. The README states the project borrows from OAuth2 to build its own multi-terminal authentication system, with token permissions isolated between subsystems, and borrows from Spring Security to build its own Secure module using JWT for token authentication, extensible to Redis and other fine-grained control schemes. In practice that means you inherit a working token flow but also a token flow you cannot debug by reading Spring Security documentation. Release v5.0.2 notes a unified client IP trusted resolution rule, which is the kind of detail that matters when tokens and rate limits are keyed on client address.

Installing SpringBlade and getting a first service running

The README does not contain a step-by-step install guide. It points to the development manual wiki, the FAQ collection, the Blade security manual on Yuque, and a Rainbond deployment guide. What the README does give you is the version matrix and the module layout, which is enough to state the prerequisites precisely: Java 21 or later, NodeJS 18 or later, Spring Boot 4.1.0, Spring Cloud 2025.1.2, Spring Cloud Alibaba 2025.1.0.0, Nacos Alibaba 3.2.2, MyBatis Plus 3.5.17 and Spring 7.0.8.

Start by checking the toolchain, because a JDK mismatch here fails at build time rather than at runtime. The version flags below are standard to the tools themselves; the README does not print them, it only states the required versions.

java -version
node -v

You should see a Java version of 21 or higher and a Node version of 18 or higher. If either is lower, the build will not match the versions the README lists.

Because the core framework is published to Maven Central, a dependent project can pull the BOM directly instead of building blade-tool from source. The README gives the artifact coordinates in the badge link: org.springblade:blade-core-bom. The README does not print a dependencyManagement snippet, so the exact version to pin comes from the Central listing for that artifact.

After that, Nacos is the first thing that has to be alive, because it is both registry and config center for every service. The README pins Nacos Alibaba 3.2.2. Bring that up before anything else, then start blade-gateway and blade-auth, then the business services. The README does not document the exact startup order or the configuration keys each service expects, so treat the development manual wiki as required reading rather than optional.

For the frontend, the README lists three options: Saber3 based on Vue3 and Element-Plus, Saber based on Vue2, and Sword based on React. Release v5.0.1 mentions establishing a full TypeScript engineering base, so the frontend side is being kept in step with the backend rather than frozen.

Where SpringBlade gets in the way

The self-built auth and Secure modules are the clearest trade-off. Isolation between subsystem tokens is a real capability, and it is implemented in code that is not Spring Security. When a token is rejected, or when a role check behaves unexpectedly, the debugging path runs through SpringBlade source rather than through framework documentation you can search in your own language. Release v5.0.1 mentions strengthening role determination and role assignment ownership validation, which suggests this area has been actively reworked recently rather than settled for years.

The documentation gap is the second constraint. The README links to a wiki, a community Q&A site, a Yuque security manual and a Rainbond guide, all external and all in Chinese. There is no English quickstart in the repository. For a team evaluating the project, that means the evaluation itself costs more than reading a README.

Version currency is a third consideration, and it cuts both ways. Spring Boot 4.1 and Spring Cloud 2025.1 are recent lines, and the README states the project has tracked Spring Cloud from Camden through Hoxton to 2025. Tracking that far forward means your surrounding ecosystem, including any internal libraries pinned to older Spring versions, has to move with it. A team running Spring Boot 2.x services cannot adopt SpringBlade as an incremental addition; it is a platform decision.

Finally, the commercial context. The homepage is bladex.cn, the README lists a membership plan and four official products (an enterprise development platform, a data visualization screen, an IoT platform and an AI model platform), and the security manual lives outside the repository. The open source code is Apache-2.0, but the project sits inside a commercial business, and the README does not spell out which modules are covered by the free repository versus the membership plan. That is a question to answer before architecture work starts, not after.

SpringBlade against assembling Spring Cloud yourself

The obvious alternative is not a competing framework but the default path: start from start.spring.io with Spring Boot and Spring Cloud, add Spring Cloud Gateway, add Nacos or Eureka, add Spring Security with OAuth2 or a JWT library, and write your own tenant filter. That approach gives you a stack you fully understand, documentation in the language of your choice, and no coupling to another project's release cadence.

The difference in approach is where the work lands. With stock Spring Cloud you spend the early weeks on integration: making the gateway forward identity correctly, deciding how tenant context propagates across service calls, setting up token isolation between subsystems, and writing the code generator you will want by month three. SpringBlade has already made those decisions, and the README is candid that some of them are opinionated, such as the self-built auth and Secure modules instead of Spring Security and OAuth2 directly.

The trade is control for time. If your team has strong Spring Security experience and specific auth requirements, the stock path is likely cheaper over a two-year horizon because every debugging session lands in documentation you can read. If your team wants a working multi-tenant skeleton and is willing to learn SpringBlade's conventions, the repository saves the integration phase. There is also a middle option the README itself points at: the SpringBoot version of the backend lives on a separate branch, at gitee.com/smallc/SpringBlade/tree/boot/, for teams that want the platform without the full microservice topology.

Maintenance, licensing and what an upgrade actually costs

The repository is not archived, and the last push was on 2026-09-18, the same day as the v5.0.2 release. The three most recent releases are close together: v5.0.0 on 2026-07-30, v5.0.1 on 2026-08-11 and v5.0.2 on 2026-09-18. That cadence tells you releases are happening; it does not tell you how much of the change is additive versus breaking, and the release notes as given are one-line summaries rather than migration guides.

The upgrade cost is set by the version matrix. v5.0.0 is described as a refactor and upgrade to SpringBoot4, SpringCloud2025, JDK21 and TypeScript. A jump of that size is not a patch upgrade. Any team adopting the 5.x line should expect that future Spring Cloud releases will pull the platform forward, and that internal libraries lagging behind will block the move.

On licensing, the repository is Apache-2.0, which permits commercial use and modification under the terms of that licence. What the README does not clarify is the boundary between the open source repository and the paid offerings: the membership plan, the BladeX enterprise platform, the data screen, the IoT platform and the AI model platform are all listed separately, and the security manual is hosted outside the repository on Yuque. The README does not state which code is covered by which arrangement. That is a question for whoever handles licensing at your organization, and it should be answered from the project's own materials rather than assumed from the Apache-2.0 badge.

Editorial conclusion

Adopt SpringBlade when your team already writes Java on Spring Boot and you want multi-tenant groundwork, gateway, auth and code generation in one repository rather than assembled module by module. Skip it if you need an English-language documentation path, a small single-service application, or a stack you can upgrade without reading Chinese release notes. Before committing, verify three things: that the blade-core-bom artifact on Maven Central matches the version you intend to run, that your Nacos 3.2.2 deployment is reachable from every service, and that the BladeX membership terms cover the modules you actually plan to ship. The repository itself is Apache-2.0, but the commercial platform behind it is not the same thing, and that distinction is the first thing to settle.

Frequently asked questions

Official sources

1. chillzhuang/SpringBlade on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases