GreaterWMS: a Django and Quasar warehouse management system built to be modified

What GreaterWMS actually is, and who it is for

GreaterWMS is an inventory and warehouse management system written mainly in Python. The README describes it as the warehousing and supply chain process used in Ford Asia Pacific after-sales logistics, started by the author after leaving Ford. The stated motivation is that commercial WMS products are closed source and expensive to extend, so secondary development stays tied to the original vendor. GreaterWMS is offered as a base platform instead: the README says it can serve as the foundation whether you only need inventory and warehouse management or you need to connect IoT, ERP and distribution systems.

The intended reader is therefore not a warehouse operator shopping for software. It is a development team, or a systems integrator, that expects to write code. The repository layout supports that reading: modules are separated by directory, with asn/, dn/, stock/, warehouse/, binset/, cyclecount/, supplier/, customer/ and goods/ each holding their own slice of the domain. The README lists customization scenarios across 3PL and cloud warehouses, pharmaceutical distribution, cold-chain warehousing, cross-border e-commerce and manufacturing. Those are described as customizations performed on top of the native code, not as features shipped in the open source build.

The Django REST backend and Quasar frontend split

The architecture is a separated frontend and backend. The backend is Django with Django REST Framework, and the README states that the APIs follow the RESTful protocol. The frontend is Quasar on Vue, and the README describes compiling the same codebase into web, Android and PDA programs, and even WeChat Mini Programs. That is the OneAPP idea: one backend serving several terminals.

The business logic is organised by module, and the README makes an explicit claim about the consequence: you can modify or extend only the modules you need without affecting other features. The directory names in the repository match the vocabulary the README uses, so ASN receiving, DN shipping, inventory and storage locations are separate Django apps rather than one large model file.

Two details are worth flagging as constraints rather than features. The frontend talks to the backend through a request address stored in templates/public/statics/baseurl.txt, which the README names under request address configuration. Change where the backend runs and you change that file. Second, the pinned stack is old: requirements.txt lists Django 4.1.2, djangorestframework 3.14.0, pandas 1.5.1 and Twisted 22.10.0, while the README's tech stack line says Python 3.8+ and Django 3.1+. The Dockerfile builds the backend on python:3.8.10-slim and the frontend on node:14.19.3-buster-slim, both with an explicit --platform=linux/amd64. Anyone planning to run this on ARM hardware has to deal with that flag first.

Installing GreaterWMS and getting the API up on port 8008

There are two documented routes. The manual route starts by cloning the repository and installing the pinned Python dependencies, then running the ASGI application with daphne. The README gives the backend command with host 0.0.0.0 and port 8008, so that is the port the API listens on.

git clone https://github.com/GreaterWMS/GreaterWMS.git
cd GreaterWMS
pip install -r requirements.txt
daphne -b 0.0.0.0 -p 8008 greaterwms.asgi:application

After that command the Django project is served by daphne rather than runserver, which matters because the dependency list includes daphne, autobahn and Twisted, the ASGI and WebSocket stack. The repository also contains manage.py, so the usual Django management commands are available for migrations and administration, though the README's quick start does not spell them out.

The frontend is a separate install. The README moves into templates/, installs the Node packages and starts the Quasar development server.

cd templates
npm install
quasar dev

Before the frontend can reach the backend, the request address has to be set in templates/public/statics/baseurl.txt. The Docker route is the shorter one: docker-compose.yml defines a front service on image greaterwms/greaterwms:front published on port 8080, and a backend service on image greaterwms/greaterwms:backend published on port 8008, with the repository mounted at /GreaterWMS/ and supervisord.conf mounted into /etc/supervisor/. The compose file also mounts ./templates into the front container. Both Dockerfile stages target linux/amd64.

Where GreaterWMS is the wrong tool

The most concrete limitation is documentation drift. The README states that all developer documentation has been migrated to the Bomiot repository, and that GreaterWMS 3.0 has its core rebuilt using Bomiot, a Rust-based framework with a plugin architecture and an app marketplace installed via pip. That means the guides a developer needs in order to extend the system may no longer live beside the code. A team that clones this repository and looks for extension documentation will find the README pointing elsewhere.

The release history is also uneven. V2.1.48 was released on 2023-12-15 and V2.1.49 on 2024-04-14, then the next listed release is V2.1.52 on 2026-09-15. A gap of more than two years separates the last two entries in that list, and the jump from 2.1.49 to 2.1.52 coincides with the 3.0 rebuild announcement. Anyone pinning to a 2.1.x release should assume the upgrade to the Bomiot-based core is not a small patch.

Two further points. The README does not document rollback, backup or data migration between versions, which is a real gap for software that owns your inventory records. And the performance figures in the customization scenarios, such as inventory turnover days dropping from 45 to 28 at one pharmaceutical distributor, are reported as customer outcomes without methodology; treat them as marketing context, not measurements. If you need a system you can evaluate without reading Django models, this is the wrong starting point.

GreaterWMS compared with ModernWMS and other open source WMS options

The closest comparison people search for is ModernWMS, which appears alongside GreaterWMS in the related searches. The difference in approach is the stack and the extension model. GreaterWMS is Python and Django REST with a Quasar frontend, and its stated design goal is customization: modular Django apps you edit in place, with the 3.0 line adding a Rust-based plugin layer and an app marketplace through Bomiot. A .NET-based WMS such as ModernWMS appeals to teams already in that ecosystem, where the extension work happens in C# rather than in Django models and Vue components.

There is also the general category of open source inventory systems, including the MERN-style projects that show up in the same search results. Those usually ship a single web application with a JavaScript backend. GreaterWMS differs in having a separate ASGI backend process, a PDA-oriented frontend that compiles to Android and WeChat Mini Programs, and a domain model split across asn/, dn/, stock/, cyclecount/ and warehouse/ rather than a generic items-and-orders schema. If your warehouse process is simple, a smaller project will be less to maintain. If your process is the reason you are replacing software, the module split is the part that matters.

Maintenance, upgrades and the Apache-2.0 licence

The repository is not archived, and the last push was on 2026-09-17, days before V2.1.52 was published on 2026-09-15. So the 3.0 work is current. That does not make upgrades cheap. The core has been rebuilt on a different framework, and the README's own framing is that 3.0 is a rebuild rather than an increment. A team running a 2.1.x deployment has to decide whether to port customizations onto the Bomiot plugin model or stay on the older line, and the README does not describe a supported migration path.

On licensing, the repository ships a LICENSE file and the README states Apache 2.0. That is a permissive licence, which generally permits commercial use and modification with attribution and notice requirements, but the exact obligations depend on the file in the repository rather than on this description. If you plan to redistribute a modified GreaterWMS, or to offer it as a hosted service, read LICENSE and, where the stakes justify it, take advice. The README also lists contact channels for customization and secondary development enquiries, which suggests commercial support exists outside the repository, though no support terms are stated.

Editorial conclusion

Adopt GreaterWMS if you have Python and Vue developers who intend to change the code, and if ASN receiving, DN shipping, inventory and storage locations cover your core flows. Do not adopt it if you need a finished product with a documented upgrade path, or if you cannot read Django models and Quasar pages yourself. Before committing, verify the licence file, confirm the baseurl.txt request address matches your deployment, and check whether the developer documentation you need has already moved to the Bomiot repository.

Frequently asked questions

Official sources

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