opsli-boot: a low code admin platform built on Spring Boot

A platform for the repetitive 70 percent

OPSLI is described in its own words as a low code rapid platform for zero code development, built to make admin management systems simpler, and the repository description spells out the ambition: a rapid development platform based on Spring Boot, Vue and Element UI, with a front end and back end separated architecture, hot pluggable business modules, high plugin extensibility, concise code and rich features, ready to use out of the box, to help Java projects solve 70 percent of the repetitive work so that development can focus on business logic.

That last claim is the one to test, because a low code platform is a bet that the repetitive work is predictable enough to generate. For a back office with users, roles, menus, dictionaries, audit logs and a reporting screen, that bet usually pays. For a system with unusual domain logic, it pays less.

The audience is therefore a Java developer starting an admin or SaaS product, not a team looking for a general purpose framework. The front end is a separate repository, opsli-ui, and the one it uses is vue-admin-beautiful, described as the open source version based on element-ui, so both the visual layer and the platform are open source.

There are public addresses to check before you commit. The site is opsli.com, the documentation is a wiki at wiki.opsli.bedebug.com, there is a live demo at demo.opsli.bedebug.com with the account demo and the password Aa123456, and a second set of credentials, admin and 123456, for the database monitoring and system interface section. The author maintains a blog at bedebug.com, and there is a QQ group, 724850675, as a support channel.

The licence is Apache 2.0, the last push was on 2026-04-20, and the releases are 2.2.0 from 2025-06-02, 2.2.1 from 2025-06-08 and a 2.1.4-fix from 2024-03-28.

The hot plug structure: modulars and plugins

The repository layout is the clearest statement of the architecture, and it starts with the module names rather than with a package tree.

At the top level there are five Maven modules. opsli-api is the external API control centre, and its own tree breaks into base for the API foundations, web for the web layer, and warpper for the API wrapper objects. opsli-base-support holds the shared code, split into opsli-common with the annotation classes, constants, enums, exception classes, message types, thread related code and utilities, and opsli-core with the API interfaces, the autoconfiguration with its conf and properties subpackages, the base Entity and Service classes, the cache handling, the eventbus for messages and events, the filters with an AOP aspect package and a Spring interceptor package, the exception handler, the context data holder, the system listeners and the log handling.

Then there are opsli-modulars, opsli-plugins and opsli-starter, and those three names are the ones that carry the hot plug promise. The description says the architecture is front end and back end separated with hot pluggable business modules and high plugin extensibility, and the directory names are where that lives. The starter is the module that produces the runnable jar, which the Dockerfile copies.

The structure of opsli-core is worth noting for a specific reason. There is a dedicated cache package, a dedicated eventbus package, a filters package with both an AOP aspect directory and an interceptor directory, a holder package for context data, and a listener package for system listeners. That is a platform layer rather than an application layer, and it is why the platform can offer the cross cutting features in the feature list without each business module implementing them.

The whole thing is a Maven build with a root pom.xml, plus push.sh and push.bat scripts for the release process and a db-file/ directory for the database schema.

The version matrix pins JDK 22 and Spring Boot 3.4

The README publishes a version table for what it calls the single machine edition, and it is a useful compatibility check because these are the exact versions the project is built and tested against.

The Java side is jdk 22 with springboot 3.4.6, mybatis-plus 3.5.12 and pagehelper 2.1.0. The connection and data layer is druid 1.2.25, dynamic 4.3.1, fastjson 1.2.83 and transmittable 2.14.5, the utility layer is hutool 5.8.38, easyexcel 4.0.3 and captcha 1.6.2, and the caching and collection layer is guava 33.4.8-jre, enjoy 5.2.2 and caffeine 3.1.8.

Two of those deserve a pause. fastjson is pinned at 1.2.83, so the project has made a deliberate choice there and an organisation with a policy on JSON libraries will want to know about it. And enjoy 5.2.2 is the JFinal template engine, which turns up in the feature list too, since the code generator is built on it.

The JDK 22 requirement is the practical gate. The project is not source compatible with an older Java release, and the Docker image matches, since the base image is azul/zulu-openjdk:22-jre. If your organisation standardises on JDK 17 or 21, this platform needs a decision from you before it needs one from the build.

The badge row in the README confirms the headline versions independently, with spring-boot 3.4.6.RELEASE, mybatis-plus 3.5.12 and hutool 5.8.38.

Security features that are specific rather than generic

The feature list is where a platform like this differentiates itself, and the OPSLI entries are concrete enough to judge.

登录安全, the login security item, says login data uses a bidirectional encryption mode with a one click switch for the encryption key in the back end, to protect the privacy of logged in users. 数据安全, data security, supports custom annotations with one click data encryption, which means you annotate a field and the persistence layer handles it. 身份安全, identity security, adds an independent identity authentication step when a user changes their email or phone number or forgets their password, rather than treating those as ordinary profile edits.

The caching item is the one that stands out technically: 采用自研的 Security Cache，解决缓存穿透、击穿、雪崩问题, a self developed Security Cache that addresses cache penetration, breakdown and avalanche. Cache penetration, where a request for a key that does not exist hits the database every time, cache breakdown, where a hot key expires and many requests fall through at once, and cache avalanche, where many keys expire together, are three different problems with three different fixes, and a platform that claims all three is making a specific claim about its cache layer rather than a generic one.

The other two structural features are about the API and the login surface. 高扩展API管控 says the platform automatically supports v1 through vn multiple versions and multi terminal interface compatibility, so business extensions do not collide. 高扩展登录 says the login layer is a highly extensible interface rebuilt on Spring Security, so email, phone, account and password, and third party logins can be added later.

Both of those are the kind of thing that is expensive to retrofit and cheap to start with, which is the argument for a platform in the first place.

The code generator uses the Enjoy template engine

The code generation feature is the centre of a low code platform, and OPSLI describes it as 采用自研的代码生成器+Jfinal Enjoy 模板引擎，在线可视化生成前后端代码，可自定义生成代码模版, a self developed code generator combined with the JFinal Enjoy template engine that generates front end and back end code online and visually, with customisable code templates.

Three properties of that sentence matter for an evaluation.

The first is that it generates both sides. A generator that only produces the Java controller and service leaves you writing the Vue form by hand, which is where most of the tedium lives in an admin system. Generating the front end as well is the difference between saving half the work and saving most of it.

The second is that the templates are customisable. A generator whose output you cannot change is a straitjacket, because the generated code will not match the conventions of your own codebase. The template mechanism is the escape hatch, and it is the reason to prefer a generator built on a template engine over one with hard coded emitters.

The third is that it is online and visual, which means the generation happens through the running application rather than from a command line tool. For a team where a product manager or a junior developer is the person who needs a new CRUD screen, that removes a step, and it is also where the plugin and modular structure of the repository becomes relevant, since the generated code and the modules it lands in have to coexist.

Online documentation is provided too: 通过接入SpringDoc，实现在线API文档的查看与调试, which is SpringDoc, so the API documentation is browsable and debuggable from the running service.

The Docker image is a JRE and a fat jar

The deployment files are short and show the packaging model.

The Dockerfile starts from azul/zulu-openjdk:22-jre, sets the time zone to Asia/Shanghai, and works in /usr/local/opsli/opsli-boot. It copies the built jar from the starter module, which is the only artefact that goes into the image:

# 拷贝Jar
COPY ./opsli-starter/target/*.jar ./app.jar

# 启动镜像
ENTRYPOINT ["java", "-Dfile.encoding=utf-8", "-Djava.security.egd=file:/dev/./urandom", "-jar", "app.jar"]
CMD ["-Xmx2048m", "-Xms2048m",  "-XX:+UseG1GC", "-XX:MaxGCPauseMillis=200", "--spring.profiles.active=dev"]

# 暴露端口
EXPOSE 7000

So the image contains no build toolchain and no source, just a JRE and the jar, which is the right shape for a deployment artefact. The entrypoint sets the file encoding to UTF-8 and points the security entropy source at the device, both of which matter for a Chinese language application and for a JVM that otherwise blocks on entropy at startup.

The compose file adds the runtime configuration. The service builds from the repository root, restarts on failure, and runs with a heap of 2048 megabytes fixed at both the maximum and the minimum, the G1 garbage collector, a 200 millisecond maximum pause target, and the test Spring profile active:

services:
  opsli-boot:
    build: ./
    restart: on-failure
    container_name: opsli-boot
    image: opsli-boot
    environment:
      TZ: Asia/Shanghai
      LANG: en_US.UTF-8
    command:
      - -Xmx2048m
      - -Xms2048m
      - -XX:+UseG1GC
      - -XX:MaxGCPauseMillis=200
      - --spring.profiles.active=test
    privileged: true
    ports:
      - "7000:7000"

Two details in that file deserve attention from a reviewer. The container runs with privileged: true, which grants far more capability than a web service needs and is worth understanding before it reaches a shared host. And it mounts a logs volume from a host path, which means the log directory is outside the container and survives a rebuild. There is also a second compose file, docker-compose-server.yml, for the server arrangement, and a db-file/ directory at the repository root for the database.

Where a low code platform is the wrong choice

The honest limits of this approach are worth stating before a team commits to it.

The first is that the platform is the design. Everything the feature list promises, the login extensions, the versioned APIs, the encryption, the multi tenancy, the cache, the code generation, arrives as part of a framework with its own opinions, its own module layout and its own dependency versions. For an application that fits that shape, that is a saving. For one that does not, you are adapting your requirements to the platform rather than the other way round, and the adaptation is the work you were trying to avoid.

The second is the dependency list itself. Druid, dynamic datasources, fastjson on the 1.x line, transmittable, hutool, easyexcel, captcha, guava, enjoy and caffeine is a substantial set of third party code in the request path of every admin action, and each one is a version to track and a policy to check.

The third is the front end, and here the platform gives you a real choice. The front end is vue-admin-beautiful, an open source project based on element-ui, and it can be used with a back end you write yourself. If your team already has a Spring Boot service and wants an admin console, taking that front end and wiring it to your own API gives you the interface without the platform, and the difference in approach is exactly that: the platform generates both sides from a shared model, whereas the alternative keeps your own back end and only borrows the screens.

Fourth, the project's own documentation is a wiki rather than a set of files in the repository, and the quick start in the README is a demo site with published credentials. For a platform you intend to run in production, the documentation link, the licensing and the upgrade path from version 2.1 to 2.2 are the things to check first, along with how the hot plug modules behave across an upgrade.

Editorial conclusion

Adopt opsli-boot if you are building a Chinese market admin or SaaS back end in Java and want the repetitive half of the work already done, especially the code generator, the multi tenant model, the versioned API layer and the login extension points. Do not adopt it if you need a light weight service, if you cannot accept a platform shaped dependency list, or if your team would rather own the admin front end itself. Verify first that your JDK is 22 and your Spring Boot line is 3.4.x, that the demo credentials and the documentation wiki give you what the README leaves out, and that the plugin and modular directories in this repository are where you expect the extension points to live before you design around them.

Frequently asked questions

Official sources

1. hiparker/opsli-boot on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases