GreaterWMS is an open-source warehouse and inventory management system built on Python, Django, and a Vue-based frontend. This review is a source and documentation review as of 14 August 2026: I examined the repository, its releases, and its open issues, but I did not install or run the software. The short answer: GreaterWMS is a substantial, real-world codebase, but at this snapshot it is not a turnkey product. The latest release is V2.1.50 (June 2025), the last push to master was September 2025, the maintainers have announced a 3.0 rebuild on a new framework called Bomiot, and open issues include bug reports around file uploads and a possible CSRF problem. Consider it if you have development capacity and a tolerance for custom work; verify licensing, recent maintenance, and your own workflows before production.

Key facts at a glance

What GreaterWMS is

The repository describes itself as an inventory management system modeled on the Ford Asia Pacific after-sales logistics warehousing supply chain process, started by its creator after leaving Ford. According to the maintainers, the original intention was a framework to make warehouse software development accessible, but the project grew into a complete system. They have since built a Rust/Python CLI framework called Bomiot and say GreaterWMS 3.0 will be rebuilt on it; the current 2.x line is what the repository ships today.

“This Inventory management system is the currently Ford Asia Pacific after-sales logistics warehousing supply chain process. After I leave Ford, I start this project. You can share your vacant warehouse space, use it for those in need, and generate income.” (repository description)

Release notes and issue history give a picture of the covered workflows: inbound ASN documents, delivery notes and outbound shipping, bin moves, picking orders, inventory deduction logic, and mobile picking logic. The V2.1.42 release added “warehouse interconnection” so organizations can share vacant warehouse space, and the V2.1.48 notes mention a new JWT library in preparation for a WCS release. These are the maintainers’ descriptions in the repository, not results I verified by running the system.

Who should consider GreaterWMS

GreaterWMS is most defensible as a starting point for teams that can develop and maintain it:

• Organizations with Django/Vue developers who want a self-hosted WMS base and expect to customize workflows, add integrations, and own upgrades.
• Operations whose processes resemble the after-sales parts and logistics pattern the maintainer says the system follows; those teams will find the data model closer to their needs than a generic ERP.
• Developers evaluating open-source WMS designs, or vendors who want to build a product and need a starting skeleton.

With conditions: if you have no in-house engineering, no budget for a contractor, and no tolerance for open bug reports, this is probably not your system today. The evidence does not show a supported, hosted, or guaranteed-maintenance option.

Maintenance signals to weigh

Popularity is not maintenance. At the 14 August 2026 snapshot the repository shows 4,343 stars and 1,157 forks, which tells you the project attracts interest, not that it is actively fixed. Weigh these signals:

• The latest release, V2.1.50, was published on 29 June 2025, and the last push to master was 26 September 2025. As of the review date that is roughly eleven months without a release or a push.
• 77 issues were open at the snapshot. Bug reports include an upload-center failure opened in March 2024 (issue 365) and a similar upload problem from March 2026 (issue 401), both still open.
• Issue 373 reports a possible CSRF vulnerability in the user registration endpoint and has been open since May 2024. I am not making a security judgment of my own; I am noting that a security-relevant report has remained open for over two years at this snapshot.
• The README’s quick start and CI badges point to a fork (dev00amk/GreaterWMS-amk), not the canonical repository. Someone following the README literally could clone the wrong line of development.
• The maintainers’ stated direction is a 3.0 reconstruction on Bomiot, which raises a real question of how much more investment the 2.x line will receive.

Deployment concerns and what to check before production

The README’s prerequisites are Python 3.9+, Node.js 16+, PostgreSQL 13+ for production, and Docker/Docker Compose as an optional path. The setup flow described is a Django backend plus a frontend build under templates/, using npm install and a Quasar dev or production build. Before you rely on any of it, work through these checks:

• Clone from the canonical repository and pin a release. Use git clone https://github.com/GreaterWMS/GreaterWMS.git and git checkout V2.1.50 rather than following the README’s fork link, which points to dev00amk/GreaterWMS-amk.
• Resolve the license question. The GitHub API reports Apache-2.0, while a README badge displays MIT. The two licenses differ meaningfully, including patent grant and notice requirements, so confirm the intended license with the maintainers before commercial reuse.
• Validate the container path on your own infrastructure. Issue 399 shows a docker-compose failure caused by a Docker client and daemon API version mismatch, so environment version differences are a realistic friction point.
• Test the upload and document workflows explicitly: two open issues report upload-center failures.
• Review security posture yourself: check open security-related issues, run the scanning tools the README documents (safety, bandit, npm audit), and review authentication, CSRF handling, and network exposure in your deployment.
• Plan the mobile story. The evidence shows desktop-oriented setup instructions and Windows release packages such as the V2.1.49 archive; an open issue asks for a ready-built APK. If floor staff needs phones, budget for building and maintaining the app from source.
• Back up and rehearse data migration. Release notes mention fixes to inventory disappearing when moving databases and changes to inventory deduction logic, which is exactly the area you do not want to discover problems in after go-live.

Limitations to plan around

• No evidence of official support, hosting, or an SLA. You would be responsible for upgrades, patches, and incident response.
• Feature gaps are visible in the issue tracker: supplier management and product expiry management are open feature requests as of the snapshot, so if those are core needs, expect to build them.
• Version transition risk: custom work done on 2.x today may be stranded if 3.0 ships with breaking changes on Bomiot.
• Scale and performance are unknown: there is no benchmark evidence in this review, so load-test with your own order volumes, pick waves, and user counts.
• The community is internationally mixed, with open issues appearing in both English and Chinese, which is a strength for reach but means documentation and support language are not uniform.

Alternatives and evaluation questions

Rather than recommend a specific competing product without evidence, here are the questions that should drive your comparison, whether that means a commercial WMS, an ERP with inventory modules, or another open-source system:

1. Do you have, or can you contract, Django/Vue development capacity for setup, bug fixes, and custom features?
2. Which workflows are non-negotiable: lot and expiry tracking, multi-warehouse, barcode scanning, carrier or e-commerce integrations, financial accounting?
3. Who owns security patching and upgrades, and what happens during the current quiet period?
4. Can your business tolerate a system whose maintainers are publicly rebuilding it on a new framework?
5. What transaction volume, concurrent users, and integration traffic must the system handle?

Whatever you compare against, evaluate with your own data and processes: import a representative dataset, run your actual receiving-to-shipping flows, and watch where the workflow breaks.

Verdict

GreaterWMS is a serious open-source warehouse management codebase with an Apache-2.0 license, a real-world process origin, and years of release history. For a team with development capacity, it is worth evaluating as a base for a custom, self-hosted WMS, provided you pin a release, resolve the license discrepancy, review the open security and upload issues, and budget for custom work. For an organization that needs a supported, maintained system today, the evidence does not support treating GreaterWMS as turnkey: the release cadence has stalled, the 2.x line is awaiting a 3.0 rewrite, and core feature requests remain open. The recommendation is conditional: evaluate it only if you have engineering ownership, and decide based on your own pilot, not on stars or screenshots.

Sources

• GreaterWMS/GreaterWMS repository: README, license metadata, topics, and repository statistics
• GreaterWMS V2.1.50 release: latest release notes, including the Bomiot 3.0 statement
• Issue 373: possible CSRF vulnerability; open security-related report
• Issue 365: unable to upload goods list file; open bug report
• Issue 399: docker-compose error; deployment friction report
• Bomiot: framework referenced by the maintainers for the GreaterWMS 3.0 rebuild

If you are trying to decide whether GreaterWMS, or any open-source system, fits your operation, I can help you work through that decision: I review the codebase and issue history against your workflows, estimate the custom development and maintenance effort, and plan the deployment or a safer alternative. That kind of evaluation is a normal part of what I do at XP812, and I will tell you when a project is not worth the risk rather than pushing you toward it.