What simple-admin-core wires into your go-zero admin backend

Six modules hanging off one core service

Simple Admin is a scaffold for distributed admin backends, and simple-admin-core is the service that everything else bolts onto. The repository description sets the range plainly: a microservice backend for small to large projects, with k8s deployment support and a background management system rather than one application. Five more modules surround the core, and the project counts all six as free. Core itself, a Backend UI built on Vben Admin, FMS for files, Job for scheduled tasks, MMS for members and MCMS as a message centre, each living in its own repository under the same author. A preview at vben5-preview.ryansu.tech takes the account `admin` and the password `simple-admin`, and a second preview covers the multi-tenant build with the same credentials under a separate enterprise; both are marked read only and neither accepts a sign-up. Licensing deserves a second reading: the six modules are described as free for commercial use, while the notice printed above them asks commercial users to keep every copyright notice in copy, logs and code, and sends anyone who strips one to a paid authorisation, and the badge labelled Apache2.0 links to opensource.org/licenses/MIT. The managed features inside the core cover users, departments, posts, a tree shaped menu, roles with multiple roles per user, dictionaries, token state with blacklisting, generated interface documentation and CRUD code generation.

Ent and Casbin split schema from permission

The direct requirements in `go.mod` read like a wiring diagram for one specific stack. The module path is github.com/suyuan32/simple-admin-core and the toolchain line reads go 1.26.0. Schema work belongs to entgo.io/ent at v0.14.6, permission work belongs to casbin/casbin/v3 at v3.11.0. Around them sit zeromicro/go-zero v1.10.3, google.golang.org/grpc v1.83.2 and google.golang.org/protobuf v1.36.12 for transport, redis/go-redis/v9 v9.22.0 with bsm/redislock v0.10.0 for shared state and distributed locking, duke-git/lancet/v2 v2.3.9 and gofrs/uuid/v5 v5.5.1 as utilities, mojocn/base64Captcha v1.3.8 for image captcha, golang.org/x/oauth2 v0.36.0, and larksuite/oapi-sdk-go/v3 v3.11.0 for Lark. Two top level trees, `api/` and `rpc/`, sit side by side, which is go-zero's own split between HTTP handlers and gRPC services, and the feature list promises code generation for all three ends, Web, API and RPC. Two Makefile switches confirm the intent: `PROJECT_STYLE=go_zero` pins the naming layout the generator produces, and `PROJECT_I18N=true` switches the internationalisation scaffolding on at code generation time rather than at runtime.

The Makefile is the repository's only build interface

Nothing else in the top level listing configures a build, so the variables at the top of the Makefile are the knobs you are expected to edit. `SERVICE=Core` with `SERVICE_STYLE=core` and the lowercase, snake and dash variants all set to core decides how the service gets spelled wherever a name is needed, while `PROJECT_STYLE=go_zero` fixes the file naming style the generator follows. `VERSION` is never typed in by hand: it comes from git describe --tags --always, and the comment above it tells you to set it yourself when git is not in use, which is exactly the case for a source tarball with no tags. `GOARCH=amd64` fixes the build architecture, so an arm64 or armv7 image needs that variable overridden on the command line. `ENT_FEATURE=sql/execquery,intercept,sql/modifier` records which official Ent features the schema code was generated with. The `docker` target then produces one image per side of the api and rpc split:

docker build -f Dockerfile-api -t ${DOCKER_USERNAME}/$(SERVICE_DASH)-api:${VERSION} .
docker build -f Dockerfile-rpc -t ${DOCKER_USERNAME}/$(SERVICE_DASH)-rpc:${VERSION} .

Two Dockerfiles, Dockerfile-api and Dockerfile-rpc, live next to a `deploy/` directory and a .dockerignore at the root, and `publish-docker` pushes the same two tags after a login that reads `DOCKER_PASSWORD` through a pipe, so credentials never sit in a shell history.

First build: two CLI tools, then two containers

There is no install command anywhere in the README, no clone line and no go run example, so the first executable step has to come from the repository itself. The project points readers at its Chinese documentation at http://doc.ryansu.tech/zh and at the separate repositories for the UI and the other five modules. What the Makefile supplies is the tool chain the workflow assumes, and the `tools` target installs both binaries in one step:

$(GO) install github.com/golangci/golangci-lint/cmd/golangci-lint@latest
$(GO) install github.com/go-swagger/go-swagger/cmd/swagger@latest

The Makefile defines GO as go and lets you override it, so the $(GO) prefix expands to whatever binary you point it at, and both installs land in the Go bin directory on your PATH. go-swagger matters because the documentation is generated from comments written inside the api files rather than kept by hand, which means the first thing worth doing after checkout is running it against those files. After that, the docker target is the next command worth running, and the image names resolve from DOCKER_USERNAME, SERVICE_DASH and VERSION, so a missing environment variable shows up as a literal dollar sign in your tag rather than as an error. What the README does not give you is the configuration surface. A `core.json` file sits at the repository root, no key inside it is printed anywhere, the api and rpc configuration files are not in the top level listing, and no port, environment variable or connection string appears in the repository, so a first successful start means reading the documentation site rather than the source tree.

Tests stop at two package trees and lint drops staticcheck

The test target is two commands and nothing else:

go test -v --cover ./api/internal/..
go test -v --cover ./rpc/internal/..

That covers `./api/internal/..` and `./rpc/internal/..` and nothing beyond them, so a team adding a package outside those two trees gets no run from this Makefile, while `--cover` prints a percentage with no threshold attached that could ever fail a build. The lint target is narrower still, running golangci-lint run -D staticcheck, which switches staticcheck off inside a project that otherwise leans on static analysis, and the tools target installs that linter at @latest rather than pinning it, so the set of checks your code passes moves when the tool moves rather than when the project changes. Pinning the linter in your own CI is the only way to get a reproducible result. For a scaffold sold on upgradeability, this is the part to know before you build on it.

Three version numbers disagree about the same scaffold

The newest tag is v1.8.7, dated 2026-08-14, and the Go-Zero, Ent and Casbin badges in the README match `go.mod` exactly at v1.10.3, v0.14.6 and v3.11.0, so the stale number is not a general documentation lag. The release badge still reads v1.8.6, `go.mod` pins the shared library github.com/suyuan32/simple-admin-common at v1.8.10, a higher number than the core module's own tag, and the last push landed on 2026-09-17. Earlier tags arrived on 2026-06-01 and 2026-03-30, a cadence of roughly two months that has held across three visible points. The practical consequence is concrete, and it is the detail a skim misses: because the shared library sits a minor version above the core tag, the core version is not a coordinate you can move by. Upgrading by tag number tells you nothing about which simple-admin-common you get, and the same goes for simple-admin-job and simple-admin-message-center, both pinned at v1.8.6 here. `go.mod` is the file to read after every update, which is a heavier habit than the one-click upgrade the project advertises.

The feature list names Kafka, the dependency block does not

Repository topics advertise asynq and rocketmq, and the feature list names kafka among the technologies used, yet none of those three appears in the direct requirement block of `go.mod`. What is there is ent, Casbin, go-zero, Redis with its lock, gRPC, protobuf, two utility libraries, a captcha package, an OAuth2 package and a Lark SDK. The same gap shows up on the login side: golang.org/x/oauth2 v0.36.0 and mojocn/base64Captcha v1.3.8 are direct dependencies, but no OAuth provider is ever named and the captcha switch is never described, so the login flow has to be reverse read out of the api tree. Native k8s support is claimed in the feature list and `deploy/` exists at the root, but no manifest, namespace or ingress appears in the repository listing, so the k8s story lives entirely in the documentation. Treat the metadata as a wish list and `go.mod` as the inventory, and the two Lark-related dependencies become a second thing to verify: the Lark SDK sits next to the message centre module, but which events it consumes is not written down anywhere.

When a plain go-zero service is the better fit

The honest alternative is to assemble the same shape yourself from zeromicro/go-zero v1.10.3 and entgo.io/ent v0.14.6 in a single binary, and the difference between the two routes is not the framework, it is what you inherit. Taking simple-admin-core means an api tree and an rpc tree talking over gRPC even when your business needs no second hop, three sibling modules pinned in `go.mod` whether or not you call their features, Redis plus a distributed lock in the dependency set from the first commit, and a paid module store sitting behind the six free ones. Starting from go-zero directly leaves you writing the RBAC layer, the menu tree, the code generator glue and the i18n wiring with your own hands. A single tenant internal tool with three tables gets more from the direct route, and so does anything that will not use multi-role permissions, menu-level route control or generated CRUD. A team that wants all three on day one gets more from the core, provided it reads `go.mod` before every upgrade and keeps its own copy of the config surface, since neither the README nor the repository root documents it.

Editorial conclusion

Adopt simple-admin-core when you are starting a Go admin backend that needs RBAC, menu trees, i18n and a generated api and rpc pair on day one, and when you can accept three sibling modules pinned in go.mod. Leave it for a single binary internal tool, a small CRUD service, or anything expecting Kafka, asynq or rocketmq workers, because none of the three reaches the direct requirements. Before writing business code, read core.json, the api and rpc configuration files, and the version pins in go.mod.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. suyuan32/simple-admin-core on GitHub