jshERP (管伊佳ERP): a SpringBoot inventory and finance ERP you host yourself

What jshERP covers and who it is built for

jshERP is an ERP aimed at small and medium businesses, and the README states the goal plainly: lower the cost of getting a company onto an ERP. The module list is narrow on purpose. Retail management, purchasing, sales, warehousing, finance, report queries and system administration. The README also claims 100% open source under Apache-2.0 and says enterprises may use it commercially.

The audience is three groups. A trading company, shop or wholesaler that wants stock levels, purchase orders, sales orders and a finance ledger in one place. A Java developer who needs a working SpringBoot and MyBatis codebase to extend rather than start from an empty project. And a student learning how a Chinese business application is structured, since the README explicitly invites beginners to download the source for study.

The README is candid that the scope is not full ERP. It says the system currently has 进销存 (purchase, sales, inventory), finance and production, and that the remaining ERP functions are planned. Treat that sentence as the boundary of what you are buying into. If your requirement is MRP, shop-floor scheduling or multi-plant planning, this is the wrong shape of product today.

Two applications, one database: the jshERP architecture

The repository has two top-level application directories. jshERP-boot holds the backend, jshERP-web holds the front end. They are separate builds with separate toolchains, which is the first thing to understand about deployment.

The backend is SpringBoot 2.0.0 with MyBatis 1.3.2 for persistence and SLF4J 1.7 for logging, built with Maven 3.3.9. The front end is Vue 2.7.16 on Ant-Design-Vue 1.5.2, and the README lists Jeecg-Boot 2.2.0 as the template framework. That Jeecg-Boot lineage explains a lot of the behaviour you will meet: the menu and permission model, the tenant concept, and the code-generation style of the admin screens.

Data flows the conventional way. The Vue application talks to the SpringBoot API, the API reads and writes MySQL through MyBatis, and Redis sits alongside as the cache and session store. Nginx serves the built front end and proxies to the Java process. There is no message queue and no separate reporting database in the stated stack, so report queries hit the same MySQL instance as transactions. For a small business that is fine. For a warehouse with heavy concurrent picking, it is a contention point you should plan around.

Permissions are described as granular, down to each button and menu, with roles controlling access. That matters more than it sounds: in an ERP, who can approve a purchase order and who can see cost prices are different questions, and the README claims both are addressable.

Installing jshERP: the versions the README pins

The README does not give a single install script. It gives a recommended environment, a deployment tutorial link and prebuilt download links, and it warns that using these versions avoids problems caused by version drift. The stated developer environment is IntelliJ IDEA 2025.1.4.1, MySQL 8.0.24, JDK 1.8, Node 20.17.0, Maven 3.3.9, Redis 6.2.1 and Nginx 1.12.2. The server environment repeats MySQL 8.0.24, JRE 1.8, Redis 6.2.1 and Nginx 1.12.2 on Windows or Linux.

Start by checking the two runtimes you cannot substitute casually. JDK 1.8 is what the project targets, and SpringBoot 2.0.0 predates the Java releases most teams now default to. The README does not print a verification command, so use your platform's own version checks for the JVM, Node and Maven, and confirm you are on 1.8, 20.17.0 and 3.3.9 respectively.

Next, provision the two services the backend expects before it starts. MySQL should report 8.0.24 and Redis 6.2.1. Create the database and import the schema that ships in the repository, then build the backend and the front end as two separate Maven and npm runs from jshERP-boot and jshERP-web respectively. The README points anyone who would rather not package it themselves at a prebuilt archive on Weiyun, and anyone who would rather not deploy it at all at the deployment tutorial at gyjerp.com/doc/archive/deploy.html. Both are the project's own guidance, not a shortcut I can vouch for.

Once it is running, the README gives the default credentials: tenant account jsh, super administrator account admin, and 123456 as the password for both. Log in and change them before the instance is reachable from anywhere but localhost. The README also notes that 73 interface languages can be switched from the 界面设置 page in the top right after login, which is a real feature if your staff do not read Chinese.

Where jshERP will disappoint you

The default credentials are the first problem, and the README presents them without a warning. jsh, admin, 123456. If you deploy this on a public address and leave them, you have published an ERP with a known administrator password. That is not a flaw in the code, it is a deployment hazard the documentation does not flag.

The second issue is the release cadence against the commit cadence. The most recent release in the list is v3.5, dated 2024-11-11. The last push to the default branch was on 2026-09-11. So the repository has been receiving commits for roughly two years beyond its last tagged release, and anyone tracking versions rather than commits has no packaged artifact for that work. If you need to pin a version and audit changes between upgrades, the tag history is thin: v3.5, v3.3 in 2023 and v3.2 in 2022.

The third issue is the stack age. SpringBoot 2.0.0, MyBatis 1.3.2, Vue 2.7.16 and Jeecg-Boot 2.2.0 are all several generations behind what a new Java project would pick today. Vue 2 in particular is a maintenance burden for the front end. This is a deliberate trade-off in a product that values stability for small businesses, but it means your developers will be writing against older APIs and older security patches than they are used to.

Finally, the README mixes the open source project with commercial offerings: a network edition at 198 yuan per year, plugins sold through a Taobao shop, and custom development by email. That is a legitimate business model, but it means the README is partly a sales page. Read the licence file, not the marketing paragraph, for what you may actually do.

jshERP against the self-hosted ERP field

The obvious comparison is with the open source ERPs written in other stacks, which is what the related searches around this project suggest people are weighing. A Laravel-based ERP and a C# ERP approach the same problem with a different developer audience: PHP or .NET shops can hire for and extend those directly, while jshERP requires Java and Vue skills.

The more useful difference is architectural. Many self-hosted ERPs are modular platforms where you assemble accounting, inventory and CRM from separate packages. jshERP is the opposite: one integrated application where purchasing, sales, warehousing and finance share a single schema and a single permission model. That means less integration work to get a coherent picture of stock and money, and less flexibility if you only wanted the inventory half.

Against the paid network edition that the README promotes, the difference is operational rather than functional. The self-hosted version is yours to run and modify under Apache-2.0; the network edition is a hosted tenant. Choosing between them is a question of whether you want to own the MySQL instance and the upgrade cycle, or pay someone else to.

Licence, upgrade cost and what the README leaves open

The licence is Apache-2.0, and the README states that enterprises may use the system commercially and that it is 100% open source. Apache-2.0 is a permissive licence with an explicit patent grant, which is generally the least complicated choice for a company embedding software in its own operations. It also means you can modify jshERP and keep the modifications private. This is a description of the licence text, not legal advice; if you redistribute the software or a derivative, read the NOTICE and attribution requirements yourself.

The upgrade cost is where I would push back on the documentation. There is a v3.5 release, a deployment tutorial and a user manual, but the README says nothing about database migrations between versions, rollback, or what happens to your data when you move from v3.3 to v3.5. For an ERP that holds your stock ledger and your finance records, the absence of a documented upgrade path is a real risk. Budget for testing an upgrade on a copy of the database first, and read the release notes for each tag before touching production.

The same gap applies to backups. The README does not document a backup procedure, so the MySQL instance is your responsibility in the ordinary way. Plan it as you would for any SpringBoot application with a single database.

Editorial conclusion

Adopt jshERP if you run a small trading, retail or wholesale operation and want an Apache-2.0 codebase you can modify, with a Vue 2 front end and a SpringBoot backend your own Java developers can read. Do not adopt it if you need production planning, manufacturing BOMs or a supported commercial SLA, because the README describes the scope as 进销存 plus finance with production listed as future work, and the network edition is a separate paid product. Before committing, verify that MySQL 8.0.24, Redis 6.2.1 and Nginx 1.12.2 are acceptable in your environment, change the default jsh and admin passwords, and read the deployment page at gyjerp.com/doc/archive/deploy.html against your own topology.

Frequently asked questions

Official sources

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