Binner: a self-hosted parts inventory for makers and electronics hobbyists

What problem Binner solves and who it is for

Binner is a free open source parts inventory tracking system you can run locally in Windows or Unix environments, created for makers, hobbyists and professionals to keep track of their parts inventory.

The motivation given is unusually concrete. The author could not find good free alternatives for tracking inventory in a home maker lab, it is easy to forget what was bought and where it was put, and the result is sometimes ordering things that are already on the shelf. The stated payoff is saving money and time.

That problem is specific to electronics, and the project says so while acknowledging it is not limited to it. Binner is designed for electronics in mind, but it could be used for other kinds of inventory management, chemistry and retail being the examples given. It is purpose built for quick data entry and fast performance, and those two goals explain a lot of the design.

The domain fit shows up in the integrations. Parts can be imported from orders placed with Digikey, Mouser and Arrow, and parts are looked up automatically across Digikey, Mouser, Arrow, Octopart, Nexar and TME. Datasheets are retrieved and searched automatically, there is a dedicated datasheet repository, a schematics repository for example circuits per part, and local upload of datasheets and images. There is KiCad HTTP Library support and a TME parts API integration.

The tool is written in C# on .NET Core with a React front end, and it runs on Windows, Unix and embedded devices such as the Raspberry Pi. The project is GPL-3.0 licensed, the last push was on 2026-04-18, and the recent releases are v2.6.23 from 2026-02-17, v2.6.24 from 2026-03-21 and v2.6.25 from 2026-03-22. The home page is binner.io.

The feature list, and what it says about the audience

The feature list is short and every item points at a physical workflow rather than at a generic inventory concept.

There is standard inventory management input, customisable nested category placement so you can organise parts however your drawers are organised, and parts tracked by Project. There is a flexible search engine, and export to CSV or Excel if you need to get the data somewhere else. Custom fields can be added to your data, which is how you record the things a generic part record does not have, like which cell of which bin a component is in.

The physical side is the distinctive part. Barcoding support means you can print a label, stick it on the part bag and scan it rather than typing a part number. Label printing is the companion feature, and the two together are what turn an inventory system into something you actually use at the bench. There is a KiCad HTTP Library integration, so a schematic can pull a part straight from your inventory, and full BOM and PCB management is on the completed list for 2025.

Then the two features that make it feel like an application rather than a spreadsheet. The app is a simple web-based UI, and it requires no web server installation because it uses a standalone Kestrel service API. That last point matters for the deployment story, since Kestrel is the .NET web server and a standalone Kestrel host means the application is a self-contained process that serves its own UI.

The completed feature list for 2025 also includes multiple language support, auto update, local upload of datasheets and images, and the Arrow and TME API integrations. Two items remain unchecked: electronic bins support, and a speculative parts marketplace.

One line in the feature list is worth reading carefully. Import your orders from Digikey, Mouser, Arrow, or AliExpress, with the AliExpress struck through. The project removed that integration, and the strikethrough is left in place, so the current state is three distributor order imports rather than four.

Installing on Ubuntu or Raspberry Pi OS from a release archive

The Linux install is a release archive, and the two documented platforms differ only in the archive you download.

On Ubuntu you download the ubuntu.14.04-x64.tar.gz from the latest release, and on Raspberry Pi OS it is the linux-arm.tar.gz. The extracted archive contains the application and an install script, and the sequence is the same on both:

// extract the archive
tar zxfp ./Binner_ubuntu.14.04-x64-VERSION.tar.gz

// to install as a service
sudo chmod +x ./install-as-service.sh
sudo ./install-as-service.sh

// or you can just run directly
sudo chmod +x ./Binner.Web
./Binner.Web

On Raspberry Pi OS the archive name changes and the extraction line is slightly different, because the archive is not prefixed with a path:

// extract the archive
tar zxfp Binner_linux-arm-VERSION.tar.gz

// to install as a service
sudo chmod +x ./install-as-service.sh
sudo ./install-as-service.sh

// or you can just run directly
sudo chmod +x ./Binner.Web
./Binner.Web

The two choices are a systemd service or a foreground process, and the documentation gives both, which is the right call because a maker running it on a Pi under a desk will want the service and a person debugging a part lookup will want the console output in front of them.

Note the archive naming. The Ubuntu build is still labelled ubuntu.14.04-x64 while the project itself targets modern .NET, so the filename is a build label inherited from earlier releases rather than a statement of the required distribution. If you are on a current Ubuntu, that is a cosmetic inconsistency rather than a problem.

For other Linux platforms the project points at a wiki page on installing on Linux.

The Docker route is the other cross-platform option, and the project is explicit that Docker is best configured with `docker compose`, with full details at Docker Hub and in the official wiki. The image is published as binnerofficial/binner, and a container can be started with `docker run --name Binner -d binnerofficial/binner:latest`. The Docker Hub badge in the project description tracks the image version, and there is a separate badge for the GitHub release, which is the distinction between the published image and the published build.

Running on Windows, and the default credentials you must change

The Windows install is an installer from the latest release, and the application can run either as a standalone console application or as a Windows service.

For the service route, the documentation says to run the following in an administrative console:

.\Binner.Web install
.\Binner.Web start

Other commands are available to manage the service, and the ones named are `uninstall`, `stop` and `help`. The console application route is a single command, running the executable directly.

The web interface is then at https://localhost:8090. The https scheme is worth noting, because it means the local instance is served over TLS rather than plain http, which is a sensible default when the same application can be exposed on a network.

Then there is the login, and this is the part to get right. The first time you log in you are prompted for a username and password, and the default credentials are admin and admin for both.

This is a genuine risk in a self-hosted application, and it is worth being blunt about it. The application holds a parts inventory, supplier order history and datasheets, and it ships with a known username and password that the documentation prints in plain text. Anyone who can reach the web interface on your network can try it. So the first thing to do after the first login is change that password, and if you are exposing the instance beyond your own machine, do it before you do anything else.

The project also publishes a hosted free online version at binner.io, which offers free and paid subscriptions based on inventory size requirements and additional features, and the author says it helps keep the project alive. That is a reasonable arrangement for a self-hosted project that needs a demo and a revenue line, and it also means you can look at the interface before committing to a local install.

Storage providers, the paid tier and the user cap

Binner supports multiple storage providers, and the section on that is truncated in the project description, so the details of the list are not visible. What is visible is the feature list entry, which describes a proprietary file-based database, or the use of providers for other formats such as SQL Server.

That default is a genuine design choice rather than a shortcut. A parts inventory for a single maker is a modest amount of data, and a file-based store means the whole application is a folder you can copy, back up and restore without a database server. It also means the failure modes are file permission problems rather than connection string problems, which is the right trade for a Raspberry Pi on a maker's desk.

The limitation is the paid tier, and the project is straightforward about it. The free open source version includes as many features as possible, and additional features and limitations are released behind a paid license to fund continued work on the project. The one limit listed explicitly is a maximum of three users, with additional users available by a subscription.

Three users is a small cap and it is the right metric for the project's audience. A home maker lab is one person. A small team sharing a parts store is three. A company with a purchasing department is not the target, and the subscription model makes that boundary explicit rather than leaving you to discover it through a feature that quietly stops working at the fourth login.

The commercial service at binner.io prices on inventory size requirements and additional features, which is a different axis from the self-hosted edition. That is a sensible split, because the self-hosted edition's limits are about the app and the hosted edition's are about the data volume.

For a deployment, the practical checklist is short. Decide the storage provider before you import your first order, because switching providers later means a migration. Then change the default credentials. Then set up the barcode and label workflow, because that is the feature that determines whether people actually enter parts into the system or let it drift out of date.

Where Binner is the wrong choice

The first limit is the user cap and the direction of the project. The free version is capped at three users and the paid features are enabled by subscription, which is a sustainable arrangement for a hobby project but a poor fit for an organisation that wants to run a parts inventory for a whole engineering department. The more users you have, the more you are depending on the maintainer's commercial roadmap.

The second limit is the scope of the domain model. Binner is a parts inventory, not a product lifecycle management system. There is no purchasing workflow, no requisition process, no supplier quote comparison, no cost accounting across projects and no shortage forecasting. Projects are a way to group parts, and that is all. A team that needs to know what it is spending on electronics and who approved it is looking for a different category of software.

The third is the distributor coverage. Order import works for Digikey, Mouser and Arrow, and part lookup covers those plus Octopart, Nexar and TME, with AliExpress removed. The distributors that are not on that list, most of the smaller regional ones and most of the component marketplaces, are simply not part of the workflow. The same applies to the manufacturer side, where a parts database like Octopart or Nexar is a best-effort source of manufacturer part numbers rather than an authoritative catalogue.

The fourth is the maturity of the platform story. The application runs on .NET Core and Windows, Unix and embedded devices, and the Raspberry Pi path is a supported build rather than an afterthought, but a shared lab inventory on a Pi on the same network as a build server is a different reliability question from a hosted service.

Compare that with a hosted parts management service, or with a spreadsheet plus a barcode phone app. The difference in approach is that the spreadsheet is free, needs no server, and everyone already knows how to use it, and it will also fall out of date the moment nobody updates it, which is the problem Binner exists to solve. Binner answers that with an application that imports your orders automatically so the inventory stays current without anyone typing anything, and you pay for that with a GPL-3.0 codebase you have to run, keep patched and keep backed up.

Licence, community and what to check before your first import

Binner is released under GPL-3.0, with the LICENSE file in the repository root. For a self-hosted internal tool, that licence is straightforward, since you are not distributing the application. It does matter if you intend to modify it and offer the modified version to others, because the copyleft obligation travels with the derived work.

The repository layout is small and tells you how the build works. There is a `Binner/` directory holding the application, a `Scripts/` directory, a `build-local.ps1` PowerShell script for building on Windows, an `appveyor.yml` for the CI configuration, and the `.github/` directory. The build badge in the project description points at an AppVeyor project, so the continuous integration runs on Windows, which is consistent with the .NET and Windows-first nature of the application and with the fact that the Raspberry Pi and Linux builds come from release archives rather than from a Linux CI pipeline.

Help comes through several channels, and the project distinguishes them. For a question or an installation problem you have two options, a post in Discussions or the Discord server for a more real-time response. For a bug report or a feature suggestion, you create a new issue.

What to check before your first import is a short list. Change the admin password from the default before anything else, since the interface is reachable on port 8090 over https. Then run a small import, one Digikey order, and confirm the part records, the datasheet links and the category structure all came across as you expected, because the importer is the part of the system most likely to need tuning for your suppliers' order formats.

Then set up the physical workflow, because an inventory system that people do not update is worthless. Print labels, stick them on the bins, and wire up the barcode scanner. The custom fields are worth configuring early as well, since they are how you record the bin and cell a part lives in, and retrofitting that onto a few hundred existing records is more work than starting with it.

Finally, if you are deploying for more than one person, check the three-user limit before you onboard anyone, because the workaround for it is a subscription and not a configuration change.

Editorial conclusion

Binner fits a maker or small engineering team that keeps thousands of parts in labelled bins, buys from the major distributors, and wants its inventory and its datasheets on its own machine rather than in a spreadsheet. It does not fit a multi-user production environment, because the free version is capped at three users with more available by subscription, and it does not fit a team that needs a full product lifecycle system with purchasing workflows and cost accounting. Before you deploy it, change the default admin credentials on first login, decide on a storage provider since the built-in one is file based, and check whether the paid tier adds anything your workflow actually needs, because the free edition is where the bulk of the functionality lives.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. replaysMike/Binner on GitHub