Diboot: a Java low-code framework built around code generation

Three modes of building, and the promise that most SQL disappears

Diboot is described as a low-code development platform built for developers, with the goal of simplifying complex work and automating repetitive work. The project puts its value in a single claim: with Diboot, most SQL no longer needs to be written, the code is greatly simplified, and developers can concentrate on the business. The project description quantifies this as a base framework that can remove the need for 90 percent of SQL, which is a vendor figure rather than a measured one, but it does explain the shape of the product.

The second claim in the description is about the range of modes. You can work in pro-code, low-code or no-code and switch between them freely, and the third is that it has a no-code model form, page and flow design capability along with code generation.

Those three modes map onto three layers of the product, and that mapping is the thing to understand before reading the feature list. No-code is the visual layer, where a model, a page, a form or a flow is configured rather than coded. Low-code is the generator, Devtools, which turns a designed model into backend, frontend, association and mobile code, including a non-overwriting update mode so that regenerating does not destroy your hand-written edits. Pro-code is what you get when neither of those is enough: the generated code is ordinary code, and you extend it directly.

The stated boundary of the no-code layer is important, because it is where these platforms usually disappoint. The documentation is explicit that where no-code cannot satisfy a complex scenario, you extend the generated code quickly, and that there is no extension limitation. So the promise is not that everything is configurable, but that configuration covers the common cases and code covers the rest without a rewrite.

The module layout is the architecture

The top-level directory listing is a set of Maven modules, and the names describe the platform more precisely than the feature list does.

`diboot-core/` is the foundation, and `diboot-core-starter/` is its Spring Boot starter. `diboot-devtools/` is the generator, and everything else builds on it. `diboot-admin-ui/` is the companion frontend, described as a self-built admin framework based on Vue 3, Vite, Pinia, Element Plus and TypeScript, and the preview screenshots show a menu resource configuration screen and a role permission configuration screen, so the admin console covers permissions as well as CRUD.

The rest are vertical starters, each a capability packaged for a project to depend on: `diboot-iam-starter/` for identity and access, `diboot-file-starter/` for files, `diboot-notification-starter/` for notification, `diboot-scheduler-starter/` for scheduled jobs, `diboot-tenant-starter/` for multi-tenancy, `diboot-mobile-starter/` with a `diboot-mobile-ui/` frontend for mobile, and `diboot-ai-starter/` for the AI features that appeared in recent versions.

Two more entries are worth naming. `rest-api-example/` is a runnable example of the REST layer, which is the fastest way to see what the framework generates for a given model. And `pom.xml` at the root makes it a single aggregator build, so all modules build together.

The topic tags put the technology line in plain terms: Spring, Spring Boot, Spring Cloud, MyBatis, MyBatis Plus, Vue and Flowable. Flowable is the workflow engine, which is consistent with the flow design capability in the no-code layer, and MyBatis Plus is the persistence layer the generated code sits on.

Devtools generates the code you would otherwise write twice

The generator is where the low-code claim is cashed out, and the feature list for it is specific about what it covers: backend code, frontend code, associations, complex master-detail pages, mobile code, a non-overwriting update mode, and AI-assisted naming.

Backend and frontend generation together is the significant part, because a low-code tool that only generates the server side leaves you writing the screens by hand, and the frontend is where the effort usually is. Here both are produced from the same designed model, which is what makes the two sides consistent with each other rather than two artefacts you keep in sync by hand.

The non-overwriting update mode is what makes generation usable over time. Without it, every regeneration is a merge conflict against your own edits, and the practical result is that developers stop regenerating and the model drifts from the code. With it, the generator can be re-run over a changed model and leave hand-written code in place.

AI-assisted naming is the newest addition and the one to treat carefully. It is listed among the Devtools capabilities, and the v3.9.0 release note mentions AI modeling with field addition and further page design tuning. Naming assistance is low risk because a name is a name, but it is worth checking what it does when the model already has a large number of fields, where naming consistency matters more than any single name.

The Devtools and Diboot projects are described as run on a non-commercial basis, with support invited through donations or by starring the repository. That is worth knowing if you are evaluating the project as a dependency in a commercial product, and it is separate from the licence question.

The no-code layer is a visual designer with forms and flows kept apart

The zero-code capabilities listed for the platform cover model design, page design, form design, flow design and data dashboards, with the claim that most features are configured directly.

The design decision worth isolating is that forms and flows are decoupled, that a flow can mount several forms, and that a form can be reused flexibly. In a system where a form is tied to a flow, a form that appears in two places has to be copied, and a flow change then breaks one of the copies. Separating them means the approval form, the rejection form and the notification form can be distinct objects that a single flow mounts, and the same form can appear in a different flow without duplication.

That is the sort of choice that is invisible in a screenshot and decisive in a large system, and it is a sign that the platform was designed against real enterprise workflows rather than as a demonstration.

The multi-tenancy, scheduler, notification, file and IAM starters sit alongside this in the module list, so the design surface and the runtime capabilities are separate concerns. A project can adopt the no-code designer for its admin screens and use the scheduler starter without touching the flow engine, which is a more modular arrangement than a single monolith framework usually offers.

Getting started means the website, Maven Central and a Chinese-first README

The repository does not contain install commands, and the documentation lives on the project site rather than in the tree.

The entry point given for new users is the getting started guide at `https://www.diboot.com/guide/beginner/bootstrap.html`, and the Maven Central badge points at the `com.diboot` group, with the artifact named `diboot-core-spring-boot-starter`. The project also maintains mirrors on Gitee, GitHub and Gitcode, and the README asks for issues and pull requests to be filed against the Gitee or GitHub repositories, with a QQ group and a WeChat group for technical discussion.

The starting point in the README is video rather than text. It links a walkthrough of building a CRM module without writing a line of code, a walkthrough of an OA system in three days, and a video on how the Diboot core achieves its performance. That tells you how the project expects to be understood, which is worth factoring in: a team that cannot read the Chinese documentation or follow the video walkthroughs will be evaluating this on documentation quality rather than on the platform itself.

The enterprise edition, described as covering zero-code, workflow and microservices, is a separate commercial offering listed on the site, so the boundary between what the Apache-2.0 licensed repository contains and what the paid edition adds is a question to ask before you plan an architecture around it. The repository itself is under the Apache-2.0 licence, with a `LICENSE` file and a separate `license.txt` at the root.

Where Diboot is the wrong tool

The clearest case is a project that has already committed to its own persistence and service layer. The value of Diboot is that it generates the code around your data model, and if you have already written that code, or intend to, the platform adds a generator you do not need and a runtime that sits between you and the framework you already use. Spring Boot with MyBatis Plus on its own is a perfectly serviceable stack; the argument for Diboot is productivity on top of it, not that the stack underneath is missing.

The second case is a team that needs to own every line. Code generation is convenient until the generated code is wrong in a way you cannot fix without forking the generator, and at that point you are maintaining a fork of a platform that expects to keep regenerating. The non-overwriting update mode reduces this risk, but it reduces it rather than removing it. A team that treats its service layer as long-lived product code rather than as scaffolding tends to be uncomfortable with this.

The third is a non-Chinese-speaking team, and this one is not about the code. The README is Chinese, the documentation and videos are Chinese, and the discussion channels are a QQ group and a WeChat group. The code itself is ordinary Java and the framework is Apache-2.0 licensed, so nothing prevents use outside China, but a team without Chinese reading will be relying on translation and on the community forums, and that is a support cost you should price in.

There is also a maintenance observation. The last push was on 2026-09-02, the same day as the v3.9.1 release, and the default branch is `develop-v3`, so the branch you get by default is a development branch rather than a released tag. The release history shows regular minor versions, v3.8.0 on 2025-10-15, v3.9.0 on 2026-07-06 and v3.9.1 on 2026-09-02, with the last of those described as a security upgrade, which is a signal to check your own version against it.

Editorial conclusion

Diboot fits a Java team that wants its admin screens, CRUD and workflow built from a model rather than typed out, and that is ready to own generated code afterwards, since the platform's own pitch is that you extend the generated result when zero-code configuration runs out. It does not fit a team that wants to keep its own persistence layer, because the value of the platform is precisely the code it generates around your data model. Before adopting, look at the `diboot-core/` and `diboot-devtools/` modules to see how much of the platform your project would actually depend on, and read the v3.9.1 release note, since it is a security upgrade and you should be moving to it from whatever v3.x you are on.

Frequently asked questions

Official sources

1. dibo-software/diboot on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases