Snowy: a Vue 3 and Spring Boot admin platform with cryptography built into the base layer

A full stack admin skeleton with cryptography under the framework

Snowy, also called SnowyAdmin, is a rapid development platform for separated front end and back end admin systems. The repository description puts the stack plainly: Vue3 with AntDesignVue3 on the front, Vite as the build tool, and Spring Boot with MybatisPlus on the back, plus Hutool as a utility library and Sa-Token for authentication. The primary language in the repository is Java, and the licence is Apache-2.0.

What sets it apart from a generic admin scaffold is the guomi plugin. The project states that it integrates encryption and decryption for Chinese national cryptography standards and that the software layer is intended to satisfy the classified protection compliance evaluation used in China. The design goal is described as moving cryptography from a specialist task into the base of the framework, so encryption applies below the level where application code usually forgets it.

Two further adaptation goals are stated: support for domestic hardware models and middleware, and adaptation to domestic database products. For a team outside that environment these are noise. For a Chinese enterprise team, they are the reason to pick this scaffold over a generic Spring Boot plus Vue starter. The cost is that the platform is a complete application skeleton with opinions, not a set of libraries you drop into an existing service.

Plugin modules: how Snowy 3.0 divides the backend

The code structure section explains that Snowy 3.0 packages the code in a plugin style so the package hierarchy stays clear and coupling stays low. The top level splits into a front end directory, snowy-admin-web, a shared module, snowy-common, two plugin trees, snowy-plugin and snowy-plugin-api, and a main startup module, snowy-web-app.

The plugin tree holds the functional areas as separate packages: auth for login and authentication, biz for business functions, client for consumer facing features, dev for development tooling, gen for code generation, mobile for mobile administration and sys for system functions. The api tree repeats that list for the interface packages, which keeps a plugin's contract separate from its implementation. That pairing is the mechanism behind the low coupling claim: a plugin can be developed and reasoned about on its own, and the api package defines what other modules are allowed to call.

The front end mirrors the discipline. Inside snowy-admin-web/src the directories divide responsibilities by kind rather than by feature: api for API forwarding, assets, components for Vue components, config, layout, locales for multi language configuration, router, store for Pinia cache configuration, style, utils and views for all screen interfaces.

The consequence for a user is that the tree tells you where a feature lives before you read a line of code. The cost is a large directory count, and no documentation in the repository states which plugins are mandatory for a minimal deployment.

Running the Vue 3 admin front end

The quick start section asks full stack developers to use IDEA and lists the front end requirement as Node.js 18 or newer. The two commands for the front end are the standard Vite pair, and the README gives them without any additional flags or environment variables.

npm install

npm run dev

After npm install resolves the dependency tree, npm run dev starts the development server for the snowy-admin-web project. The repository does not document a production build command, an environment file or the port the dev server binds to, so the Vite defaults apply unless the project's own config directory changes them. There is also no mention of how the front end is told where the API lives, which is the first thing you will need to find in the config directory when wiring the front end to a running back end.

One detail worth noting is that the front end has no build step in the documented path beyond the dev server. The demo deployment and the documentation site are separate from the source tree, so the quickest way to see the intended interface is the hosted demo rather than a local build.

The back end needs JDK 17, Redis and MySQL before the code will start

The server side requirements are listed as a table: JDK 17 as the Java environment, Lombok as a code simplification plugin inside IDEA, Maven as the package manager, Redis as the cache store and MySQL at version 8.0 or 5.7 as the database. The start instruction is short: configure Maven in the development tool and configure the database in the code, and the application starts.

That instruction is where the practical work sits. There is no sample configuration file in the repository listing, no default schema, no documented Redis connection settings and no listed application port in the quick start section. The configuration step is left to the developer, which is normal for a framework whose audience is a Chinese full stack team accustomed to Spring Boot projects, but it means the first run is not a copy and paste job.

The absence of documented defaults also applies to the guomi plugin. The project describes the encryption capability as part of the framework base layer, yet the quick start section does not list a key file, a keystore location or an environment variable for the cryptographic material. Treat that as a question to answer with the maintainers before building on the encryption story.

The open source edition stops where the commercial products start

The README separates the free platform from the vendor's paid offerings, and the boundary is worth reading carefully because the feature list people associate with Snowy spans both sides.

The open source repository carries the framework, the plugin modules and the guomi encryption. The website is described as offering workflow, multi tenant, multi data source and a Vue3 form designer as additional plugins. Note the wording: these are described as available on the official site, not necessarily as parts of the repository. The repository's own top level entries are the Maven project, the front end directory, the common module and the two plugin trees, and no workflow, multi tenant or form designer module appears among them.

The commercial side is listed as four products: an AI driven zero code platform for building business systems by dragging and dropping, a domestic data middle platform covering collection, storage, governance, security and asset management, a unified identity authentication platform supporting OAuth, SAML, JWT and CAS, and an AI large model platform for building agent and knowledge base workflows. Each has its own demo site.

The practical reading for an evaluator: if your requirement is multi tenant, workflow, several data sources or a form designer, you are looking at the paid catalogue rather than the Apache-2.0 repository, and you should price that separately.

Four branches, and two of them are frozen

The branch policy is stated explicitly, which saves you from a common mistake with a fast moving Chinese framework, where people stay on an old line because it works.

master is the stable branch, and version specific changes are recorded in the update tags. dev is the team development branch, and the description warns that code there can be pushed at any time and is not guaranteed to run or be usable. snowy1.8 covers the 1.x line, which has stopped taking new features and is limited to bug fixes, and the guidance is to use the 2.x version instead. snowy2.5 covers the 2.x line with the same arrangement, and it is described as able to transition smoothly to 3.x.

So there is a supported migration story from 1.x through 2.x to 3.x, but only one actively evolving stable line. The dev branch warning matters if you are evaluating the codebase: reading default branch code at an arbitrary moment may not give you a runnable project.

Code and documentation are mirrored in several places, with download links on Gitee, a GitHub mirror and GitCode, plus a hosted documentation site and a demo deployment. The documentation link is where the plugin development conventions live, which the README points to for the modular development standard.

v3.5.1 in June 2025, while the branch itself moved in October 2026

The published release history is short and dated. v3.5.1 was released on 2025-06-15, v2.1.3 on 2022-11-23 and V1.2.0 on 2021-02-25. The repository is not archived and the last push was on 2026-10-14, so work continues on the code even though the newest tagged release is from mid 2025.

That gap is the main upgrade question. The tags tell you which releases exist for production use, and the last of them is more than a year old relative to the last push. If you need a fix that is present on master, you are carrying an untagged build, which is a different risk profile from pinning v3.5.1.

On licensing, the repository is Apache-2.0, which permits commercial use and modification under its notice and licence conditions. The guomi plugin inherits the same terms because it sits inside the same repository. No legal advice is offered here; read the LICENSE file yourself. What matters practically is that the encrypted workflow, multi tenant and form designer features that the website advertises are separate products with their own terms, not part of what Apache-2.0 covers.

Editorial conclusion

Snowy fits teams in China that want an admin console with guomi encryption already wired into the framework and a plugin layout they can extend. It does not fit teams outside that regulatory context, or those wanting a library rather than a full application skeleton. Before adopting it, install the front end and confirm the v3.5.1 layout matches the module names your team expects, and check the licence file yourself, since the open source edition is Apache-2.0 while the identity, zero code and data platform features live in separate commercial products.

Frequently asked questions

Official sources

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