Snipe-IT или InvenTree: что выбрать для инструмента, запчастей и ИТ — и как поставить обе системы на одном сервере

Snipe-IT выбирают для того, что выдаётся и возвращается: инструмент, приборы, ИТ-техника. InvenTree — для того, что приходит партиями и расходуется: запчасти, фильтры, масла. Если у вас есть и то и другое, обе системы спокойно работают на одной виртуальной машине в Docker, с общим HTTPS-прокси и единым ночным бэкапом.

Главная разница: штучный учёт ценностей и количественный складской учёт

Запрос «snipe-it или inventree» мы слышим, когда компания уже поняла, что Excel не справляется, и ищет бесплатную систему учёта. На первый взгляд обе системы про одно и то же: каталог, места хранения, штрихкоды, веб-интерфейс, API. На деле они отвечают на разные вопросы, и выбор упирается не в интерфейс, а в то, как ведёт себя сама вещь. Перфоратор возвращается на склад. Тормозные колодки — нет: их ставят на машину, и они исчезают из учёта навсегда.

Snipe-IT построен вокруг единицы. У каждого перфоратора, нивелира, ноутбука есть своя карточка с инвентарным номером, серийником, статусом и историей. Главные вопросы, на которые он отвечает: у кого вещь сейчас, с какого числа, когда обещали вернуть и в каком она состоянии. Выдача и возврат — центральная операция, всё остальное вокруг неё: просрочки, аудит, ремонты, поверка, акт с подписью работника.

InvenTree построен вокруг количества. Деталь в каталоге — это описание товара с артикулом, параметрами и поставщиками, а реальное наличие хранится в складских позициях: «12 штук, партия от 14 октября, полка А-1, по такой-то цене». Одна деталь может лежать в пяти местах, частично ехать от поставщика и частично уже быть списанной на ремонт. Главные вопросы здесь другие: сколько осталось, где лежит, куда ушло и когда заказывать снова.

Отсюда простое правило, которым мы пользуемся на первом созвоне. Если вещь после работы должна вернуться и важно, кто её держал, — это штучный учёт ценностей, и ему место в Snipe-IT. Если вещь приходит партиями, раскладывается по ячейкам и расходуется, — это складской учёт, и его удобнее вести в InvenTree. Подробно о каждой системе — в отдельных материалах: кейс выдачи инструмента приходящим работникам по QR-коду и обзор InvenTree 1.6 для учёта запчастей.

Путаница возникает потому, что обе системы немного заходят на территорию друг друга. В Snipe-IT есть расходные материалы с количеством и минимальным остатком, в InvenTree можно вести серийные детали. Но это вспомогательные функции. Расходник в Snipe-IT числится в одном месте и умеет только «выдать со списанием» и «добавить количество», а серийная деталь в InvenTree не имеет ожидаемой даты возврата и списка должников. Пытаться вести всё в одной системе можно, пока объём небольшой; дальше начинаются костыли.

Snipe-IT vs InvenTree: сравнение по 16 критериям

Ниже — сравнение систем учёта по тем пунктам, которые реально всплывают при внедрении. Таблицу мы собирали не по документации, а по демо-стенду, где обе системы стоят рядом на одной виртуальной машине и заполнены данными, похожими на настоящие: инструмент, измерительные приборы, автозапчасти, несколько складов, машина-мастерская и приходящие работники. Версии — Snipe-IT 8.8.1 и InvenTree 1.6.0.

Самые важные строки — первые четыре. Если вам нужна ожидаемая дата возврата и отчёт «кто до сих пор не сдал перфоратор», InvenTree этого не даст, как его ни настраивай. Если вам нужно знать, что одних и тех же колодок восемь штук на основном складе, три в машине и две едут от поставщика, — Snipe-IT это не покажет: его расходник привязан к одному месту, а приход сводится к увеличению количества без документа заказа.

Про мобильную работу стоит сказать отдельно. У Snipe-IT официального приложения нет: работаете в браузере телефона, QR-код на этикетке открывает карточку актива после входа, ярлык на рабочем столе запускается почти как приложение. Сторонние приложения существуют, но официальными они не являются, и мы их клиентам не ставим. У InvenTree есть официальное бесплатное приложение для Android и iOS: поиск, сканирование, перемещение, приёмка заказа, инвентаризация, фото. При этом веб-интерфейс InvenTree на узком экране прямо предупреждает, что лучше пользоваться приложением, — на смартфоне так и работаем, а на планшете вполне хватает браузера.

Перевод в обеих системах неполный, и это надо учитывать при обучении. В Snipe-IT выдача названа «Привязать», возврат — «Отвязать» или «Вернуть на склад», часть заголовков на панели остаётся английской. В InvenTree непереведённых терминов больше. На практике это решается одной страницей шпаргалки для кладовщика, но ждать полностью русского интерфейса не стоит.

Лицензии разные, и для внутреннего использования обе бесплатны без ограничения пользователей. Snipe-IT распространяется под AGPL-3.0: если вы дорабатываете код и даёте доступ к системе посторонним через сеть, изменения нужно публиковать. Для внутреннего учёта без правок кода это ни на что не влияет. InvenTree — под MIT, самой свободной из распространённых лицензий.

Когда хватит одной Snipe-IT, когда нужен InvenTree, а когда ни то ни другое

Мы не ставим две системы «на всякий случай»: каждая добавляет базу, бэкап, обновления и обучение. Решение принимаем по нескольким признакам, которые выясняем ещё до развёртывания. Подробный список вопросов — в чек-листе перед внедрением учёта инструмента.

InvenTree нужен, если выполняется хотя бы одно из условий:

Одной Snipe-IT хватит, если запчастей несколько десятков позиций и все они лежат на одном складе, а от учёта нужно только «сколько осталось» без истории прихода, цен и поставщиков. Тогда запчасти и мелкие расходники ведутся как расходные материалы Snipe-IT с минимальным остатком, а вся сила системы уходит на инструмент и ИТ-технику. Это частый вариант для офиса с хозяйственной частью или для небольшой бригады.

Пример из практики. Ремонтная мастерская «Винт и Гайка» пришла с вопросом, какую систему выбрать: у них дорогой инструмент, которым пользуются несколько мастеров, и склад запчастей для собственного транспорта. Мы прошли по признакам выше. Инструмент выдаётся и возвращается, иногда задерживается у мастеров на выезде — однозначно Snipe-IT. Запчастей больше полутора сотен позиций, часть возится в машине-мастерской, заказы у нескольких поставщиков — InvenTree оправдан. Сделали вывод в пользу связки двух систем и показали обе на демо-стенде с похожими данными, чтобы решение принималось не по описанию, а по живым экранам.

Ни то ни другое не подойдёт, если учёт должен попадать в бухгалтерию с проводками и первичными документами, если запчасти продаются клиентам с выставлением счетов и НДС или если нужны себестоимость и партионный учёт для отчётности. InvenTree — не бухгалтерская система: в нём нет проводок и первички, связь с 1С делается через API отдельной доработкой. В таких случаях честнее сразу смотреть на 1С или ERPNext — сравнение вариантов мы разбирали в статье какую систему учёта на Linux выбрать, а складскую часть ERPNext — в материале ERPNext: склад, партии и штрихкоды.

Бывает и промежуточный вариант: бухгалтерия живёт в 1С, а оперативный учёт инструмента — в Snipe-IT. Это нормально и даже удобно: 1С не умеет показывать, у какого работника сейчас перфоратор, а Snipe-IT не обязан знать про амортизацию. Важно лишь договориться, какая система главная для каждого вида данных, чтобы не сверять их вручную каждый месяц.

• позиций запчастей больше 100–150, и они регулярно приходят от поставщиков;
• одна и та же деталь лежит на нескольких складах, в машине или на объекте;
• запчасти возят между складами, и нужна история перемещений;
• нужно понимать, что заказывать, у кого и по какой цене брали в прошлый раз;
• детали списываются на конкретную машину или заказ, и потом надо видеть, что куда ушло.

Архитектура связки на одной ВМ: Docker Compose, Caddy, два поддомена

Обе системы прекрасно уживаются на одной виртуальной машине, и для небольшой компании так и правильно: одна точка обслуживания, одна схема защиты, один бэкап. Мы берём Ubuntu 24.04 и ориентируемся на 4 vCPU, 8 ГБ RAM и 60 ГБ диска для связки; если ставится только Snipe-IT, хватает 2 vCPU, 4 ГБ и 40 ГБ. Хостом может быть ваш Windows Server с Hyper-V или наш хостинг. Если сервер на Windows Server 2016, учтите, что его поддержка заканчивается 12 января 2027 года: ВМ с учётом переносится на новый хост целиком, данные при этом не страдают.

Каждая система живёт в своём каталоге со своим docker-compose и своим файлом .env. Snipe-IT — официальный образ и MariaDB. InvenTree — официальный production-стек: сервер, фоновый обработчик задач, PostgreSQL, Redis и собственный прокси Caddy. Базы не смешиваются, общий у систем только внешний прокси. Порядок установки Snipe-IT в Docker мы подробно описывали в инструкции по установке Snipe-IT в Docker, здесь остановимся на том, что меняется при соседстве двух систем.

Главное правило: ни один контейнер не публикует порты на внешний интерфейс. Snipe-IT слушает 127.0.0.1:8081, прокси InvenTree — 127.0.0.1:8082. Снаружи доступен только внешний Caddy на 443, который сам получает сертификаты Let's Encrypt и раздаёт системы по двум поддоменам. Ниже — минимальный Caddyfile в этой схеме.

# /etc/caddy/Caddyfile — внешний прокси на ВМ, сертификаты Let's Encrypt получает сам
tools.example.ru {
    encode gzip
    reverse_proxy 127.0.0.1:8081    # Snipe-IT
}

parts.example.ru {
    encode gzip
    reverse_proxy 127.0.0.1:8082    # InvenTree (его собственный прокси из официального стека)
}

# В docker-compose обеих систем порты публикуются только на петлю:
#   snipe-it:        ports: ["127.0.0.1:8081:80"]
#   inventree-proxy: ports: ["127.0.0.1:8082:80"]

Каждой системе нужно сообщить её внешний адрес, иначе ссылки в письмах, QR-коды на этикетках и перенаправления после входа будут вести не туда. В Snipe-IT это APP_URL в .env, в InvenTree — INVENTREE_SITE_URL и настройка доверенных прокси, чтобы система правильно понимала, что запрос пришёл по HTTPS. Эту ошибку легко пропустить: всё открывается, но QR на этикетке ведёт на внутренний адрес, и ни один телефон его не откроет.

Защита строится одинаково для обеих систем. На роутере открывается только порт 443 на ВМ; SSH доступен только из нашей сети управления или через VPN. Для администраторов включается двухфакторный вход по одноразовому коду, против перебора паролей ставится блокировка после серии неудачных попыток. Если белого IP нет, работаем через VPN или туннель. Кладовщику и работникам даём минимальные права: в Snipe-IT — без удаления и администрирования, в InvenTree — через роли группы, где можно смотреть и перемещать, но не удалять.

QR-коды на этикетках обеих систем ведут на ваш домен, поэтому стоит заранее подумать о подмене этикеток. Чужая наклейка поверх вашей может отправить сотрудника на фишинговую страницу входа — о том, как это выглядит, мы писали в статье про фишинг через QR-коды. Для ценного инструмента помогают VOID-этикетки, а работникам достаточно правила: страница входа в учёт открывается только на поддомене компании.

Бэкап обеих баз: что копировать и как проверить восстановление

Резервная копия связки — это не только две базы. Без файла .env Snipe-IT не расшифрует часть данных и не запустится с прежним ключом приложения, без медиа InvenTree пропадут фото деталей и вложения, без папки storage Snipe-IT — фото активов и подписанные акты. Поэтому ночной бэкап у нас состоит из четырёх частей: дамп MariaDB, дамп PostgreSQL в формате custom, файлы загрузок обеих систем и оба файла .env.

#!/bin/bash
# /usr/local/bin/uchet-backup.sh — запускается cron'ом ночью
# Имена контейнеров, баз и путей подставьте из своих compose-файлов
set -euo pipefail
ROOT=/opt/backups/uchet
D="$ROOT/$(date +%F)"
mkdir -p "$D" && chmod 700 "$ROOT"

# Snipe-IT: логический дамп MariaDB
docker exec snipeit-db sh -c 'mariadb-dump -uroot -p"$MYSQL_ROOT_PASSWORD" --single-transaction --databases snipeit' \
  | gzip > "$D/snipeit.sql.gz"

# InvenTree: дамп PostgreSQL в формате custom (восстанавливается через pg_restore)
docker exec inventree-db sh -c 'pg_dump -U "$POSTGRES_USER" -Fc "$POSTGRES_DB"' > "$D/inventree.dump"

# Файлы: загрузки и фото Snipe-IT, медиа InvenTree, оба .env (без них дамп не поднять)
tar czf "$D/files.tar.gz" /opt/snipeit/storage /opt/inventree/inventree-data/media \
  /opt/snipeit/.env /opt/inventree/.env

# Ротация: храним 7 дней, затем копия вне сервера
find "$ROOT" -mindepth 1 -maxdepth 1 -type d -mtime +7 -exec rm -rf {} +
rsync -a --delete "$ROOT/" backup@offsite.example.ru:/srv/uchet/

Скрипт ставится в cron на ночное время, когда в системах никто не работает, каталог с копиями закрывается правами 700, ротация — семь дней на сервере. Копия вне сервера обязательна: если хост выйдет из строя вместе с диском, локальные бэкапы погибнут вместе с ним. Файлы .env содержат пароли баз и ключи приложений, поэтому внешнее хранилище тоже должно быть закрытым, а не общей сетевой папкой.

Бэкап, который ни разу не восстанавливали, — это надежда, а не бэкап. При сдаче системы мы поднимаем обе копии на чистой тестовой ВМ: MariaDB — из sql-дампа, PostgreSQL — через pg_restore в пустую базу, затем распаковываем файлы, кладём .env и проверяем, что открываются карточки, фото, история выдач и остатки по местам. Повторять такую проверку стоит после каждого крупного обновления, особенно InvenTree, где между версиями меняется структура базы.

Отдельно стоит подумать о снапшотах ВМ на уровне гипервизора. Они удобны перед обновлением — откатиться можно за минуту, — но не заменяют логические дампы: снапшот живёт на том же хранилище, а восстановить из него отдельную таблицу или перенести данные на другую версию нельзя. Мы делаем снапшот перед обновлением и удаляем его после проверки, а постоянной защитой остаются ночные дампы.

Что где учитываем без дублирования: инвентарные номера и этикетки

Самая частая ошибка при связке двух систем — заводить одну и ту же вещь в обе. Перфоратор оказывается и активом Snipe-IT, и деталью InvenTree «на всякий случай», через месяц цифры расходятся, и никто не знает, какой системе верить. Поэтому до наполнения мы фиксируем на одной странице: какой вид ценностей в какой системе живёт, и ни одна позиция не числится в двух местах.

Мелкие расходники — свёрла, биты, диски, электроды, перчатки — вызывают больше всего споров. Наш вариант по умолчанию: если они выдаются работникам вместе с инструментом и важен только минимальный остаток, оставляем их расходными материалами в Snipe-IT, рядом с инструментом. Кладовщик работает в одной системе, выдача идёт с тем же списком работников. Если же метизы и расходники закупаются у нескольких поставщиков, лежат по ячейкам и их сотни позиций, переносим их в InvenTree, а Snipe-IT оставляем только возвратное. Главное — решить один раз и записать.

Работники и места хранения в двух системах неизбежно дублируются, и это нормально: справочник людей в Snipe-IT нужен для выдачи, в InvenTree — для прав доступа и истории. Названия мест держим одинаковыми — «Склад №1 / стеллаж B», «Машина-мастерская» — чтобы кладовщик не путался, где какой склад. Если людей много, их можно синхронизировать через API обеих систем или из Active Directory; приёмы описаны в статье про интеграции Snipe-IT с AD, API и Excel.

Инвентарные номера разводим префиксами, чтобы по этикетке сразу было видно, какая система её напечатала. Например, INS-000123 — инструмент в Snipe-IT, IT-000045 — компьютерная техника там же, ZP-04417 — внутренний артикул запчасти в InvenTree. Сканер или камера всё равно прочитают код, но человеку на складе префикс подсказывает, в какую систему идти. Номера не переиспользуются: списанный перфоратор уносит свой номер с собой.

Этикетки печатаются на одном и том же принтере. Для инструмента, который живёт в масле, грязи и на морозе, берём термотрансферную печать на полиэстере: бумажная термоэтикетка на перфораторе быстро перестаёт читаться. Для коробок и полок с запчастями хватает обычной термобумаги. В Snipe-IT этикетка формируется встроенным движком, в InvenTree — по HTML-шаблону, мы сделали размер 58×40 мм для детали и места. Удобные размеры для обеих систем — 30×20, 40×25 и 58×40 мм. Подробно о принтерах, материалах и мелочи вроде свёрл — в материале об этикетках и принтерах для маркировки инструмента.

На скриншотах ниже видно, как одни и те же места выглядят в двух системах: в Snipe-IT это склады и машина-мастерская со счётчиками активов, в InvenTree машина-мастерская — обычное место хранения с возимым запасом мастера, разбитым по партиям.

Обслуживание, обновления и риски связки

Две системы — это два цикла обновлений. Snipe-IT выпускает версии часто, обновление в Docker сводится к загрузке нового образа: миграции базы выполняются при старте контейнера. В InvenTree после загрузки образа обязательно выполнить шаг обновления, который применяет миграции и собирает статические файлы. Если его пропустить, веб-интерфейс встретит ошибкой — на стенде мы поймали это сами, когда понадеялись на автоматическое обновление.

# Snipe-IT: новый образ, миграции выполняются при старте контейнера
cd /opt/snipeit && docker compose pull && docker compose up -d

# InvenTree: новый образ, затем миграции и сборка статики
cd /opt/inventree && docker compose pull
docker compose run --rm inventree-server invoke update
docker compose up -d

Порядок обновления у нас всегда одинаковый: снапшот ВМ, свежий бэкап, чтение заметок к релизу, обновление одной системы, проверка ключевых операций, только потом вторая система. Мажорные версии не ставим в первую неделю после выхода — даём время выйти исправлениям. Регламент эксплуатации Snipe-IT с периодичностью проверок мы публиковали в статье о регламенте эксплуатации Snipe-IT, для InvenTree он устроен так же.

Грабли, которые встретились при сборке стенда, полезно знать заранее. В Snipe-IT 8.8 после создания администратора из консоли может не появиться запись настроек, и система бесконечно отправляет на страницу первичной настройки. Для работы API нужно сгенерировать ключи авторизации, лимит по умолчанию — 120 запросов в минуту, и при массовой загрузке его стоит поднять параметром API_THROTTLE_PER_MINUTE. Архивные активы API не отдаёт без фильтра по статусу — при выгрузке легко потерять часть списка. В InvenTree пользователю нужен профиль, права выдаются через роли групп, а API-токены создаются через интерфейс или API, а не напрямую в базе.

Главные риски связки — организационные. Первый — дублирование учёта, о нём сказано выше. Второй — один человек, который понимает обе системы: если он уходит, никто не знает, где что. Решается короткой инструкцией и вторым обученным сотрудником. Третий — отсутствие мониторинга: система может неделю лежать после сбоя, а заметят это, когда понадобится выдать инструмент. Мы ставим простую проверку доступности обоих поддоменов и контроль, что ночной бэкап действительно создан и имеет разумный размер.

Четвёртый риск — ожидания. InvenTree не заменит бухгалтерию, Snipe-IT не станет складской программой, и ни одна система не сработает, если инструмент выдаётся «на минутку» без отметки. Учёт держится на привычке: этикетка на каждой вещи, скан при каждой выдаче, раз в неделю взгляд на список просрочек и минимальных остатков. Технически связка поднимается за несколько дней, а привыкание персонала занимает дольше — поэтому мы начинаем с пилота на одном складе.

Если вам нужна помощь с выбором или с развёртыванием, мы занимаемся учётом ИТ-имущества в Snipe-IT и складским учётом на open source, а саму связку ставим в рамках услуги внедрение open-source систем.

Частые вопросы