# go-admin-ui: the Vue front end of a Gin and Casbin admin system

> go-admin-ui is the browser half of the go-admin permission management system, a Vue and TypeScript application built with Vite and pnpm that talks to a Gin backend over a REST API with Casbin based RBAC. It ships code generation, drag and drop form building, an API contract check and an i18n data check in its CI script, and the container image is a static bundle behind nginx.

**go-admin-team/go-admin-ui** — 基于Gin + Vue + Element UI & Arco Design & Ant Design 的前后端分离权限管理系统的前端模块

- Repository: https://github.com/go-admin-team/go-admin-ui
- Website: https://www.go-admin.pro
- Stars: 1,337 · Forks: 785
- Language: TypeScript
- License: MIT
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/go-admin-team-go-admin-ui

## The browser half of a two repository system

The first thing to understand about this repository is that it is one half of a pair. The repository is go-admin-ui, and the description names it as the front end module of a front end and back end separated permission management system built on Gin, Vue, Element UI, Arco Design and Ant Design. The backend lives in go-admin-team/go-admin, and the documentation is at doc.go-admin.dev.

The split is not merely a repository convention, it is a deployment one. The README's local development section has an important note that the two projects must be placed in the same folder, and the setup instructions create a directory, clone the backend and clone the front end into it side by side.

The front end is a Vue application in TypeScript, built with Vite, and the topic tags list vue alongside element-ui, arco, arco-design, ant-design and antd-design-pro, which tells you the component library is a choice rather than a fixed decision. The package metadata describes it as a magical vue admin and an out-of-box UI solution for enterprise applications, with the newest development stack of vue.

The project is MIT licensed, the default branch is master, the last push was on 2026-10-12, and the releases are v3.2.1 from 2026-09-16, v3.3.0 from 2026-09-25 and v3.4.0 from 2026-09-27, with the version field in package.json at 3.4.0 to match. The README links the documentation site, the project homepage is go-admin.pro, and there is a Chinese README, README.Zh-cn.md, alongside the English one.

## What the admin system actually manages

The feature and module lists in the README describe a complete permission system, and reading them tells you what a team gets and what it still has to build.

The internal modules are the substance. User management configures the system operators. Department management configures the organisation, a company, department or group, and displays the tree structure to support data permissions, which means the organisational tree is what scopes who can see which rows. Position management configures the positions of system users. Menu management configures the system menu, operation authority, button authority identification and interface authority, so permissions are attached to the interface layer rather than to pages only.

Role management assigns menu permissions to roles, and divides role settings into data scope permissions by organisation, which is the second half of the permission model, the first being what a role can do and the second what a role can see.

Then the supporting modules: dictionary management for relatively fixed data used frequently, parameter management for common parameters configured dynamically, an operation log for normal and abnormal activity, and a login log that includes login exceptions.

The tooling entries are the last group. Interface documentation is generated automatically from the business code, code generation produces the add, delete, modify and check operations from a data table structure so the basic business can be implemented with zero code, form construction is a drag and drop page layout editor, service monitoring shows basic information about some servers, and content management is a demo function with classification and content management.

Two entries deserve a flag rather than praise. The multi-language interface switches between Chinese and English without a reload and with no database or backend change, and the feature list carries an explicit TODO for unit tests.

## The build is pnpm and Vite with three environment files

The manifest describes the tooling in a way that leaves no ambiguity about what the project expects.

The scripts start with a sync step that runs before every dev and build, node scripts/sync-apps.mjs, and then Vite itself. The three build targets are dev, build:prod and build:stage, and the last one passes the staging mode to Vite, which pairs with the three environment files in the repository root, .env.development, .env.production and .env.staging.

The stack below that is modern. The type check is vue-tsc --noEmit together with tsc for the node side of the configuration, which means the project keeps a separate tsconfig.node.json for the build tooling, alongside the main tsconfig.json and a jsconfig.json. The linter is eslint over src and tests, configured with eslint.config.mjs, and the repository uses husky for the git hooks, with a prepare script that runs husky.

The code generation story is worth noticing because it is a different kind of generator from the one the README describes on the backend. Here, the new script runs plop, and the repository carries plopfile.js and a plop-templates/ directory, so new pages and components are scaffolded from templates on the local machine rather than generated on the server from a database table.

The runtime dependencies visible in the manifest include axios for HTTP, echarts for the charts, codemirror for a code editor in the form builder, core-js for polyfills, and the Element Plus icon package, which is a hint that the Element variant is the one the development is following even though other design systems are supported.

## The CI script chain checks the API contract and the translations

The most distinctive part of the manifest for an evaluating team is the test:ci script, because it describes what the project considers a broken change.

```json
"test:ci": "pnpm lint && pnpm type-check && pnpm test:unit && pnpm check:api && pnpm check:i18n"
```

Five stages in order. Linting, then type checking, then the unit tests with vitest run. Then check:api, which runs node scripts/check-api-contract.mjs, and then check:i18n, which runs node scripts/check-i18n-data.mjs.

Those last two are the interesting ones, because they check things a normal unit test does not. A contract check compares the API calls the front end makes against the API the backend provides, which catches the most common failure in a split system, where the front end is upgraded and the back end is not, or the other way round. An i18n data check verifies the translation resources, which is what stops a new string from shipping untranslated in one of the two languages.

There is also a performance script, check:size, which runs node scripts/check-first-paint.mjs, so first paint size is measured rather than assumed.

The end to end tests are Playwright based, with three named projects: e2e runs the mocked project, e2e:live runs against a live server, and e2e:shots runs a screenshots project. The configuration lives in playwright.config.ts. The unit tests run under vitest, with a watch mode alongside.

The one thing that stands out against the README's own feature list is the TODO entry for unit tests, which sits next to a manifest that has vitest, Playwright and a five stage CI chain. The tooling arrived before the feature was closed.

## Cloning both projects into one directory

The local development instructions are concrete enough to follow, and they begin with a requirement that is easy to miss.

You need to install go, gin, node and git locally. The stated environmental requirements are go 1.26.5, nodejs v22 and above with v24 LTS recommended, and package manager pnpm v9 and above, with the note that this project uses pnpm and the lockfile is pnpm-lock.yaml.

Then you create a directory and move into it:

```bash
mkdir goadmin
cd goadmin
```

And then the important note applies, the two projects must be placed in the same folder:

```bash
# Get backend code
git clone https://github.com/go-admin-team/go-admin.git

# Get the front-end code
git clone https://github.com/go-admin-team/go-admin-ui.git
```

The reason is visible in the rest of the instructions. The server start sequence goes into the backend directory, compiles it with go build, and then edits the configuration file, with the path given as go-admin/config/settings.yml and the command as vi ./config/setting.yml, and instructs you to modify the database information under settings.database and confirm the log path.

The same sequence then initialises the database and starts the service:

```bash
# The first configuration needs to initialize the database resource information
# Use under macOS or linux
$ ./go-admin migrate -c=config/settings.dev.yml

# ⚠️Note: Use under windows
$ go-admin
```

So the front end and the back end are siblings in one directory, and the back end is where the database connection and the migration live. The Windows case gets a separate note because go-sqlite3 needs cgo, and the README shows the two error messages you get on Windows without it, one for a missing compiler path and one for gcc not being in the path.

## The container image is a static bundle behind nginx

The Dockerfile in the repository is short, and it shows exactly what this front end is in production terms.

```dockerfile
FROM node:24-alpine as build-stage
WORKDIR /app
COPY package.json pnpm-lock.yaml .npmrc ./
RUN npm install -g pnpm@9.15.1
RUN pnpm install --frozen-lockfile
COPY . .
RUN pnpm build:prod

# production stage
FROM nginx:stable-alpine
COPY --from=build-stage /app/dist /usr/share/nginx/html

EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]
```

There is no application server in the final image. The build stage uses node 24 on alpine, installs a pinned pnpm 9.15.1, and installs dependencies with the frozen lockfile so the build cannot silently pick up a different dependency set than the one committed. The production stage is nginx serving the contents of the dist directory, and the container exposes port 80.

That tells you the deployment contract. This front end is a static bundle, so it can be served by any web server, and the only dynamic piece is the Gin API it calls, which has to be reachable and has to permit cross origin requests, since the backend's feature list mentions cross-domain middleware.

The Dockerfile is also the clearest statement of the toolchain. Node 24 and pnpm 9.15.1 are what the image expects, which is close to the local requirements of node v22 and above with v24 LTS recommended and pnpm v9 and above.

The repository also holds a SASS_UPGRADE_NOTE.md, an UPGRADE_TO_VUE3.md, a VUE3_BEST_PRACTICES.md and a VUE3_UPGRADE_COMPLETE.md, so the Vue 3 migration is documented in the tree rather than assumed, and there is a test-vue3.js at the root.

## Multiple apps and the design system question

The last structural detail in the repository is the one that will affect your integration work most, and it is the apps.config.mjs file plus the scripts/sync-apps.mjs script that runs before every dev and build.

The description of the project lists three design systems, Element UI, Arco Design and Ant Design, and the topic tags repeat all three. The repository root holds apps.config.mjs, a file that names the applications the front end serves, and the sync script copies or generates the app set before Vite starts.

The difference in approach between the variants is not only visual. The manifest dependencies point at the Element Plus icon package and the keywords list element-ui first, so the Element variant is the one the dependency set is tuned for, and the other design systems are supported through the app configuration rather than through a separate package. 

The practical consequence is that a decision about which design system to use is a configuration decision that happens early, and the cost of changing it later is not zero, because the component APIs differ even when the pages look similar.

There is also a hint about the direction of travel in the file names. A SASS upgrade note, three documents about the Vue 3 upgrade, and a script called test-vue3.js all point to a codebase that has been through a major framework version change recently, and the presence of a VUE3_UPGRADE_COMPLETE.md suggests the migration was finished. The i18n support, with Chinese and English switchable without a reload and without a backend change, is the other feature that shapes how you would build on this, since it means the interface layer has to be built with translation keys from the start rather than with hardcoded strings.

## Conclusion

Adopt go-admin-ui if you want a complete admin backend with its user, department, role, menu, dictionary and log modules already designed, and if your team is comfortable in the Vue ecosystem and willing to run both halves of the system. Do not adopt it as a standalone admin template, since the front end assumes a matching Gin API and the two repositories have to sit side by side. Verify first that your Node and pnpm versions match the stated requirements, that the API contract check passes against the backend version you pair it with, and that the i18n data check is satisfied before you ship a Chinese and English interface.

## FAQ

### What do I need installed to work on go-admin-ui?

The README lists go, gin, node and git locally, with environmental requirements of go 1.26.5, nodejs v22 and above with v24 LTS recommended, and pnpm v9 and above, since the project uses pnpm with a pnpm-lock.yaml lockfile.

### Why do the go-admin and go-admin-ui repositories have to be cloned together?

The local development section states that the two projects must be placed in the same folder, and shows the backend and the front end cloned into one directory. The back end holds the configuration file with the database connection and the migration command that initialises the database.

### What does the go-admin-ui CI script check?

The test:ci script runs pnpm lint, pnpm type-check, pnpm test:unit, pnpm check:api and pnpm check:i18n in that order. The API check runs a script that compares the contract with the backend, and the i18n check verifies the translation data.

### How is the go-admin-ui production image built?

The Dockerfile builds with node 24 on alpine and pnpm 9.15.1 using a frozen lockfile, runs pnpm build:prod, and copies the resulting dist directory into an nginx:stable-alpine image that exposes port 80. The final image contains no application server, only static files and nginx.

## Sources

- [go-admin-team/go-admin-ui on GitHub](https://github.com/go-admin-team/go-admin-ui)
- [License: MIT](https://github.com/go-admin-team/go-admin-ui/blob/master/LICENSE)
- [Project website](https://www.go-admin.pro)
- [README](https://github.com/go-admin-team/go-admin-ui/blob/master/README.md)
- [Releases](https://github.com/go-admin-team/go-admin-ui/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/go-admin-team-go-admin-ui