mysiteforme and the admin scaffold that writes its own boilerplate

A scaffold whose first job is generating the boring parts

mysiteforme is described as a lightweight system scaffold written while the author was learning Spring Boot, and its goal is to let a developer assemble their own admin backend and have the front end and back end base code generated for them. The module list is the clearest statement of intent: user management with add, edit, delete, query and status operations, role management where roles are assigned menus and operation permissions, menu management with multi-level navigation, and a permission system that reaches button level rather than stopping at page level.

Also present are login authentication, an operation log that records what users do, dictionary management for the static lookup data that every admin system accumulates, internationalisation for the fixed text on both sides, and scheduling through Quartz.

The project targets small and mid-sized systems, and it says so directly. A larger organisation with an existing identity system, an audit requirement or a permission model that does not match RBAC will find the generated modules a starting sketch rather than a foundation, and the cost of reshaping them exceeds the cost of writing them.

Two authentication options and a versioned framework stack

The backend stack is pinned in the project notes: Spring Boot 3.2.5 with Spring Security 6.2.4, MyBatis Plus 3.5.10.1, Quartz for scheduling, Redis for caching, Druid 1.2.20 for the connection pool, JDK 17, MySQL 8.0.32 and Maven 17.0.14. Authentication is JWT based.

One line in the stack description is worth pausing on: Spring Security is listed with Sa-Token as an alternative. That is a genuine fork in the design rather than a detail, because the two approaches differ in how much wiring a team has to write for authentication and authorization, and Sa-Token is often chosen precisely to reduce that wiring. A team that inherits this codebase inherits whichever choice was made, so that decision should be made deliberately rather than inherited.

The front end is a separate application. It uses Vue 3.x with Vite, Element Plus and Pinia, and the project states that it is based on the Art-design-pro template, described as a Vue 3, TypeScript, Vite and Element Plus admin template. The backend and front end are separated deliberately, so they can be deployed and developed independently.

The database has to be imported before anything will run

The quick start starts with the parts that are easy to get wrong. The runtime expectations are JDK 17 or newer, MySQL 8.0.32 or newer, Redis 7.2.1 or newer, Maven 17.0.14 or newer, and Node.js 22.14.0 or newer.

Then the schema. The root `db` folder holds `01_new_mysiteforme.sql` and `02_update.sql`, and the two files are imported into MySQL in that order, the first creating the schema and the second applying the updates. This is the point in the setup where a mistake is expensive, because the seeded data includes the menu tree and the permissions that the button-level control checks against.

After the import, the database and Redis connection settings are edited in `application.yml` to match the local environment, and the backend is started from the IDE or the command line by running the main class `com.mysiteforme.Application`. Two configuration files are involved before that, `application.yml` for the application and the environment files for the container path.

The Vue front end runs on pnpm from the server-ui directory

The front end is driven with pnpm, and the global install comes first:

npm install -g pnpm

Dependencies are then installed inside the `server-ui` directory:

pnpm install

The project documentation names a fallback for when that fails, which is worth knowing about because the failure it works around, post-install scripts, is exactly the kind of thing that breaks on a locked-down or offline machine:

pnpm install --ignore-scripts

With dependencies in place there are two commands that matter. The development server is started from the `server-ui` folder:

pnpm dev

and the production bundle is built with:

pnpm build

The default login is documented in the same place as the access address, and the credentials are `test` and `123456`, with the password changeable afterwards from the personal centre. A default account that is published in the README is fine for a local evaluation and is a problem the moment the application is reachable from a network, so the first thing to do with a deployment is change it.

Docker Compose wires MySQL, the backend and the front end together

The container path uses a base Compose file plus one overlay per environment, with the environment selected through `.env.dev` or `.env.prod`. The development startup is a single command:

docker-compose -f docker-compose.yml -f docker-compose-dev.yml --env-file .env.dev up --build -d

and the production equivalent swaps in the production overlay and environment file:

docker-compose -f docker-compose.yml -f docker-compose-prod.yml --env-file .env.prod up --build -d

Both stacks tear down the same way, with the environment again deciding which overlay is used:

docker-compose -f docker-compose.yml -f docker-compose-dev.yml --env-file .env.dev down

The Compose file itself shows the wiring. The backend publishes a port from the `BACKEND_PORT` variable, defaulting to 8080, and the front end is built from the `./server-ui` context. The database is the `mysql:8.0` image, and the `db` folder is mounted into the container's init directory, which is what lets the same SQL files used for a manual import seed a fresh container automatically:

      - "${BACKEND_PORT:-8080}:8080"

    image: mysql:8.0

The backend waits for the database using a health check, and the front end is configured to restart unless stopped. A `proxy/` directory holds the nginx configuration, so a deployment can put a reverse proxy in front of the two services.

File storage and IP lookup are the two settings worth reviewing first

Two pieces of the system are deliberately left pluggable, and both are configured from the running application rather than from code. File upload defaults to local storage, with Aliyun and Qiniu uploads available in the online configuration, and the site settings allow a switch between them once the alternative has been configured and tested. The same pattern applies to IP location: the default is the pconline IP lookup service, with the option to configure the Tencent service instead.

That design is a genuine strength for a scaffold that will meet a Chinese cloud deployment, and it is also the point where an adoption decision is easy to get wrong. A default that works in one region is a default that has to be changed before a deployment elsewhere, and the failure mode of a wrong IP lookup service is quiet rather than loud, since login records simply carry the wrong place.

The rest of the repository layout supports the same picture. There is a `server-admin/` backend project with its own Dockerfile and Maven `pom.xml`, a `server-ui/` front end project with separate development and production Dockerfiles, the `db/` folder of SQL, a `docs/` directory of project documentation, and a `DOCKER_DEPLOY.md` at the root for the container deployment details.

One tagged release and a project that keeps moving

mysiteforme is released under Apache License 2.0, with the licence text in the LICENSE.txt file at the root and a note that the project may be used, modified and distributed freely. For a team that wants to vendor the code into an internal product rather than run it as a service, that permissive licence is a low-friction starting point, though the obligations and any trademark considerations still need reading for the specific case.

The release history is thin. There is a single tag, v1.0.0, recorded as release-2025.0212 and dated 2025-02-12, and the last push to the repository was on 2026-05-07. The repository is not archived.

The gap between those two dates is the thing to plan around. A scaffold that is still receiving commits months after its only tagged release is a project whose code moves ahead of any version you can point at, so a team that needs a repeatable deployment should pin to a commit hash rather than to v1.0.0 and should expect to read the diffs between deployments. The project accepts issues and pull requests, and a deployment built on top of it will need its own tests around the permission model, because that is where a scaffold's assumptions meet your organisation's.

Editorial conclusion

mysiteforme fits a team that wants a running admin backend this week, with user, role, menu, permission and dictionary modules already in place, and that is comfortable editing SQL seeds and Compose files rather than expecting a framework to adapt itself. It is the wrong choice if you need a long release history, a supported upgrade path, or a permission model you do not want to reshape, since the only tag is v1.0.0 from 2025-02-12 and the last push was on 2026-05-07. Before adopting it, decide whether the Spring Security or the Sa-Token variant fits your team, then check the seeded SQL in `db/` and the environment files `.env.dev` and `.env.prod` for the credentials you would be deploying.

Frequently asked questions

Official sources

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