Open QuarterMaster 6.5.0 介绍与选型指南

Open QuarterMaster 自托管仓储管理系统的能力画像、组件架构与版本节奏，及对 Snipe-IT/InvenTree/Part-DB 的量化选型对比（2026-10-24 实查）。

Open QuarterMaster库存管理自托管2026/10/24

Open QuarterMaster 6.5.0 介绍与选型指南

在"自托管库存管理"这个赛道上，常见的开源答案大多是资产管理（给设备建档、扫码、领用退回）或零部件库（给元器件建 BOM、管耗材）。如果你要管的是真正意义上的仓储流水——物品放到哪个货架、什么时候入了多少、出了多少、谁动的手、库存会不会过期——Open QuarterMaster（下文简称 OQM）是少数把这个问题当成核心来设计的开源系统。

本文基于 2026-10-24 对官方仓库与官方文档的实查，并结合一次完整的部署与 API 实测（本地模拟真实服务器完成 Core API 全链路调用），给出 OQM 的能力画像与选型对比。

一、OQM 是什么

Open QuarterMaster 是一个开源、自托管的库存/仓储管理系统，官方口号是 "Inventory without a catch, and all the hooks"——不带任何隐藏代价的库存系统，且处处留有钩子。项目由 Epic Breakfast Productions 于 2021 年启动，采用 GPL-3.0 许可证，代码托管在 GitHub（Epic-Breakfast-Productions/OpenQuarterMaster），官网 openquartermaster.com 提供在线演示（openquartermaster.com/public/demo）。

它的设计目标非常明确：一套系统，从家用物品清点，一直扩展到仓库与配送中心的库存作业。为此 OQM 采用了模块化架构：

组件角色技术栈
Core API核心枢纽，所有库存数据的唯一权威来源（source of truth），提供 REST APIJava / Quarkus
Base Station官方 Web 前端（库存浏览、入库/出库操作、附件管理）Quarkus + 前端打包（以 host 网络方式对外服务）
Station Captain单机部署/更新管理器，负责拉起整个栈、证书、快照备份Python 3 CLI（oqm-captain 命令）
插件（Plugins）独立进程，通过 Kafka 与 Keycloak 接入，扩展出按需功能不限语言，Docker 镜像分发

官方内置插件有 External Item Search（跨外部站点搜索物品，v2.3.0）、Storagotchi（物品存放交互）、File Server（文件存储服务）等；基础设施组件包括 MongoDB（库存主存储）、PostgreSQL（Keycloak 专用库）、Keycloak（OIDC 认证/SSO）、Traefik（反向代理统一入口）。

一个值得注意的设计：OQM 原生支持多个库存数据库（multi inventory DB）。所有核心 API 都挂在 /api/v1/db/{oqmDbIdOrName}/ 路径下——你可以为"家用"“公司仓库”“代管资产"分别开独立的库存库，彼此数据隔离，但在同一个 OQM 实例里管理。实测中，部署完成后的默认库存库就叫 default。

二、核心能力清单

以下能力均经官方文档溯源或实测确认：

  • 物品与存储模型：物品（Item）挂在存储块（Storage Block）下，存储块支持箱子（BOX）、货架（SHELF）、房间（ROOM）、托盘（PALLET）、储物柜（CABINET）等多种类型，且存储块之间可以嵌套——"仓库 → 房间 → 货架 → 料盒"的层级可以原样建模。
  • 库存事务流水：入库（ADD_AMOUNT / ADD_WHOLE）、出库（CHECKOUT_AMOUNT / CHECKOUT_WHOLE）、盘点设定（SET_AMOUNT）、转移（TRANSFER_AMOUNT / TRANSFER_WHOLE）、以及带损耗的 CHECKIN_PART / CHECKIN_LOSS，共 12 种事务类型。每一次事务都是一条不可变流水，记录操作实体与时间戳——这是它与"改一个数字就完事"的简单库存工具的本质区别。
  • 过期与低库存告警：物品可设过期时间与低库存阈值，事务应用后系统即时返回 postApplyResults 告警结果。
  • 附件与图片：物品与存储块都可以挂文件附件与图片，官方 File Server 插件支撑大文件存储。
  • 标签/条码打印：物品自带 ID 生成器（idGenerators）与标签格式（labelFormat），配合内置的标签打印能力（Base Station 支持 Zebra ZPL 等）。
  • 多用户与细粒度角色：认证走 Keycloak（OIDC/JWT），新建用户默认即带 inventoryView / inventoryEdit / itemCheckout / inventoryAdmin 等角色组（实测确认）。
  • 快照备份：Station Captain 内置快照体系，支持手动/计划/抢占式快照、xz/gz/bz2 压缩、对称加密备份、本地/SSH/对象存储三种备份方式。
  • 隐私立场：官方明确表示系统不会回传遥测数据（phone home 的只有 Station Captain 检查 Git 仓库更新这一个动作）。

三、版本节奏与组件版本策略（2026-10-24 实查）

OQM 的组件各自独立发版，Release 命名形如 core-api-6.5.0、core-base+station-1.21.3、manager-station+captain-2.13.1。2026-09-28 官方同日发布了一整套互相配套的版本：

组件最新版本发布日期
Core API6.5.02026-09-28
Core Base Station（前端）1.21.32026-09-28
Station Captain（管理器）2.13.12026-09-28
插件 External Item Search2.3.02026-09-28
基础设施打包（traefik/postgres/mongodb/keycloak）1.1.1 / 1.2.6 / 1.2.6 / 2.0.32026-09-28

这套版本号就是 2026-10 当前的稳定组合，本文其余各篇的实测均基于此组合（Core API 6.5.0 + Base Station 1.21.3）。

四、量化选型对比

选库存系统最容易犯的错误是拿资产管理工具去干仓储的活。下表把 OQM 放进自托管库存赛道里横向比一轮，数据均取自 shields.io 徽章与各官方仓库（查询日期 2026-10-24）：

维度Open QuarterMasterSnipe-ITInvenTreePart-DB
GitHub Stars（shields.io 实查）7715.0k7.81k1.82k
最新版本（实查）core-api 6.5.0v8.8.3v1.6.1v2.20.2
最近一次提交2026-09（当月活跃）2026-10-23（前一日）2026-10-24（当日）2026-10-19
许可证GPL-3.0AGPL-3.0MITGPL-3.0
定位仓储事务流水 + 多库存库IT 资产管理（资产建档、领用、审计）零部件库存 + BOM 管理电子元件库（器件参数、数据手册）
技术栈Java/Quarkus + MongoDB + PostgreSQL + KeycloakPHP/Laravel + MySQL/MariaDBPython/Django + PostgreSQL + 前端 VuePHP/Symfony + MariaDB/PostgreSQL
部署形态官方 deb 仓库 + Station Captain 一键部署；官方 Docker 镜像（Core API/Base Station/各基础设施组件）官方 Docker 镜像，另有 installer 脚本官方 Docker Compose，单体镜像官方 Docker 镜像，单体镜像
数据模型核心事务流水（12 种事务）+ 存储层级 + 过期/低库存资产（Asset）+ 许可/配件/耗材零件（Part）+ 库存位（StockItem）+ BOM元件（Part）+ 类目树 + 脚注参数
认证Keycloak（OIDC/SSO，独立认证域）内置用户体系 + LDAP/OAuth内置用户体系 + SSO（付费版更全）内置用户体系
APIREST + OpenAPI 规范端点（实测 /q/openapi 可得完整规范）REST API 完善，社区生态成熟REST API 完善 + Python 客户端REST API
适合谁真实仓储作业：有货架层级、出入库流水、过期管理诉求；需要数据隔离的多库场景管公司 IT 资产、设备、许可证的团队硬件创客/电子厂：零件、BOM、采购联动电子工程师个人/小团队：元件参数库

怎么选，一句话版：

  • 管公司电脑、服务器、办公设备谁领用了 → Snipe-IT（资产管理的成熟答案，社区最大）。
  • 管研发物料、BOM、采购到生产 → InvenTree（零件-BOM 生态最顺）。
  • 个人/小团队管元器件参数与库存 → Part-DB（轻、专）。
  • 管一个真仓库：货架在哪里、什么货、多少个、何时入何时出、是否过期 → Open QuarterMaster（事务流水与存储层级是四者中最完整的仓储模型）。

需要客观指出的风险：OQM 的社区体量与 Snipe-IT/InvenTree 相差两个数量级（77 vs 15000+ stars），issue 响应与生态集成（现成的 ERP/IM 打通）远不如头部项目丰富；其架构自带 MongoDB + PostgreSQL + Keycloak 三件套，资源占用与运维复杂度高于单体应用型选手。它适合的是"仓储模型对、数据主权在手"优先级高于"生态最热"的团队。2026 年官方仍在稳定发版（最近一套 2026-09-28），Discord 社区活跃，项目并未停摆。

五、部署与上手成本

OQM 官方把"单机部署"做成了一等公民：提供 Station Captain（oqm-captain 命令行管理器），通过官方 deb 仓库安装后，一条命令拉起整套栈（含 MongoDB/PostgreSQL/Keycloak/Core API/Base Station），后续更新、证书、快照都由它管理。对希望精细控制的用户，官方同时提供 Compose 编排文件（官方标注为本地/非生产探索用途）与 Kubernetes 部署路径。

实测环境最低门槛：官方要求 2 GiB 内存起步（实测全栈冷启动峰值约 2.5 GiB 量级），需要支持 AVX 指令集的 CPU（MongoDB 6.x 的硬性要求，老旧虚拟化平台要注意）。

具体安装步骤、目录布局与首次配置，见部署篇；配置项逐条说明见配置篇；REST API 实操见 API 实战篇。

本专栏其他文章

参考来源