pig-mesh/pig: an RBAC platform on Spring Boot 4 and Spring Authorization Server

The gap Pig fills: OAuth2 plus RBAC wiring that nobody wants to write twice

Most teams starting an internal platform spend the first weeks rebuilding the same four pieces: a login and token service, a role and permission model, an API gateway that validates those tokens, and a user management screen. Pig packages those pieces. The README describes it as an enterprise rapid development platform built on Spring Cloud, Spring Boot and OAuth2, supporting both a microservice layout and a monolith. The authentication centre is built on Spring Authorization Server, and the README lists authorization code, password and refresh token among the supported flows.

The audience is narrow but real. You are building a back office, an operations console or an internal system with several roles and a few dozen endpoints. You have a Java team. You do not want to hand-roll token issuance, refresh rotation, permission checks and a Vue admin shell before writing any business code. Pig is for that team.

It is not a general web framework, and the README is explicit that the open version is a subset. Multi-tenant support, data permissions, dynamic routing, workflow, payment, official account, reporting and mobile services exist only in the commercial product. If your requirements list includes per-tenant data isolation, this repository is a starting point you will extend yourself, not a finished answer.

How the pieces fit: gateway, auth, UPMS and Nacos

The module tree in the README shows the data flow. pig-register is a Nacos server on ports 8848, 9848 and 18080. pig-gateway is a Spring Cloud Gateway on port 9999 and is the only entry point for backend calls. pig-auth is the authorization service on port 3000. pig-upms-biz is the user permission business service on port 4000, with pig-upms-api holding the shared API types. pig-monitor, pig-codegen and pig-quartz sit under pig-visual on ports 5001, 5002 and 5007.

A request therefore enters at 9999, is routed by the gateway, and reaches a service that validates the token issued by pig-auth. Service discovery and configuration both come from Nacos, so the gateway can resolve pig-upms-biz without hard-coded hosts. The README states that gateway routes live in pig-gateway/src/main/resources/application.yml and in Nacos configuration, and that the previous dynamic route table is gone. That is a deliberate simplification: routes are static configuration you edit, not database rows a UI rewrites at runtime.

Shared behaviour is factored into pig-common: security utilities, MyBatis Plus and cache extensions, dynamic datasource wrapping, Feign extensions, Excel import and export, XSS handling, Sentinel and exception wrapping, Swagger, OSS upload and logging. That decomposition is the main architectural claim worth evaluating. If you only need part of it, the modules are separable in principle, but the README does not document which of them can be dropped without breaking the others.

Installing Pig and starting the microservice stack

The README lists the base environment as JDK 17 or newer, Maven 3.9 or newer, Docker with Docker Compose, and Node.js 20.19.0 or newer if you intend to run the pig-ui front end. The front end lives in a separate repository, pig-mesh/pig-ui, which is the first line of the module listing.

For microservice mode, the README gives two commands from the project root. The first compiles everything with the cloud profile; the second builds the images and starts the local stack.

mvn clean install -T 4 -Pcloud
docker compose build && docker compose up

After the services are up, the README states that backend interfaces are reached through the gateway on port 9999 and the Nacos console is on port 8848. Expect the first start to be slow: the compose file builds images for MySQL, Redis, Nacos, the gateway, auth, UPMS, monitor, Quartz and codegen from source rather than pulling finished application images.

The compose file itself carries the usage note that on the host you do not need to configure hosts entries for service discovery, that no source changes are required, and that you should simply wait for services to start. MySQL is built from the db directory with root password root and lower_case_table_names set to 1. The README adds that the default database scripts initialise business tables into a schema named pig and Nacos configuration into pig_config.

If you prefer a single process, the boot profile activates the pig-boot module, which does not participate in the build otherwise:

mvn clean install -T 4 -Pboot
docker compose -f docker-compose-boot.yml build && docker compose -f docker-compose-boot.yml up

The README states that the monolith listens on 9999. Note that the boot profile also changes what gets compiled, so switching between the two modes means rebuilding rather than just changing a runtime flag.

Where Pig gets in the way

The dependency floor is the first constraint. The README's dependency table pins Spring Boot 4.0.6, Spring Cloud 2025.1.2, Spring Cloud Alibaba 2025.1.0.0, Spring Security OAuth2 Authorization Server 7.0.5 and JDK 17 or newer. That is a very new line. Any library in your stack that has not caught up to Spring Boot 4 will block you, and this is not a project where you can quietly downgrade Spring Boot without losing the authorization server integration.

Operational weight is the second. Even the microservice path needs MySQL, Redis and Nacos before a single business endpoint answers. The monolith path removes the service split but not the dependencies: docker-compose-boot.yml still builds a MySQL image from db and still runs Redis. If your team has no experience running Nacos, the configuration surface (application.yml plus Nacos-hosted config) is a new failure domain where a wrong data ID looks like a broken service.

The third constraint is scope, and it is a product decision rather than a bug. The README says the open version removed multi-tenant, data permissions, dynamic routing, workflow, payment, official account, reporting and mobile services. Teams that evaluate Pig from the commercial demo pages and then clone this repository will find features missing. There is no rollback or migration documentation in the README for moving between the two, and the README does not document an upgrade path between major versions either, so treat v4.1.0 as a baseline you pin rather than a stream you follow blindly.

Pig against SpringBlade and hand-rolled Spring Security

The closest thing to a peer in the search terms around this project is SpringBlade, another Chinese Spring Cloud admin platform with a similar module layout: gateway, auth, UPMS-style system service, code generator and a Vue front end. The difference that matters is the authorization stack. Pig's README states that its authentication centre is built on Spring Authorization Server, the OAuth2 authorization server that grew out of the Spring Security team's own work, and it lists authorization code, password and refresh token flows. SpringBlade's documentation centres on its own token handling rather than a standards-based authorization server. If you need third-party clients to obtain tokens through a standard OAuth2 flow, that distinction decides the choice. If you only ever authenticate your own first-party Vue app, it does not.

The other alternative is assembling it yourself from Spring Boot, Spring Security and a Vue template. That gives you exactly the modules you need and no Nacos. It also means writing token issuance, refresh, permission evaluation, the user and role tables, the admin screens and the code generator. Pig's value is that all of that already exists and is wired together; its cost is that you inherit its opinions, its dependency versions and its operational footprint. For a two-service internal tool, hand-rolling is often cheaper. For a platform that will grow to a dozen services and several roles, the pre-built UPMS and gateway usually pay for themselves in the first sprint.

Maintenance, licence and the cost of upgrading

The repository is not archived, and the last push was on 2026-09-07, which is recent enough that the project is being worked on. The release history shows v4.1.0 on 2026-07-08, v4.0.0 on 2026-06-05 and v3.9.2 on 2025-10-31. The gap between the 3.x and 4.x lines is roughly seven months, and 4.x moved to Spring Boot 4 and Spring Cloud 2025, which is a large jump for anyone on 3.9.2. The README does not describe a supported upgrade procedure, so a 3.x to 4.x move is a migration project, not a dependency bump.

Contributions go through pull requests against the current development branch, and the README asks that issues include the symptom, the development environment and reproduction steps. Code style follows Spring Java Format, applied with mvn spring-javaformat:apply from the project root. If you plan to fork and maintain a private branch, that command is the cheapest way to keep diffs readable when you later pull upstream changes.

The licence is Apache-2.0. The README states that commercial use is allowed but that class author and copyright information must be retained. This is a permissive licence with a notice obligation, not a copyleft one, so a closed-source internal deployment is compatible with it as long as the notices survive. That is a description of what the README says, not legal advice; the wording of the licence file in the repository is what governs, and the README does not discuss trademark use of the Pig name or the branding in the front end.

Editorial conclusion

Adopt Pig if you want a working OAuth2 authorization server, gateway and UPMS skeleton you can extend, and you accept that multi-tenant, data-scope, workflow, payment and reporting modules are not in this repository. Skip it if you need a single Spring Boot admin app with no Nacos, MySQL and Redis to operate, or if you cannot move to JDK 17 and the Spring Boot 4 line. Before committing, check three things in your own checkout: the db/ scripts load into a database named pig and Nacos config into pig_config, the gateway routes in pig-gateway/src/main/resources/application.yml match your topology, and docker compose build succeeds on the machine you intend to deploy from. The Apache-2.0 terms allow commercial use, but the README asks you to keep class author and copyright notices, so decide how that obligation is handled before the first commit lands in a private fork.

Frequently asked questions

Official sources

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