Part-DB Inventory Management Features and Setup

Why Part-DB Fits Electronic Component Collections

Part-DB addresses a specific inventory problem: recording what electronic components exist, where they are stored, what they cost, and which files describe them. A component record can be connected to a category, footprint, manufacturer, tags, storage locations, and price information. That structure is more useful than a generic spreadsheet when a collection contains parts with different package types, datasheets, photographs, and purchasing history.

The intended users range from hobbyists tracking a private collection to makerspaces controlling access for several users. The README also says small companies and universities use it. Shared installations need the built-in user, group, and fine-grained permission system. This is an important distinction from a private stock list. Part-DB is designed for an inventory that may be edited by more than one person and may need an event history.

Its project and bill-of-materials features extend beyond counting stock. Users can assign parts to a project, calculate how many complete builds are possible from available inventory, and withdraw the required components. KiCad integration can use Part-DB as the central source for available parts. For an engineering team, that creates a path between inventory records and schematic or PCB work, although the README does not describe synchronization behavior or conflict handling.

Part-DB is not an electronic design automation suite. It does not replace KiCad, schematic editing, PCB design, or component lifecycle management. Its role is the inventory record and the handoff between procurement, storage, projects, and available design data.

The Symfony Data Flow Behind Part-DB

The current repository is a complete rewrite of the legacy Part-DB version below 1.0. Its application runs as a Symfony 7 web application, with PHP 8.2 as the minimum stated version. The repository layout follows the conventional separation between `src/`, `config/`, `templates/`, `public/`, database migrations, translations, tests, and frontend assets. A web server must serve the application from `public/`, which keeps application code outside the directory exposed directly by the web server.

Inventory records are relational data. The repository includes `migrations/` and Symfony console tooling, while the supported backends are SQLite, MySQL, and PostgreSQL. SQLite removes the need for a separate database server. MySQL 5.7 or newer and MariaDB 10.4 or newer are supported, as is PostgreSQL 10 or newer. The backend choice is configured through `DATABASE_URL` in the local environment file rather than through a user interface.

Uploaded component data has a filesystem-facing side as well as database records. The repository contains an `uploads/` directory, and the Dockerfile explicitly creates `uploads` and `public/media` during its build. Component files can include datasheets and pictures. Automatic thumbnail generation and rich descriptions therefore depend on writable storage and successful media processing, not just a database connection.

The frontend is compiled through Webpack Encore. `package.json` defines development and production asset scripts, while `yarn.lock` records the JavaScript dependency tree. The documented frontend requirement is Node.js 22.0 or newer. This architecture is conventional, but it involves more infrastructure than a single-file or desktop inventory application. Upgrades may involve PHP dependencies, JavaScript assets, database migrations, and persistent uploads.

Installing Part-DB and Reaching the First Inventory Screen

The repository describes a rough installation path and points to the detailed installation documentation. The first documented operation copies the environment file so local settings do not directly modify the shared `.env` defaults:

cp .env .env.local

The README then instructs administrators to change `APP_ENV=dev` to `APP_ENV=prod` in `.env.local`. If SQLite is not suitable, the administrator must replace the `DATABASE_URL=` value for the selected database. It also says to configure the web server to serve from `public/`. The installation excerpt ends before its remaining Symfony commands, so this article does not invent a cache-clearing or migration command for the production guide.

For a developer environment, the Makefile provides a dependency target that installs both PHP and frontend dependencies:

make deps-install

That target runs `composer install` and `yarn install`. The repository requires Node.js 22.0 or later, and the Dockerfile uses PHP 8.4 and Node.js 22 for image builds. A self-hosted installer therefore needs the PHP extensions and database access required by the selected Symfony configuration. Shell access is described as highly recommended.

Docker is the more encapsulated deployment path documented by the project. The published image is `jbtronics/part-db1`. The README refers readers to the Docker installation documentation rather than reproducing a `docker run` or `docker compose` command. Database variables, persistent volumes, proxy settings, and upgrade actions are essential parts of a container deployment, but the README excerpt does not state their exact values.

For a first real use, start with the public demo before configuring a server. The README provides a demo login with username `user` and password `partdb-demo`. The demo is convenient for inspecting the responsive browser interface, part fields, and list views. It is not evidence that a private installation is stable because the README says every change to `master` is automatically deployed there and that the deployment may not be completely stable. After installing a release, the first production activity should be creating an administrator or group, configuring the database and uploads location, and entering a small set of real components.

Permissions, Inventory Changes, and External Data

Access control is more than a basic login. Part-DB supports groups, detailed permissions, two-factor authentication through Google Authenticator or WebAuthn/U2F keys, and enforcement of two-factor authentication for a group. Optional SAML SSO can connect the application to an identity service such as Keycloak, which can in turn connect to LDAP or Active Directory. Password reset by email can also be configured.

For a makerspace, this permits different levels of access, but the README does not publish a predefined role matrix. An administrator must determine which groups may edit costs, move stock, upload files, revert records, manage projects, or administer users. Restricting the initial administrator account after setup is therefore a specific deployment task, not a generic security recommendation.

The event log records inventory changes and which user performed them. Part records can be reverted to older versions. That history is useful when a component is assigned to the wrong location or its metadata is changed incorrectly. The documentation does not explain retention limits, bulk restoration behavior, or whether all administrative actions are reversible, so restoration should not be treated as a substitute for database backups.

Part-DB can also retrieve component information from configured cloud providers such as Octopart, DigiKey, Farnell, LCSC, and TME. It supports a browser plugin for submitting parts from shops, structured metadata extraction, AI-based extraction, and extraction from uploaded PDF datasheets. The MCP Server gives AI agents and chats access to an instance. These integrations expand the application, but each depends on external services and credentials. The README does not state retention rules for submitted data, accuracy guarantees for AI extraction, or the operational impact of the MCP endpoint, so those points require separate review.

Operational Limits of a Self-Hosted Part-DB

The clearest limitation is deployment ownership. A web server must run Symfony 7, PHP must be at least 8.2, and frontend assets require Node.js 22 or later when built from source. SQLite simplifies the database arrangement, while MySQL, MariaDB, or PostgreSQL introduces server administration. Persistent component files also need reliable backup and writable storage.

Part-DB is the wrong choice when a browser service with server administration is unacceptable. A standalone desktop catalog may fit a single user better. It is also a weak fit for organizations whose core need is procurement, manufacturing execution, warehouse automation, or barcode compliance beyond the documented part and location label features. The README confirms inventory management and project withdrawal, but it does not claim manufacturing planning or a complete purchasing workflow.

Its AI extraction and shop automation deserve caution. Data imported from a supplier page or PDF can contain inaccurate package, footprint, or manufacturer information. The documentation describes the extraction mechanisms but provides no accuracy metric or review workflow. Treat generated data as data to inspect rather than as a guaranteed component master record.

The demo also has a distinct reliability limitation. The README says the free Heroku instance can be slow when loading a page for the first time and that it tracks the current development progress of `master`. It should be used as a product preview, not as an uptime benchmark or proof of production behavior.

Finally, the repository name and legacy history can cause upgrade mistakes. This version is a complete rewrite of the pre-1.0 application, and the README directs legacy users to separate upgrade documentation. Copying a database or configuration directly from the old system without following that migration guide would not be a documented installation procedure.

Part-DB Compared with a Spreadsheet Inventory

A spreadsheet is the clearest alternative because both can record a part name, quantity, location, price, and notes. The practical difference is that Part-DB makes relationships and shared operations part of the data model. A component can have multiple locations and price records, a manufacturer and footprint, tags, files, and project assignments. A maker using KiCad can query the same inventory from the design workflow rather than maintaining a separate exported list.

Spreadsheets are easier to start and may be sufficient for one person with a small, stable collection. They also make local copies and ad hoc calculations straightforward. Part-DB instead centralizes the record in a browser application and adds an event log, permissions, revisions, labels, BOM workflows, and APIs. Those features matter when several people need controlled changes or when stock must be connected to builds.

The trade-off is system administration. Part-DB introduces a PHP and Symfony runtime, database configuration, uploaded files, authentication, frontend asset builds, and container or web-server maintenance. A spreadsheet avoids that operational layer. It also lacks Part-DB's structured inventory semantics unless the operator builds disciplined tables, validation, and access control.

Another alternative is a generic asset-management application. Part-DB is more specific to electronic components because its documented fields, parametric search, KiCad integration, BOM import, datasheets, and component providers are centered on hardware inventory. The repository evidence does not establish that it surpasses a general warehouse system for non-electrical assets or procurement workflows.

Release Cadence, Upgrades, and AGPL-3.0 Obligations

The repository is not archived. Its last push was on 2026-10-15, and the listed releases include v2.20.1 on 2026-10-12, v2.20.0 on 2026-10-10, and v2.19.2 on 2026-09-28. This recent release sequence is evidence of ongoing project output, but it does not by itself establish upgrade compatibility or operational support.

The upgrade burden depends on the deployment method. Source installations require attention to PHP dependencies in `composer.json`, JavaScript packages in `package.json`, frontend assets, environment configuration, and Doctrine migrations under `migrations/`. Docker users still need a persistent database and upload strategy, but the image encapsulates PHP, Node.js, and application dependencies. The README does not provide a complete production rollback procedure or a compatibility matrix for upgrades.

The project is licensed under AGPL-3.0, and `package.json` records `AGPL-3.0-or-later` for the package metadata. This matters when deciding whether to operate, modify, or distribute a deployment. Review the repository `LICENSE` and applicable obligations with the responsible legal or compliance owner before redistributing modified code or exposing a network service.

For upgrades, database backups and persistent upload backups are distinct concerns. The repository contains migrations, but migration execution can change application data. The README does not say whether uploads are versioned or how to coordinate a failed migration with an older release, so those operational details must be verified before changing a production instance.

Editorial conclusion

Part-DB is a practical choice for hobbyists, makerspaces, universities, and small organizations that need a structured browser inventory with component metadata and stock tracking. It is a poor fit for users who need a desktop-only application or want deployment without PHP, Node.js, web-server, and database maintenance. Evaluate a release first, starting with the documented database configuration, permission model, and migration path. For a new deployment, verify that `jbtronics/part-db1` produces the expected `public/` web root and `uploads/` behavior, and confirm that AGPL-3.0 is acceptable for the intended distribution before making the project public.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Part-DB/Part-DB-server on GitHub
3. Project website
4. README
5. Releases