OpenBoxes is a warehouse system built for low resource supply chains

The origin story explains every design decision

Most software projects do not tell you why they exist. This one does, in one paragraph. OpenBoxes was initially conceptualized by staff at Partners In Health as a way to digitize the delivery, inventory and consumption of emergency medical supplies in Haiti in the aftermath of the 2010 earthquake. Today it runs in healthcare facilities all over the world, including in Sierra Leone, Lesotho, Rwanda, Liberia and the United States, providing staff with the tools they need to ensure that lifesaving medication is always available to patients when they need it. That origin is not a historical footnote, it is the specification. The community states four aims, and every one of them is a constraint that comes from the deployment environment. Efficiency is described as rooted in the origin story, with the application expected to run smoothly, reliably and affordably in low-resource environments. Flexibility means it should be adaptable to the everchanging needs of each facility and to the unique requirements of vastly different supply chain systems. Accessibility means it should be intuitive to use, simple to get up and running and affordable to maintain. And sophistication is framed as the counterweight: the community does not want the accessibility of the software to come at the expense of quality, and prides itself on open sourcing a suite of tools that you would normally expect to see only in paid, enterprise tier software. That last pairing is the interesting one. A system that must run on a bad connection in a clinic and still do expiry tracking, batch management and stock movements is a harder engineering problem than a feature checklist suggests.

General purpose, but not for everyone

The README says OpenBoxes is not only for global health systems, and that as an open source project the community has helped evolve the application into a general purpose warehouse management system servicing supply chains across a wide array of industries. It is also honest about the limits of that claim. The features page and the demo site are the places to look for the details, with a sign up link at demo.openboxes.com for experimenting with the application before you install anything, and a feature list at openboxes.com/features/. The subject areas listed in the repository topics tell you the vocabulary of the domain: inventory-management, shipment-tracking, warehouse-management, disaster-response and healthcare. Those are not generic ERP topics, they are the specific vocabulary of moving physical goods through a chain of custody where the goods matter medically and where the environment is often unreliable. The audience for adoption is therefore two groups. The obvious one is a health programme or ministry of health running a medical supply chain, where the fit with the original purpose is close to exact. The other is any organisation with a warehouse and a need for stock tracking, and that group has to make its own judgement about whether a system shaped by emergency medical logistics suits its own inventory. The support and community surfaces are organised as well, with a Slack channel, a support forum at community.openboxes.com, a user guide at help.openboxes.com and a contributor guide published on GitBook.

A Grails application with a React front end and Liquibase migrations

The stack is visible in the repository, and it is a specific and slightly old looking one. The primary language is Groovy, and the application is a Grails project, with a grails-app/ directory, a grails-wrapper.jar and the grailsw and grailsw.bat wrapper scripts. The build is driven by Gradle rather than by the Grails wrapper alone, with build.gradle, settings.gradle, gradle.properties and a gradlew wrapper alongside. The front end is React, built with webpack. The package.json in the repository is for that part of the system, and its scripts show the workflow.

"watch": "webpack --watch --progress --mode=development",
"bundle": "webpack --no-color --mode=production",
"test": "jest",

There is also a styleguide script, styleguidist server, with a build counterpart, and an eslint script that runs with the fix flag over the js and jsx files in src/js. The browser tests use Jest with the jsdom environment, with the roots pointed at src/ and the module directories including src/js, and a module name mapper that replaces css and scss imports with a style mock. mock-local-storage is set up in the setup files, which tells you the front end persists state in local storage. Database changes are handled with Liquibase, in a liquibase/ directory, and there is a reset-database.sh script at the root for starting from scratch. The runtime expectations are pinned, and they are old.

"engines": {
    "node": "^14",
    "npm": "^6 || ^7"
  }

Node 14 and npm 6 or 7 is what the front end build expects, and that is a constraint worth checking before you plan a build pipeline.

Two installation paths, and the split between developers and administrators

The quickstart section splits its audience explicitly, which is a good sign for a project that has to survive both a hackathon and a hospital IT department. For developers, the local setup instructions live in the contributor guide, in a section on running OpenBoxes locally, and they are described as a step-by-step guide on how to quickly get an OpenBoxes server running on your local machine. For system administrators, the installation documentation at docs.openboxes.com is the place to go, with the README telling anyone deploying to a production server to take a look at the admin guide installation section instead. That separation is deliberate. The two jobs have different constraints. A developer needs a server on a laptop in a few minutes, and a hospital needs a deployment that a system administrator can support for years, which means an install guide written for people who did not write the application. The repository reinforces it with a docker/ directory and a docker-image.yml workflow badge, so there is a containerised path alongside the manual one. There is also a docs/ directory, a mkdocs.yml for the documentation site, a .readthedocs.yml with its own build badge, and a separate dbdocs workflow, which suggests the database documentation is generated and published rather than maintained by hand. There is no single install command in the README, and for a project of this size that is sensible. The documentation is where the procedure lives.

Localisation and translation are part of the build

A warehouse system used in Sierra Leone, Lesotho, Rwanda and Liberia is a multilingual application in practice, and the repository is set up for that. There is a crowdin.yml at the root for the translation platform, and a weglot/ directory for the other service, so strings are extracted and managed outside the codebase rather than edited in place. That pairing of services is a small but meaningful detail. It means a translator is not a person who needs to know Groovy or Grails, and a change to a user facing string in the application is not blocked on a translation workflow. The repository also carries a .babelrc and an .eslintrc for the front end, a webpack.config.js, a styleguide.config.js for the component style guide, a jasmine.sh script that appears to be a test runner helper, and a .travis.yml alongside the GitHub Actions workflows. The GitHub Actions badges in the README header map onto the parts of the system that can be checked automatically. There is a badge for the develop branch on change, one for the documentation build on readthedocs, one for the dbdocs build, and one for the docker image build. Four badges, four things that can break silently in a large application: the server code, the docs, the database reference and the container image. A .codebeatignore file is also present, which suggests some static analysis configuration for the JavaScript side.

EPL-1.0, a develop branch, and releases that ship hotfixes

The licence is the Eclipse Public License 1.0, stated in the README with a link to the full text in LICENSE.md and an epl-v10.html file at the root of the tree. EPL 1.0 is a weak copyleft licence, which makes it a sensible choice for an application that organisations want to be able to modify and deploy themselves, including in a modified form, without the whole application becoming a derivative work of someone else's code. For a health system that may need to adapt the application to a national workflow, that is the point. The README is explicit about the terms. By using or contributing to the software in any fashion you are agreeing to be bound by the licence, and you must not remove the licensing notice or any other notices from the software. On releases, the pattern is instructive. The recent tags are v0.9.8-hotfix1 from 2026-08-14, v0.9.8 from 2026-06-13 and v0.9.7-hotfix1 from 2026-04-23. So a base release in June and a hotfix on top of it in August, and the same pattern a quarter earlier. Shipping a hotfix as a separate artefact rather than a patch bump is a deliberate choice, and in a system that manages medical inventory it is a reasonable one, because it lets an administrator apply the fix without changing the version their training and documentation refer to. The default branch is develop, and the badges track that branch, so the release tags are the stable artefact for an administrator and develop is the moving target for a contributor.

Editorial conclusion

Adopt OpenBoxes if you run a medical or humanitarian supply chain and need stock tracking with expiry and movement history in an environment where the server has to run cheaply and reliably. Do not adopt it expecting a current JavaScript toolchain, because the front end build pins Node 14 and npm 6 or 7, and do not adopt it for a general commercial warehouse without reading the feature list and the demo first. Before deploying, pick the tagged release rather than the develop branch, and confirm the Docker image build and the database documentation build are both green for the version you plan to run.

Frequently asked questions

Official sources

1. License: EPL-1.0
2. openboxes/openboxes on GitHub
3. Project website
4. README
5. Releases