OpenBoxes WMS: the short answer

Answer in brief: OpenBoxes is an actively maintained, open-source WMS (warehouse management system) with healthcare roots, but it is a pre-1.0 Groovy/Grails application distributed as a WAR file. If your organization runs lot- and expiry-aware supply chain workflows and has developer capacity for deployment, upgrades, and customization, OpenBoxes is worth evaluating; if you need a quick, low-maintenance, or strongly localized out-of-the-box system, it is probably not the right fit. This article is a source and documentation review of the repository as of August 11, 2026; no installation or runtime testing was performed.

Key facts at a glance

What OpenBoxes is and where it comes from

OpenBoxes is described by its maintainers as an accessible, open-source warehouse and inventory management system designed to manage inventory and track stock movements for healthcare facilities. Its origin is humanitarian: staff at Partners In Health first conceived it to digitize the delivery, inventory, and consumption of emergency medical supplies in Haiti after the 2010 earthquake, according to the README. The maintainers state the application now runs in healthcare facilities in Sierra Leone, Lesotho, Rwanda, Liberia, and the United States, and that the community has evolved it into a more general-purpose warehouse management system used across supply chains in many industries.

Those are project claims, and the repository activity is consistent with them: the release notes are dominated by healthcare-oriented workflows such as lot numbers, expiry dates, cycle counts, purchase orders, receiving, returns, and shipment tracking. The repository topics point the same way: healthcare, disaster response, warehouse management, inventory management, and shipment tracking.

Who should consider OpenBoxes WMS

OpenBoxes is a realistic candidate for healthcare, pharmaceutical, and humanitarian supply chain operations that need lot and expiry visibility, receiving and shipment workflows, and stock movement tracking, provided they have technical capacity. Concretely, that means at least one person or partner who can operate a Java application server, manage a database, read release notes, apply upgrades and security patches, and write or commission customizations when a workflow is not covered.

It is also a plausible base for teams that want to build custom inventory, ERP, or logistics software on an open-source foundation instead of buying a closed system, because the code is public under EPL-1.0. That path assumes you are willing to invest in Groovy and Grails skills, since that is the stack the application is built on.

If your situation is the opposite, a small team with no developer support, a requirement to go live this month, or a need for polished localization in many languages, OpenBoxes will likely cost more than it saves. Nothing in the evidence suggests it is a plug-and-play SaaS replacement.

Realistic OpenBoxes use cases

• Healthcare facility supply: managing medication inventory, expiry dates, lot numbers, requisitions, and stock movement, which is the project’s design center.
• Regional warehousing and distribution: receiving, shipment tracking, cycle counts, and returns workflows that appear throughout the v0.9.7 and v0.9.8 release notes.
• Low-resource and disaster-response settings: the README explicitly targets running affordably in low-resource environments, and disaster response is a listed topic.
• Platform for custom inventory development: organizations that plan to extend or integrate a healthcare-oriented inventory core with their own reporting, integrations, or workflows.

Each use case assumes you will operate OpenBoxes rather than consume it as a finished product. The v0.9.8 release notes alone list dozens of fixes and features across receiving, returns, cycle counting, import/export, and stock history, which is evidence of momentum, but also of a large, evolving codebase.

Maintenance signals: active, with a visible backlog

The maintenance picture is good in the areas that matter for adoption. The repository’s last push was August 10, 2026, one day before this review’s snapshot. Maintainers published four releases between March and June 2026, v0.9.6-hotfix2, v0.9.7, v0.9.7-hotfix1, and v0.9.8, and each ships a WAR artifact, so there is a defined upgrade path. The v0.9.8 release notes list fixes for three security advisories, and the same release includes maintenance work on URL and upload handling and role-permission boundaries. The README also displays CI status badges for the develop branch, documentation, database docs, and Docker image builds.

The counterweight is the issue tracker. The repository shows 176 open issues, and the sampled issues include a feature request from April 2019 still labeled needs discussion, a record-stock comment issue open since December 2019, and a Chinese localization display bug open since July 2024. An active release cadence and an old unresolved backlog can coexist; they mean the project is being worked on, but not every reported problem gets a quick fix.

Deployment concerns to check before production

Start with version discipline. The default branch is develop, and production deployments should pin to a release such as v0.9.8, then read the release notes before upgrading. Between v0.9.7 and v0.9.8, for example, the maintainers changed product import so it now errors when an assigned category does not exist, with the previous behavior available only through the application property openboxes.import.product.createMissingCategories: true. That kind of change matters when you depend on existing import files.

Deployment is not a simple single-file web app. The v0.9.8 release distributes openboxes.war, a roughly 190 MB Java archive, which implies a Java application server rather than plain static or PHP-style hosting. The v0.9.7 release notes mention running OpenBoxes via Docker Compose and supporting Docker Engine 29, so containers appear to be a supported path, but this review did not verify that path against a live environment.

The stack is also mid-migration. Release notes reference Grails 3 unit tests and consolidating tests into Grails 3’s customary location, which suggests the framework transition is ongoing. If you write custom code against this codebase, plan for framework and API changes between versions.

Security patching is an operational requirement, not an option. Because v0.9.8 bundled fixes for three security advisories, an unpatched deployment is behind on known fixes; your plan should include a named person responsible for applying each release and testing it before it goes live.

Limitations and gaps to plan for

• Pre-1.0 maturity: every release in the snapshot is 0.9.x, and behavior changes like the product import category rule confirm that upgrades can alter workflows.
• Healthcare-shaped workflows: the evidence does not show finance, HR, manufacturing, or consumer e-commerce coverage; OpenBoxes is an inventory and stock movement system, not a full ERP.
• Localization gaps: an open issue reports that some page labels do not display when using Chinese, and release notes are published in English, French, and Spanish with a contributed Brazilian Portuguese translation; verify language coverage for your users before committing.
• Old feature requests: the stock-list workflow request from 2019 remains open, so do not assume an uncovered workflow will arrive soon.
• EPL-1.0 obligations: the Eclipse Public License has its own requirements, and the README requires retaining license notices; have legal review the terms for how you plan to use, modify, or redistribute the software.
• No vendor contract: support is community-oriented through Slack, forums, and a support guide, rather than a commercial SLA.

Evaluation questions and alternatives

Before committing, answer these against your own operation:

1. Do your core workflows match lot, expiry, receiving, shipment, return, and cycle-count patterns, or are you forcing a different process into them?
2. Who will deploy, upgrade, back up, and patch the system, and what is that person’s Grails, Groovy, or JVM experience?
3. Can your hosting environment run a Java application server and a roughly 190 MB WAR, or will you need containerization support?
4. Which languages must the UI support, and is each language actually covered?
5. What integrations do you need, such as accounting, ERP, EDI, barcode hardware, or reporting, and who will build them?
6. Is EPL-1.0 acceptable to your legal team for embedding or redistributing the software?

On alternatives: this review did not benchmark OpenBoxes against other products, so treat any comparison as your own pilot. The practical categories are commercial WMS/ERP platforms, general-purpose open-source ERP suites with inventory modules, and a custom-built inventory system. Compare them on workflow coverage, total cost of ownership, integration effort, language support, and who maintains the code, the same criteria this review used. The maintainers link a demo site and installation documentation, which are the right first step before any commitment.

Verdict

OpenBoxes is worth serious evaluation if you run a healthcare or humanitarian supply chain and can commit to operating a Grails application: the project is active, releases regularly, publishes security fixes, and is rooted in a real operational domain. It is not the right default for a team that wants inventory software without technical ownership, and it is not a complete ERP. Adopt it as a foundation you will deploy, patch, and extend, not as a finished product you turn on.

OpenBoxes WMS FAQ

Is OpenBoxes a WMS? Yes. It is an open-source warehouse and inventory management system for stock movements, receiving, shipments, returns, and cycle counts, with its design center in healthcare supply chains.

Is OpenBoxes free to use? The code is public under the Eclipse Public License 1.0 (EPL-1.0), and the license carries its own obligations. Support is community-oriented through Slack, forums, and a support guide rather than a commercial SLA, and this review does not cover commercial pricing.

Does OpenBoxes track lots and expiry dates? Lot numbers and expiry dates are part of the workflows the release notes emphasize, which is consistent with the project’s healthcare origins.

Can OpenBoxes run in production today? It can be evaluated for production, but every release in this snapshot is 0.9.x, deployment requires a Java application server, and security patching is an ongoing operational duty.

Sources

• openboxes/openboxes repository
• Release v0.9.8 (June 13, 2026)
• OpenBoxes website
• OpenBoxes installation documentation
• Issue #1029: stock list option, open since April 2019
• Issue #4770: Chinese localization labels, open since July 2024
• Issue #1383: record stock comment, open since December 2019

If you are evaluating OpenBoxes or comparing it with alternatives, I can help you scope the pilot and the production plan before you commit, and I help teams work through exactly this kind of decision: reviewing open-source systems against your workflows, planning deployment and upgrade paths, and building the custom inventory, ERP, and business-process integrations around them.