Pig: one codebase, two deployment shapes

The cloud and boot profiles decide seven containers or one

Pig supports microservices and monolithic deployment from the same tree, and the switch is a Maven profile rather than a fork. For the microservices shape, a full build followed by the compose stack:

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

For the monolithic shape, the `boot` profile is what pulls the `pig-boot` module into the build:

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

That second command is the whole difference. Same source, same `pom.xml`, a different profile and a different compose file. The microservices profile uses `cloud` and activates the `dev` environment configuration by default; the `boot` profile leaves `pig-boot` out of every other build, so a `pig-boot` change will not show up in a plain compile.

Both shapes listen on `9999`. In the microservices layout that is the Spring Cloud Gateway, in the monolith it is the single service, and a client pointed at the port does not care which one answered.

The compose file starts more services than it publishes ports for

The microservices compose file declares pig-mysql, pig-redis, pig-register, pig-gateway, pig-auth, pig-upms, pig-monitor, pig-quartz and pig-codegen, all joined to the `spring_cloud_default` network with `restart: always`. Only some of them publish a host port.

pig-register:
  ports:
    - 8848:8848
    - 9848:9848
    - 18080:18080
pig-gateway:
  ports:
    - 9999:9999
pig-monitor:
  ports:
    - 5001:5001

So Nacos takes three ports, the gateway takes one, and the monitor takes one. pig-auth and pig-upms carry no `ports` entry at all, even though the module layout marks them `[3000]` and `[4000]` respectively. Those numbers are the services' internal ports, reachable only from inside the compose network. If you are writing a smoke test or a health check that runs outside the stack, you cannot point it at 3000 or 4000; you have to go through the gateway on 9999.

The health monitor is the exception that surprises people: `pig-monitor` maps 5001, so it is directly reachable from the host while the authorization and permission services are not.

Gateway routes now live in a config file, not a route table

Routing used to be the kind of thing you changed at runtime. It is not anymore. Gateway routes are maintained in `pig-gateway/src/main/resources/application.yml` together with the Nacos configuration, and the project states plainly that it no longer depends on a dynamic routing table.

That has a concrete effect on anyone extending the platform. Adding a route means editing the gateway's application.yml or its Nacos configuration, not a dynamic routing table. In exchange, the routing configuration survives a fresh container start, which matters when your deployment path is `docker compose build && docker compose up` from a clean checkout.

Configuration bootstrapping has the same two-source shape. The default database scripts sit in `db/`, business tables are initialised into a database named `pig`, and the Nacos configuration is initialised into `pig_config`. The compose file builds its MySQL image with `context: ./db`, so those scripts are baked into the database image rather than mounted at run time. Package naming has been unified to `com.pig4cloud.pig`, which is the thing to check first if a reflective lookup or a package-scanned bean fails to register after you move code between modules.

The open edition is smaller than the commercial one, on purpose

The clearest statement of scope in the project is which capabilities were removed from the open source version: multi-tenancy, data permissions, dynamic routing, workflow, payment, WeChat official account, reports, and the mobile end services.

What stayed is the core: authentication, gateway, user and permission management, monitoring, code generation, and scheduled tasks. The authentication centre is built on Spring Authorization Server and covers authorization code, password and refresh token flows.

Read that list as a filter on your requirements rather than as a backlog. If your deployment needs tenant isolation, or row-level data scoping on top of RBAC, or dynamic routing, the open tree will not get you there and there is no build flag in the `cloud` or `boot` profile that brings them back. Workflow, payment and reporting are the same story. Three related products are listed separately: a hosted PIGX demo, a self-developed BPMN workflow engine, and a large-model RAG knowledge base. Those are separate offerings rather than modules you can pull into this repository, and the workflow engine in particular addresses a capability the open edition explicitly dropped.

MySQL starts as root with the password root

The database service is built from the `db/` directory and configured with two environment values and one command:

pig-mysql:
  build:
    context: ./db
  environment:
    MYSQL_ROOT_HOST: "%"
    MYSQL_ROOT_PASSWORD: root
  command: --lower_case_table_names=1

`MYSQL_ROOT_HOST` set to `%` means the root account is accepted from any host, not only localhost, which is what lets the other containers in `spring_cloud_default` connect. It is also the first thing to change before this stack is reachable from anything you do not control.

`--lower_case_table_names=1` forces case-insensitive table names, which matters on a case-sensitive filesystem and for MySQL versions where the default changed. It is set on the command line rather than in a config file, so an existing data directory keeps whatever it was created with.

Redis is pulled from `registry.cn-hangzhou.aliyuncs.com/dockerhub_mirror/redis`, a mirror hosted in Hangzhou rather than from Docker Hub directly. Anyone building this outside mainland China should expect that image reference to be slow or unreachable, and the compose file offers no mirror setting for it.

A Spring Boot 4 train, pinned to specific patch versions

The dependency table is the fastest way to see what you are signing up for. Pig 4.1.2 sits on JDK 17+, Spring Boot 4.1.2, Spring Cloud 2025.1.4, Spring Cloud Alibaba 2025.1.0.0 and Spring Security OAuth2 Authorization Server 7.1.2. On the data side it uses MyBatis Plus 3.5.16, Nacos Client 3.2.4 and Druid 1.2.28.

The frontend numbers are in the same table: Vue 3.5.44, Element Plus 2.13.7 and Vite 8.1.6. That frontend is `pig-ui`, and it is a separate repository rather than a directory of this one. Running it needs Node.js 20.19.0 or newer, which is the only reason that requirement appears in a Java project's prerequisites at all.

Build requirements are JDK 17+, Maven 3.9+, and Docker with Docker Compose. Two more details from the module layout are worth noting before you restructure anything. `pig-register` is not merely a Nacos client; it is the Nacos server itself, on ports 8848, 9848 and 18080, which is why the compose file gives it three published ports and builds it from `./pig-register`. And `pig-common` is a family of modules rather than one: a BOM for global version management, a core utility package, a MyBatis Plus and cache extension, a dynamic datasource wrapper, logging, OSS upload helpers and security utilities.

Deployment, development and format steps live on the wiki, not here

This README is short, and the part that is there is a pointer. Development environment configuration, server startup, running the frontend, microservice deployment and monolithic deployment are all handled on `wiki.pig4cloud.com`. If you are deciding whether Pig fits, you are deciding on the strength of a wiki you have not read yet, because the repository itself documents the build commands and the module map and stops there.

The contribution rules are more concrete. Pull requests are welcome and should target the current development branch. Issues are asked to describe the symptom, the development environment and the reproduction steps, which is a reasonable bar for a platform with this many moving services. Formatting follows Spring Java Format, and the command to run before committing is:

mvn spring-javaformat:apply

The licence is Apache 2.0, which permits commercial use on the condition that the author and copyright information is retained. Read that as an obligation on redistribution, not on use, and keep the `LICENSE` file intact if you ship a fork.

One inconsistency to note: the default branch is `master`, while the contribution guidance refers to the current development branch without naming it. Check which branch receives PRs before you branch off.

Release tags moved twice this year, and the last push is recent

The version history is short and recent. v4.1.2 was published on 2026-10-23, v4.1.1 on 2026-10-06, and v4.1.0 on 2026-07-08. Three tags inside four months means the 4.1 line is young enough that upgrade notes matter.

The last push to the repository was on 2026-11-02, so the tree is being worked on. What that does not tell you is whether a given module is in flux. A framework moving between Spring Boot generations and a permission service having its routes moved out of a runtime table at the same time is a combination that tends to produce behaviour changes that no version number announces.

Practical consequence for an adopter: pin the version you build, read `CHANGELOG.md` if it exists at that tag, and treat the `dev` environment configuration that the `cloud` profile activates by default as something to override rather than inherit. The monolith path is the lower-risk way to evaluate the platform, because it runs a single service on 9999 instead of the gateway and separate services, and it uses the same code.

Editorial conclusion

Take the cloud profile if you already run Nacos and want the gateway, authorization server and permission service to fail independently, and take the boot profile if you want one process and one port on a small deployment. Before either, check what you actually need from the removed modules: multi-tenancy, data permissions, dynamic routing and the workflow, payment, reporting and mobile services are not in the open edition, and there is no community build of them. Then verify the published ports, because the compose file starts pig-auth and pig-upms without exposing them, and confirm the MySQL credentials before the stack is reachable from anywhere but your machine.

Frequently asked questions

Official sources

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