InvenTree: a Django and REST API inventory backend for parts and stock tracking

The gap InvenTree fills: parts you can query, not just a stock count

Most small inventory tools answer one question: how many of this item are on the shelf. InvenTree is aimed at a different shape of problem. The README describes it as providing "powerful low-level stock control and part tracking", which is a statement about granularity. Parts, stock locations and stock items are separate records, and the backend exposes them through a Django admin interface and a REST API rather than through a fixed set of screens. That matters when the inventory is electronics components, spare parts or sub-assemblies where the same part sits in several places and moves between them. The intended audience is a team with at least one person comfortable running a Python service. The README lists integration paths for the API, a Python module, a plugin interface and third party tools, so the assumption is that InvenTree is the system of record and something else is the front end. If nobody on the team wants to operate a database server, the project is the wrong shape from the start.

Django, DRF and Django Q: how the backend is put together

The architecture is a conventional Django application with a separate JavaScript client. The README's tech stack section names Python, Django, Django REST Framework for the API layer, Django Q for background tasks, and Django-Allauth for authentication. The client is React, with Lingui for translation, React Router, TanStack Query, Zustand, Mantine and Mantine Data Table, and CodeMirror. The database options listed are PostgreSQL, MySQL, MariaDB, SQLite and Redis. Redis appears in the database list but its practical role is as the broker for the Django Q worker queue, which is why a deployment generally needs both a relational database and Redis running alongside the web process. The repository layout supports this reading: src/ holds the application, config/ holds deployment configuration, contrib/ holds supporting material, and there is a Procfile, which is the process declaration used by platform-as-a-service deployments. The practical consequence is that the web interface and the REST API are the same application. Anything you can do through the UI is reachable through the API, and plugin code runs inside the same process, which is convenient for extension and also means a misbehaving plugin affects the server rather than a sandbox.

Installing InvenTree with Docker or the single line script

The README offers three deployment routes: Docker, bare metal, and a single line installer, with links to the documentation for each. The single line install is given verbatim in the README, and the README directs readers to the installer documentation for the list of supported distributions and for details about what the script does.

wget -qO install.sh https://get.inventree.org && bash install.sh

Run that on a supported distribution and the script handles the setup; on anything outside the supported list, use the bare metal instructions instead. The container image is published as inventree/inventree on Docker Hub, and the README points to a Docker deployment page in the documentation rather than embedding a compose file, so the image tag and the surrounding services come from the docs. For a first real use, the README links a hosted demo at demo.inventree.org. That is the cheapest way to see whether the parts and stock model matches how you think about your inventory, before you spend time on a server. There is also a companion mobile app, linked from the README to the Android Play Store and the Apple App Store, which the project documents as giving access to stock control information and functionality. The README does not document a rollback procedure for the installer script, so plan a snapshot or a database backup before running it on a machine you care about.

The plugin interface is the extension point, and the constraint

InvenTree's extensibility story is the plugin interface, documented separately from the REST API. Plugins are how custom behaviour gets added without forking the backend, and the README frames the project as "designed to be extensible" with integration options for external applications. The trade-off is version coupling. A plugin written against one release has to keep pace with the backend, and the release history shows a fast cadence: 1.5.0 on 2026-08-11, 1.5.1 on 2026-08-19, and 1.5.2 on 2026-08-25. Three releases in a month is normal for an active project, and the last push to the repository was on 2026-08-25, so this is not a dormant codebase. For a team running plugins, that cadence means upgrade testing is a recurring task rather than a one-off. The repository carries a CHANGELOG.md, which is where the per-release detail lives; the README itself does not describe a plugin compatibility policy or a deprecation window, so that is something to establish by reading the changelog and the plugin documentation before you build on the interface.

Where InvenTree is the wrong tool

InvenTree assumes you will operate it. The README's deployment section is entirely about installing the software yourself, whether through Docker, bare metal or the installer script, and the database list is a list of servers you run. There is no hosted offering described in the README. A two-person workshop that wants a browser tab and a monthly bill should look elsewhere. The second limitation is platform support for the installer: the README explicitly says to read the documentation for supported distributions and details, which is a signal that the single line script is not universal. If your environment is Windows, the README does not present a Windows install path; the documented routes are Docker and bare metal, and the search interest in a Windows install is not matched by a documented Windows procedure in the README. Third, the granularity cuts both ways. A parts-and-locations model with stock items is more structure than a simple consumables cupboard needs, and the setup cost of modelling your inventory correctly is real. If your inventory is a spreadsheet with a hundred rows that never moves between locations, InvenTree's data model is overhead.

InvenTree against Part-DB and Odoo

The README acknowledges PartKeepr as "a valuable predecessor and inspiration", which places InvenTree in a lineage of open source parts databases rather than in the ERP category. Part-DB is the closest comparison in that lineage, and the difference is the integration surface. InvenTree's core is a Django backend with a documented REST API, a Python module and a plugin interface, and the README lists those as first-class integration options. A parts database that is primarily a web application gives you screens; InvenTree gives you screens plus an API you are expected to call. Odoo is a different comparison entirely. It is a full ERP suite where inventory is one module among many, with its own module ecosystem and its own deployment model. If you already run Odoo for accounting or manufacturing, adding inventory there avoids a second system. If you want a focused inventory backend that your own scripts and services can talk to, and you do not want the surrounding ERP, InvenTree's narrower scope is the point. The README's own framing, a database backend with an admin interface and a REST API, is an accurate description of which side of that line the project sits on.

Licence, upgrade cost and what the repository tells you about maintenance

InvenTree is MIT licensed, per the badge and the LICENSE file at the repository root. MIT is permissive: you can use, modify and redistribute the code, including in commercial settings, provided the licence notice is preserved. That is a statement about the licence text, not legal advice for your situation; if you plan to redistribute a modified InvenTree, have someone qualified read the LICENSE file rather than this paragraph. The upgrade cost is the part that deserves attention. The last push was on 2026-08-25, and the three 1.5.x releases landed on 2026-08-11, 2026-08-19 and 2026-08-25. A project shipping at that rate is moving, which is good for fixes and bad for anyone who wants to install once and forget. The repository includes .pre-commit-config.yaml, ruff configuration in pyproject.toml, biome.json, codecov.yml and a .devcontainer directory, which together indicate an enforced lint and test pipeline. For upgrade planning, the CHANGELOG.md at the repository root is the file to read before each jump, and the plugin documentation is the second thing to check if you run plugins.

Editorial conclusion

Adopt InvenTree if you need an inventory database you can query and extend from your own code, and you are willing to run PostgreSQL or MySQL plus Redis and keep up with a release cadence that shipped 1.5.0, 1.5.1 and 1.5.2 within August 2026. Do not adopt it if you want a hosted service with no server to operate, or if you need an official Windows build, since the README points at Docker, a bare metal path and a single line installer for supported distributions. Before committing, check the plugin interface documentation against the version you plan to deploy, and confirm the supported distributions list for the installer script.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes