gin-vue-blog: a Go and Vue blog that tests its own permissions

Two front ends and one Go backend in one repository

gin-vue-blog is a front end and back end separated blog project written in Go and Vue 3, and the split is visible in the top level of the tree:

The server side is laid out in the conventional Go way, with cmd for the program entry point and data initialisation scripts, internal for handlers, models, middleware, global configuration and error codes, and utils, plus a docs directory holding the Swagger documentation, an assets directory, a config.yml and a Dockerfile. The two front end projects have matching structures under src with api, components, mock, router, store, utils and views, and the admin project adds layout and composables.

The stack badges give the version floors: Go 1.26, Gin 1.12, GORM 1.31, Vue 3.5, Vite 8 and UnoCSS 66. The backend runs on Go with Gin, GORM, SQLite by default with MySQL as an alternative, Redis, Viper for configuration and log/slog for logging. The front end uses Vue 3, Vite, Vue Router, Pinia, UnoCSS, VueUse and Axios, with Naive UI added for the admin panel, and pnpm for package management. The project is MIT licensed and the last push was on 2026-10-19.

JWT authentication with role-based menus built by the server

The admin panel uses JWT authentication with role based access control, and the notable detail is that both the menu and the interface permissions are configurable in the admin panel itself rather than hardcoded. The front end menu is delivered by the backend as dynamic routes, so a role change in the database changes what a user sees on the next load without a front end release.

The permission model is built around per-user and per-role enable and disable flags, and disabling is enforced in two directions. A disabled user is refused at login, and tokens already issued to that user stop working immediately. That second property is the one worth checking in your own deployment, because session invalidation is where this kind of design often has a gap.

The dashboard on the admin home page summarises pending comments and messages, the latest articles, category distribution, visitor geography, recent logins and a 14 day visit trend. The rest of the panel covers Markdown article editing with import for .md and .markdown files and .md export, operation logs, login logs including failures, online user monitoring with forced sign out, and file upload to local storage or to Qiniu cloud. Front end error reporting is built in rather than delegated, with uncaught exceptions from both front ends reported to an admin list and aggregated by fingerprint so the same error only increments a count.

The CI deploy job checks permissions, not just unit tests

Most projects of this shape run lint, tests and a build. The workflow file in this repository runs four job groups on push and pull request, and the fourth one is unusual enough to look at closely.

The Server job runs gofmt, go vet and go test, and also verifies that the checked in docs directory matches the Swagger annotations. The Frontend job runs lint, test and build for each of the two front ends. The Docker job builds two images from the front end artefacts, starts them and performs a health check, and pushes to GHCR when the main branch gets a new commit. The Deploy job brings up the full Compose stack and validates invariants about the permission seed data: admin can change configuration, guest cannot, unauthenticated requests are blocked, and running the seed again does not create duplicate resources.

That last check is a genuinely useful thing to automate, because seed scripts are exactly the code that silently breaks when the schema moves. The test suite is claimed to be regression oriented, with every test verified to turn red if the fix is reverted, and the specific defects covered are documented in the code audit file under its component test section.

The count is stated in the README, with 8 backend packages, 33 front end test files and 203 tests, and 27 admin test files and 165 tests, which adds up to the 368 front end tests claimed in the feature list.

Running the whole stack with a single bootstrap script

For a quick look, the project offers Docker Compose deployment. You need Docker and Docker Compose, and the README notes that on Windows you should use GitBash:

The Compose route is the documented one for evaluation, with the clone, a directory change into the deploy folder and the bootstrap script:

git clone https://github.com/szluyu99/gin-vue-blog
cd gin-vue-blog/deploy
./bootstrap.sh

After that the front end is on localhost and the admin panel on localhost/admin, with the default account admin / 123456. The README warns to set core.autocrlf to false on Windows before cloning, because the project uses line feed endings and carriage return line feed breaks the Docker build, and it also notes that if email verification registration is enabled you have to change the localhost value in GetEmailVerifyURL to your own domain.

Seed data is deliberately thin. Initialisation contains only system basics such as menus, interfaces, roles and configuration, with no articles. To get clickable content, the categories, tags, 15 articles, comments and replies, messages and friend links, the quick start describes a dev.sh fresh --demo command and the alternative go run main.go -t demo invocation.

A mock mode that runs the front end without a backend

Both front ends can run with no server at all. The feature list calls this out as unusual, and the README explains that the mock data lives in the src/mock directory, that changes exist only in the current page, and that a refresh puts everything back. There is an online deployment of it on GitHub Pages, deployed automatically by GitHub Actions, covering the blog front end, the admin panel where any account and password will log you in, and a Swagger interface documentation page generated from annotations that cannot be called online because it is statically hosted.

This is a genuinely useful property for a template project, since it means a front end developer can work on layout and components without provisioning Go, Redis or a database, and it means a reviewer can click through the interface from a browser without running anything.

The mock mode also sets expectations correctly. The demo data is fake and local, so the online preview tells you about the interface and nothing about the backend contract. The GitHub Pages build is the front end only, and the same limitation applies to the Swagger page: it is a static rendering of the annotation output, not a live API.

There is a developer-facing mode of the same idea. The dev.sh script at the repository root offers a fresh --demo action, and the quick_start.md document covers both the mock mode without the backend and the full startup, along with addresses, default accounts and common questions.

What the project has decided not to build

The most useful part of the README for an adopter is the list of things that will never appear unless someone changes their mind, and it is specific: ElasticSearch search, server side rendering and static site generation, third party login, internationalisation, RSS and sitemap, backend log rotation, and swapping the admin panel's @iconify/vue usage for UnoCSS icon classes. The roadmap file is said to record the reasoning for each, and also to record what was done and what was deliberately left out, with a current state section meant to be read first by anyone taking the project over.

Two other choices are worth knowing. SQLite is the default database and MySQL is an alternative, which makes a first run cheap but means you should pick MySQL before real data arrives. Tencent cloud captcha is available for registration but off by default, and email verification registration is off by default as well, controlled by the Captcha.SendEmail setting in config.yml.

The audit trail is unusual for a project at this stage. code_audit.md records each issue found in review, its cause and its fix, item by item, and the roadmap file records the decisions. For anyone planning to build a real site on this, those two documents are a better starting point than the code, because they tell you which parts are considered settled and which are still being worked on. There are no GitHub releases for the project, so the deployment story is the Compose path rather than a versioned artefact.

Editorial conclusion

Adopt gin-vue-blog if you want a complete blog with an admin panel you can extend, and you want the permission model verified by a test rather than by hand, since the Deploy job in CI checks that admin can change configuration, guest cannot, unauthenticated requests are blocked and reseeding does not duplicate resources. Skip it if you need search, RSS, internationalisation or server side rendering, because the project lists all of those as deliberate non-goals with reasons in roadmap.md. Before you build on it, read the roadmap's current state section and the code_audit.md file, since both document decisions the code alone will not explain.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. szluyu99/gin-vue-blog on GitHub