Admin3 ships Spring Boot and Vue permissions code with no security framework attached

Sessions in the database, which is the whole point of the design

Admin3's distinguishing claim is that it implements session management and permission control without using any security framework. The README describes the result as an elegant implementation of session handling plus access control, supporting request URL interception and menu and button level permissions.

The session storage choice is the part that produces visible behaviour. Sessions are cached in the database as a second level cache, which means a restart does not lose login state. That is a real difference from in-memory sessions in an embedded servlet container, and it is the reason a deployment restart or a horizontal scale does not log everyone out.

The project positions itself narrowly and honestly. It calls itself a lightweight admin framework that provides a best practice solution for user and permission management core features, and says it deliberately does not wrap things too heavily. The intended uses are second-phase custom development on a base project, taking on client work, and studying source code. Nobody is meant to install it and consider the product finished.

The feature list adds two things beyond permissions. Operation logs are marked as done in the todo list. File upload is marked as done too, with a unified wrapper over third party object storage services and support for changing a user avatar. Internationalisation is listed as not done.

The stack behind this is Java 21 and Spring Boot 3.2 on the server, TypeScript, Vite 3, Vue 3 and Element Plus on the client, with Spring Data JPA at the persistence layer so more than one database can be supported.

Local setup: five steps, two URLs

The documented local path is short enough to follow exactly. Get the source with git, create a database named `admin3` with UTF-8 encoding, edit `application.yml` to set your MySQL account and password, then start the service.

Two addresses matter once it is up. The admin console is at http://localhost:8080/admin3, and the Swagger UI is at http://localhost:8080/admin3/swagger-ui/index.html. The `/admin3` context path is why both addresses carry the prefix, and it is worth noting now if you plan to reverse proxy behind a gateway, because the base path is baked into both.

The stated software requirements are JDK 17, MySQL 8.0 and Maven 3.6.0 or later. Note the gap between the requirements list and the project description: the description says the backend is built on Java 21, while the software requirements name JDK 17 as what you need to run it.

A one-click path also exists through Gitpod, and the repository carries a `.gitpod.yml` plus a `gitpod/` directory. There is a live demo at https://admin3.wetech.tech with three pre-made accounts, and the README is direct about what they are for: `admin / 123456` has all permissions, `employee / employee` has partial permissions, and `guest / guest` is view only. Those credentials are the fastest way to see what each permission level actually renders.

For anything beyond the quick start, the README links five documents in `docs/`: authority management, directory structure, API reference, object storage, and common commands.

Docker Compose runs three services on non-standard host ports

The compose file is the clearest view of the topology, and it deliberately avoids the default host ports so the stack does not fight a local MySQL install.

  mysql:
    image: mysql:8.0
    container_name: admin3-mysql
    environment:
      MYSQL_ROOT_PASSWORD: 123456
      MYSQL_DATABASE: admin3
      MYSQL_CHARACTER_SET_SERVER: utf8mb4
      MYSQL_COLLATION_SERVER: utf8mb4_unicode_ci
      TZ: Asia/Shanghai
    ports:
      - "3307:3306"

The database publishes `3307` on the host for `3306` in the container, sets the server charset to `utf8mb4` and the collation to `utf8mb4_unicode_ci`, and pins the timezone to Asia/Shanghai. It has a healthcheck using `mysqladmin ping -h localhost` on a ten second interval with five retries, and a named volume `mysql_data` mounted at the data directory.

The backend builds from `Dockerfile.backend`, publishes `18080:8080`, and reaches the database over the internal network at `jdbc:mysql://mysql:3306/admin3`. It declares `depends_on` the database with the `service_healthy` condition, so the backend waits for the ping rather than starting into a connection race. Three datasource settings are passed as environment variables, including `SPRING_JPA_HIBERNATE_DDL_AUTO: update`.

That last one deserves a decision rather than a shrug. Hibernate updating the schema on every boot is convenient for a demo and undesirable in an environment where you manage migrations elsewhere, so decide before you point it at anything you care about.

The frontend builds from `Dockerfile.frontend`, publishes `18081:80`, and depends only on the backend having started, not on its health. All three services sit on a bridge network called `admin3-network`, and each uses `restart: unless-stopped`. The two credentials in the file, root password `123456` and datasource username `root`, are demo values and must be changed before this runs anywhere shared.

Frontend assets can be embedded or deployed on their own

The repository root splits into `admin3-server/` and `admin3-ui/`, with a root `pom.xml`, `mvnw` and `mvnw.cmd` wrappers, a `.mvn/` directory, a `docker-compose.yml` and a `.gitpod.yml`.

One of the listed features is that frontend assets support both independent deployment and embedding into the backend through webjars. That choice is more consequential than it sounds. Embedded, the whole admin console ships as a single artefact and the Spring application serves it, which is simple to deploy but means every UI change requires a backend rebuild and redeploy. Split, the UI is built and hosted separately and the backend is only an API, which lets you change the front end without touching the server but requires you to deal with cross-origin requests and two deploys.

The compose file chooses the split arrangement, with a separate frontend container serving on port 80 and proxying or calling the backend. Nothing in the compose file shows the proxy configuration between them, so that wiring is inside `Dockerfile.frontend` or the dev server setup rather than declared here.

AOT native image support is also claimed, with the stated benefit of saving at least 50 percent of memory compared with a traditional JVM form. That is a project claim rather than something the documentation shows a measurement for, so treat it as a reason to try the native build rather than as a budget figure to plan against.

Storage abstraction: local upload or anything speaking S3

The unified object storage wrapper is described as isolating the application from the location of uploaded files, and supporting local upload as well as any S3 standard object storage service, with 阿里云, 华为云 and MinIO given as examples.

The architectural point is that the application never holds a filesystem path or an S3 bucket name in its own logic. It asks for a file, and the abstraction decides whether that lands on local disk or in a bucket. That is the difference between a project that has one file upload endpoint and one that can be pointed at cloud storage by configuration.

The documentation for it lives in `docs/storage.md`, alongside `docs/api-reference.md` for endpoints and `docs/authority-management.md` for how the permission model is structured. Since the feature is that storage is swappable, that document is the place to look before assuming local behaviour.

What the README does not cover, and what you would have to determine yourself, is the configuration keys for switching backends, whether uploads can be served through signed URLs when stored in S3, and what happens to a local development upload directory in a container. The compose file mounts no volume for the backend service, so if it writes uploads to local disk inside the container, they will not survive a recreate.

Testing claims and the gap between the demo and a product

The README states that all interfaces have end to end test coverage and that the full test suite runs on every code change, with the purpose of guaranteeing the functionality is usable. Coverage is reported through the `.github/` workflow and the repository layout includes `docs/`, `.editorconfig` and a `.gitignore`, which is consistent with a project that runs CI on pull requests.

Treat that as a statement about the code the maintainer shipped rather than about the code you will write after forking. The gap to understand is between a permissions reference implementation and an admin product. The todo list has internationalisation unchecked, with a pointer to the issue tracker for anything else, and the project's own framing is that it is a base project for customisation, client work and source study.

That framing shapes maintenance risk. The repository is not archived, and the last push was on 2026-04-30, which is inside a six month window of today's date but not recent churn by the standards of a Spring Boot project. A recent release is 3.0.0, dated 2025-05-10; the provided release history does not show whether there is a stream of patches to follow. If you fork it, you own the security patches, the Spring Boot upgrades and the Java 21 migration path yourself.

The MIT licence permits forking, modification and commercial distribution, provided you follow its notice and licence requirements. The README links the licence file directly.

Editorial conclusion

Adopt Admin3 when you want a working permissions backend to read, copy and modify rather than configure from scratch, since it implements sessions, URL interception, menu and button permissions, operation logs and S3 compatible storage with documented command references, and it runs on JDK 17 with MySQL 8.0. Skip it if you need internationalisation, an internationalisation roadmap item, or a maintained upstream, because the last push was on 2026-04-30 with a recent release 3.0.0 dated 2025-05-10. Before you build on it, change the demo credentials and the MySQL root password, then confirm `SPRING_JPA_HIBERNATE_DDL_AUTO: update` is acceptable in your environment, because the shipped compose file ships schema changes as automatic DDL updates on every boot.

Frequently asked questions

Official sources

1. cjbi/admin3 on GitHub
2. License: MIT
3. Project website
4. README
5. Releases