dromara/lamp-cloud: a Spring Cloud multi-tenant backend scaffold

What lamp-cloud actually is, and what it is not

lamp-cloud is a Java microservice scaffold from the dromara organisation, described in its README as a "微服务中后台快速开发平台" (a rapid development platform for microservice admin backends) built on Spring Cloud Alibaba, Spring Cloud and Spring Boot.

The stated focus is multi-tenant SaaS architecture. The README says the project has implemented several isolation modes: large tenants nesting small tenants, database isolation, field isolation, and a no-tenant mode. The same codebase can also be used as a plain non-SaaS foundation, which is why the README lists both a tenant and a non-tenant demo. The project explicitly says it aims to provide framework capability and does not cover concrete business logic. That sentence matters more than any feature list: you are adopting a starting point, and every business table, workflow and permission rule is still yours to write.

The audience is narrower than the description suggests. The README names individual learners and small and medium enterprises as the intended users. That is an honest framing. This is not a platform you deploy and hand to a business team on day one.

How tenant isolation and the service split work

The repository layout shows the architecture rather than describing it. Top-level directories include lamp-gateway, lamp-oauth, lamp-system, lamp-base, lamp-generator, lamp-support, lamp-public and lamp-dependencies-parent. The names suggest the split: a gateway for routing and authentication, an OAuth service, a system service for the platform's own administration, a base service, a code generator, and a support module. The README also states that the gateway performs unified authentication and that the project implements its own RBAC system based on tenant applications.

The isolation modes are the part worth understanding before you commit. Database isolation means each tenant gets its own datasource. Schema isolation means tenants share a database instance but are separated by schema. Field isolation means tenants share tables and rows are separated by a tenant column. The repository description calls these pluggable, which is the practical claim: you choose a mode rather than being locked into one. The cost is that the choice propagates. A team that starts with field isolation and later moves to datasource isolation is changing how data is routed, not just a configuration value.

The broader stack is listed in the README: Spring Cloud Alibaba, Spring Boot, MyBatis, Seata for distributed transactions, Sentinel, RabbitMQ, FastDFS or MinIO for file storage, and SkyWalking for tracing.

Installing lamp-cloud: what the README does and does not give you

This is where the project is weakest for a new adopter. The README does not contain build or run instructions. It contains links. The homepage is tangyh.top, and the documentation lives under tangyh.top/doc/. There is also a WeChat mini program advertised for reading the documentation for free, which tells you where the project expects its users to go.

What the README does specify is dependency order. lamp-cloud depends on lamp-util, and lamp-job also depends on lamp-util. The stated compilation order is therefore lamp-util, then lamp-cloud, then lamp-job. If you clone lamp-cloud alone and build it, the missing lamp-util is the first thing you will hit. The README is also explicit that new users should study and use the java17/5.x branch and that the other branches are older code.

git clone https://github.com/dromara/lamp-cloud.git

Cloning gives you the default branch, which the repository identifies as java17/5.x. The README's instruction to use that branch is therefore a confirmation rather than a checkout you have to perform, but it protects you from working on a stale fork.

cd lamp-cloud

Once you are in the repository root, note that pom.xml sits there alongside the module directories. Because lamp-cloud depends on lamp-util, lamp-util has to be available to your build before lamp-cloud resolves. The README gives the order but not the exact commands, so the sequence to follow is the one it states: lamp-util, then lamp-cloud, then lamp-job.

The README then points you at the demo deployments to see what the running system looks like: max-datasource.tangyh.top for datasource mode, max-column.tangyh.top for field mode, and none.tangyh.top for the non-tenant mode. Those are the fastest way to judge whether the scaffold's defaults match what you want to build.

The open source edition is not the whole project

The README states plainly that the project is split into an open source edition and an enterprise commercial edition. The open source edition is what you find on GitHub and Gitee and is licensed under Apache. The sponsored edition is hosted on a private GitLab and requires purchasing an account. The README links to a feature comparison page at tangyh.top/vip/.

This is the single most important thing to check before investing time. The README does not enumerate which features are withheld from the open source edition. It only says a comparison exists. If your evaluation depends on a specific capability, you have to open that comparison page and confirm the capability is in the edition you are willing to use. Reading the feature list in the README and assuming it all ships in the Apache-licensed code is a mistake the README itself warns against, indirectly, by mentioning the split at all.

The licence section is unusually direct for an Apache-2.0 project. It restates the standard conditions: include the licence, note modified files, retain notices, and do not imply your additions change the licence. It then adds a request that goes beyond the licence text: if you borrow or learn from the source, the README asks you to state the attribution prominently in your own source and documentation and link back to the GitHub repository. That is a request, not an Apache-2.0 condition, and it does not bind you legally. It does tell you what the maintainer expects from commercial users.

Where lamp-cloud is the wrong choice

The project is not a product, and treating it as one leads to a bad outcome. The README says the aim is framework capability without concrete business logic, which means everything specific to your domain is absent. If you need an admin panel running this week, a scaffold with tenant isolation modes and a code generator does not shorten that path as much as the feature list implies.

The documentation gap is the second problem. The README is a landing page with links, not a manual. Installation, configuration and the details of each isolation mode live on an external site, and part of that documentation is delivered through a mini program. For a team evaluating the project in a corporate environment, that distribution model may not fit internal documentation or procurement processes.

Third, the stack is opinionated and heavy. Spring Cloud Alibaba, Seata, Sentinel, RabbitMQ and SkyWalking are a lot of moving parts. If your team is not already running these, the operational surface of the scaffold exceeds the application you intend to build on top of it. A single Spring Boot application with a tenant column would be smaller and easier to reason about.

Alternatives and how they differ in approach

The README itself points to a related project, MDP (主数据平台), described as focused on single sign-on, open platform and basic management platform solutions. That is a different centre of gravity: MDP starts from identity and master data, while lamp-cloud starts from a tenant-aware microservice scaffold with RBAC and a gateway. If your problem is centralised login and master data rather than tenant isolation for a multi-service backend, MDP is the closer fit and the README treats it as a case study rather than a competitor.

The other comparison the README invites is the front end. lamp-web is a separate repository based on vben-admin, and the author lists contributions to vue-vben-admin and soybean-admin. The demo deployments come in vben5 and vben2 variants. That means lamp-cloud is a backend decision that carries a frontend assumption with it. If you already have a frontend, you are adopting the backend half of an opinionated pair.

Against a plain Spring Boot monolith, the difference is architectural rather than feature-level. A monolith gives you one deployable and no gateway, no OAuth service and no distributed transaction coordinator. lamp-cloud gives you those as separate services and asks you to operate them. The README's claim that the project suits parallel development across multiple business systems and multiple services is exactly the trade: more coordination cost up front, in exchange for services that can be developed and scaled independently.

Maintenance, branches and upgrade cost

The repository is not archived, and the last push was on 2026-10-09. That is a current signal. The repository has no published GitHub releases, so there is no published version history to reason about. If you need a tagged release to pin, the repository does not show one.

The branch situation is the main upgrade consideration. The README states that new users should use java17/5.x and that other branches are old code, while the description also mentions support for JDK 21, JDK 17 and JDK 8. Those two statements sit together awkwardly: the supported JDK range spans three major versions, but the recommended branch is named for one of them. A team on JDK 8 or JDK 21 should confirm with the documentation which branch is actually intended for their runtime before starting, because the README does not map JDKs to branches.

Upgrade cost also comes from the dependency graph. lamp-cloud depends on lamp-util, and lamp-job depends on lamp-util. A change in the shared utility project can affect both, so upgrading lamp-cloud in isolation is not the unit of work. Plan on tracking lamp-util alongside it. The compilation order the README gives, lamp-util then lamp-cloud then lamp-job, is also the order in which a broken upgrade will surface.

Editorial conclusion

Adopt lamp-cloud if you are building a Java 17 Spring Cloud Alibaba admin backend and want tenant isolation, RBAC and gateway authentication already wired together. Do not adopt it if you need a documented, one-command install, if you are not on Spring Cloud Alibaba, or if you want a finished product rather than a scaffold. Before committing, verify what the open source edition includes against the paid edition comparison page, confirm that the java17/5.x branch is the one you are cloning, and check the build order lamp-util, then lamp-cloud, then lamp-job.

Frequently asked questions

Official sources

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