GoWind Admin ships one backend and three interchangeable admin frontends

Three frontends, one of which you keep

The defining choice in this scaffold is that the frontends are alternatives rather than a merged set. The README is explicit that the Vue3 Vben build with Ant Design Vue, the Vue3 Element Plus build and the React19 Antd build are three parallel implementations of the same backend, so that teams working in different stacks can each take the one they already know. Each team takes one, a deployment runs one, and once chosen the other two directories can be deleted, with the changes listed in a separate adoption document. The reason given is not to serve a team that needs both React and Vue at once but simply that different teams have different stacks, and the cost of keeping all three working is carried upstream rather than by the adopter. The demo addresses are published for all three so you can open them side by side and compare, with the same instruction attached: open each one, compare, and you will only want one of them.

Protobuf as the contract, code generation for both sides

The backend is Go on the go-kratos microservice framework with Protobuf and Buf, and the API contract is the Protobuf files. From that single contract the project generates the Go API and the TypeScript clients, and the Ent schema drives the ORM layer, with one-click CRUD scaffolding on top. A desktop visual code generator and a CLI accompany this, in a separate toolkit repository. The ORM is Ent or GORM, chosen by build tag, with Ent as the default, and the data stores are MySQL or PostgreSQL. The framing is that a team should not need deep understanding of the contract format to build features, which is the same argument the frontend choice makes. The scale of the stack is worth noting before you adopt it: the README describes the platform as production ready, with JWT authentication, SSE push, async task scheduling, Swagger documentation and one-command Docker deployment, and the feature list adds a script engine running Go, Lua and JavaScript with a multi-language hook plugin system. That is a large surface to inherit.

The authorisation engine defaults to allowing everything

The security story is the most important thing to read twice, because the defaults are not what a cautious deployment would want. The stack lists JWT for authentication and Casbin or OPA for authorisation, chosen at build time, and it says plainly that the default is noop with everything allowed. In other words, out of the box the authorisation layer authorises every request. What you get instead is the machinery to put a policy engine in place: multi-tenant, multi-role and multi-department support with menu, button and data-level permission control, and the policy engine is swappable between Casbin and OPA. On top of that sit TOTP multi-factor authentication, password policy, application-layer password encryption, dynamic RBAC with multi-tenant isolation, and scheduled backup rotation. The compliance framing is specific: the security capabilities are designed against the technical requirements of the Chinese Cybersecurity Multi-Level Protection Scheme 2.0, at level two and three, aimed at enterprise private deployments with high privacy requirements. That is a design reference rather than a certification, and the documentation should be read as a starting point rather than a compliance sign-off.

Audit logging with 180 day retention

The audit table is where the compliance angle becomes concrete. Six categories of audit log are covered, login, operation, API, data access, permission change and policy evaluation, and the client IP is recorded, with the first three categories additionally resolving a geographic origin from the front-end supplied `X-Reque` header. Retention is set at 180 days with archiving built in, which is the figure the MLPS 2.0 reference points to. The README also lists password policy, application-layer password encryption, TOTP MFA, dynamic RBAC with tenant isolation, and scheduled backup rotation as part of the same compliance story, all under a section titled security and compliance. The practical note for an evaluator is that the log volume of that design is substantial, six categories recorded on every relevant request, and the archiving behaviour is what keeps 180 days of it inside a disk budget.

Running the backend on Linux and on Windows

The backend commands run from the `backend` directory, and there are separate environment scripts for Linux and macOS development and production, and a PowerShell script for Windows development. On Linux and macOS the flow is: set the environment up, start the middleware only, then run the admin service. The script permission step is a find over three levels of subdirectories because a glob would miss `env/lib` and `deploy/sse`.

cd backend

find ./scripts -name '*.sh' -exec chmod +x {} +

./scripts/env/install_unix_dev.sh
./scripts/docker/libs_only.sh
gow run admin

The Docker layer has two modes. `full_deploy` starts the middleware together with the backend application, which suits a one-click demo or a production deployment, while `libs_only` starts only the middleware so the application runs from a local IDE for debugging, and that is the mode the documentation recommends for development. The production path swaps the first script for the production variant and the second for `full_deploy.sh`, and a further step wires the service under PM2. The Windows equivalent follows the same shape with PowerShell scripts, and needs the execution policy relaxed once for the current user.

Set-ExecutionPolicy RemoteSigned -Scope CurrentUser

.\scripts\env\install_windows_dev.ps1

.\scripts\docker\libs_only.ps1
gow run admin

The frontends live under frontend/admin and each has a port

The three frontends sit under `frontend/admin`, and the table in the README gives the directory, the start command and the port for each: React at `frontend/admin/react` on 15888 with `pnpm dev`, Vue Element at `frontend/admin/vue-element` on 15777 with `pnpm dev`, and Vue Vben at `frontend/admin/vue-vben` on 15666 with `pnpm dev:antd`. The install command is `pnpm install` in all three cases, but the working directory matters, since neither the repository root nor `frontend/admin` has a `package.json` and running the install there only produces an ENOENT error.

cd frontend/admin/react
pnpm install

The Vue Vben frontend is itself a pnpm workspace with a `pnpm-workspace.yaml`, an `apps/` directory and a `packages/` directory, so dependencies must be installed at its root, and `pnpm dev:antd` then picks out the `@vben/web-antd` app from inside the workspace. Installing on its own under `apps/admin` breaks the catalog version locking, which is a detail worth knowing before you conclude the workspace is broken. The frontend stacks are Vue 3 with Vite and Ant Design Vue for the Vben build, Vue 3 with Vite and Element Plus for the Element build, and React 19 with Vite, Zustand and Ant Design V6 without UMI for the React build, all three using Tailwind CSS.

Toolchain versions are pinned harder than most READMEs admit

The environment requirements table is unusually precise, and it is worth reading because the constraints are not all obvious. Go must be 1.26 or newer, with `backend/go.mod` as the authority. Node.js must satisfy `^20.19.0 || >=22.12.0`, and the README explains that this is the intersection of the three frontends' `engines` fields, decided by vue-element, since vue-vben only asks for `>=20.10.0` and the React build declares nothing. The consequences are that 21.x does not qualify and 20.18 and below do not either. pnpm must be at least 9.12.0, that lower bound coming from vue-vben's `engines.pnpm`, and vue-vben additionally pins `packageManager` to `[email protected]`, so enabling corepack switches to it automatically, and otherwise you install that major by hand or align it. Docker must be 20.0 or newer. The backend commands all go through the `gow` CLI, installed with `go install github.com/tx7do/go-wind-toolkit/gowind/cmd/gow@latest`. Middleware is Redis, brought up by compose from `bitnami/redis:latest` with no version pinned, and MinIO as the S3-compatible object store. The README notes the Redis image is unpinned but that the code only uses long-lived commands such as Set, Expire and Publish and nothing Redis 8 specific.

Editorial conclusion

Adopt GoWind Admin if you are building a Chinese-language enterprise admin console and want RBAC, audit retention and code generation in place on day one. Skip it if your team wants one codebase serving every client, because the three frontends are parallel implementations and only one is meant to survive. Before you deploy, replace the default noop authorisation engine, which allows every request, and read the compliance documentation rather than assuming the MLPS alignment is already certified.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. tx7do/go-wind-admin on GitHub