Сколько RAM нужно для HomeBox

MAATRIX

Когда переносишь учёт домашнего имущества из блокнота или таблицы в HomeBox, первый практический вопрос — какой сервер под это брать, чтобы не переплачивать за гигабайты RAM, которые никогда не понадобятся. Ниже — честный разбор аппетитов HomeBox: сколько памяти он ест в простое, от чего расход растёт, и какую конфигурацию брать под личный архив, а какую — под общий инвентарь на всю семью с кучей фотографий.

Что такое HomeBox и почему он лёгкий

HomeBox — это self-hosted приложение для инвентаризации домашнего имущества: что где лежит, сколько стоило, когда куплено, где чек и когда заканчивается гарантия. По архитектуре это один бинарник на Go, который отдаёт и API, и собранный фронтенд на Vue, плюс SQLite как база данных по умолчанию. Никакого отдельного веб-сервера, никакого PHP-FPM, никакого Node.js-рантайма рядом — всё внутри одного процесса и одного Docker-образа.

Это принципиально другая история по сравнению с приложениями на связке "PHP + MySQL + Redis + очередь" или Java-сервисами на Spring, где JVM сама по себе резервирует сотни мегабайт под кучу. Go-бинарник запускается, выделяет память под свои структуры и почти не растёт в простое — сборщик мусора в Go агрессивно возвращает неиспользуемую память операционной системе.

Сколько RAM ест HomeBox в простое и под нагрузкой

Если ориентироваться на характер приложения (Go + SQLite, без JVM и без тяжёлых фреймворков), реалистичные цифры выглядят так — это ориентир, а не гарантированный бенчмарк, у вас на конкретном железе и версии образа цифры сдвинутся на десятки мегабайт в любую сторону:

• Сразу после старта, пустая база: контейнер обычно укладывается в 40-80 МБ RSS. Основную часть съедает сама Go-рантайм и загруженный в память индекс SQLite.
• Простой с несколькими сотнями позиций и без активных запросов: прибавка небольшая, в пределах 20-50 МБ — SQLite держит часть страниц базы в кэше, но агрессивно их не разрастает.
• Активная сессия — просмотр списков, загрузка фото, экспорт в CSV: кратковременные всплески до 150-250 МБ, пока идёт обработка изображений (создание превью) и сериализация JSON-ответов.
• Несколько параллельных пользователей (например, вся семья одновременно листает каталог с телефонов): пики могут доходить до 300-400 МБ, если совпадают загрузка фото и тяжёлые списочные запросы.

Важная оговорка: HomeBox не публикует официальных бенчмарков по памяти, а у проекта были смены мейнтейнеров и заметные изменения в коде между версиями, поэтому относитесь к этим числам как к порядку величины, а не к точной спецификации.

От чего реально растёт потребление памяти

RAM для HomeBox зависит не от "количества функций", а от четырёх конкретных факторов:

1. Число позиций (items) и связанных сущностей. Каждая локация, категория, ярлык и позиция — это строки в SQLite. Тысячи позиций для SQLite не проблема ни по диску, ни по памяти: движок не грузит всю базу в оперативку, а читает нужные страницы по запросу.
2. Объём и обработка фотографий. Это главный потребитель. Каждая загрузка фото — это чтение файла в память, возможно создание thumbnail, запись на диск. Если вы одновременно загружаете партию из 20-30 фото (например, фотографируете содержимое кладовки), кратковременный пик памяти будет заметно выше, чем в обычном просмотре.
3. Одновременные пользователи и открытые сессии. Каждый активный HTTP-запрос держит в памяти буферы на время обработки. Для домашнего использования на 2-5 человек это несущественно, но если вы решите открыть инвентарь общине или небольшому офису на 20+ человек — тут уже нужен запас.
4. Размер вложений (чеки, PDF-инструкции, гарантийные талоны). HomeBox позволяет прикреплять файлы к позициям. Сами файлы лежат на диске в volume, но при загрузке и скачивании проходят через память процесса.

Что почти не влияет на RAM: количество зарегистрированных пользователей само по себе (пока они не онлайн одновременно), длина текстовых описаний, число тегов и локаций как таковых.

Минимальная конфигурация для личного использования

Для одного человека или пары, которые ведут учёт вещей в квартире без фанатичной фотофиксации каждого предмета, с запасом достаточно 512 МБ - 1 ГБ RAM, выделенных под сам HomeBox. Пример docker-compose с явным лимитом памяти — полезно задавать его сразу, чтобы контейнер не мог случайно вытеснить из памяти что-то ещё на сервере (подробнее про лимиты в статье про ограничение CPU и памяти в Docker):

services:
  homebox:
    image: ghcr.io/sysadminsmedia/homebox:latest
    container_name: homebox
    restart: unless-stopped
    environment:
      - HBOX_LOG_LEVEL=info
      - HBOX_WEB_MAX_UPLOAD_SIZE=10
      - TZ=Europe/Moscow
    ports:
      - "7745:7745"
    volumes:
      - homebox-data:/data
    deploy:
      resources:
        limits:
          memory: 512M
        reservations:
          memory: 128M

volumes:
  homebox-data:

На VPS с 1 ГБ RAM такой контейнер спокойно живёт вместе с systemd, sshd и Docker-демоном — на систему обычно уходит 150-250 МБ, остальное свободно под сам HomeBox и файловый кэш ОС, который SQLite активно использует для ускорения чтения.

Конфигурация с запасом: семья, много фото, общий доступ

Если инвентарь ведёт вся семья, вы фотографируете каждую вещь (что резко упрощает поиск "а это у нас вообще есть?"), и база растёт до тысяч позиций с гигабайтами вложений — берите 1,5-2 ГБ RAM. Дело не столько в том, что HomeBox постоянно жрёт эти два гигабайта, сколько в запасе на пиковые нагрузки: массовую загрузку фото, экспорт полной базы в CSV/JSON для бэкапа, одновременную работу нескольких человек в вечерние часы.

Таблица для ориентира по сценариям:

Если на том же сервере крутится ещё и обратный прокси (Caddy или Nginx перед HomeBox для HTTPS), закладывайте дополнительно 50-100 МБ — сами по себе они лёгкие, но с TLS-терминацией и несколькими доменами едят чуть больше в момент установки соединений.

Хранилище фото и вложений растёт независимо от RAM — это вопрос диска, а не памяти. Стоит сразу продумать, куда HomeBox складывает /data: на выделенный VPS volume или на отдельный диск, чтобы не упереться в место на системном разделе. Про то, какой тип хранилища выбрать под такие сценарии, — в статье про типы Docker volumes.

Как замерить реальное потребление и не гадать

Вместо того чтобы ориентироваться на чужие цифры, проще снять метрики со своего инстанса за неделю обычного использования:

# Разовый снимок по всем контейнерам
docker stats --no-stream

# Только по HomeBox, обновление раз в 2 секунды
docker stats homebox

# Пиковое потребление за время работы контейнера (RSS в байтах)
cat /sys/fs/cgroup/memory.peak 2>/dev/null || \
  docker exec homebox cat /proc/1/status | grep VmRSS

Если контейнер жёстко упирается в лимит и Docker начинает его убивать OOM-киллером, в логах docker inspect homebox --format='{{.State.OOMKilled}}' вернёт true — это сигнал поднять лимит на 256-512 МБ и пересмотреть, не совпадает ли массовая загрузка фото с другими тяжёлыми процессами на сервере (бэкап, обновление системы).

Отдельный момент — своп. Для сценария с редкими пиками памяти небольшой swap на VPS (1-2 ГБ) работает как страховка от OOM-килла в момент загрузки партии фото, а не как постоянный рабочий ресурс — держать HomeBox постоянно в свопе не стоит, это заметно замедлит SQLite. Как правильно настроить своп на свежем сервере, разобрано в статье про swap и производительность на Debian 12.

Что ещё влияет на выбор сервера, помимо RAM

RAM — не единственный параметр. Для HomeBox важны ещё:

• Диск. SQLite чувствителен к скорости случайной записи (fsync при каждой транзакции). На NVMe-VPS база работает заметно отзывчивее, чем на медленном сетевом хранилище. Для личного архива хватит 10-20 ГБ, для семейного инвентаря с фото в высоком разрешении закладывайте 30-50 ГБ и больше.
• CPU. Здесь HomeBox нетребователен: 1 vCPU достаточно почти для любого домашнего сценария, обработка изображений — единственный момент, где лишнее ядро реально помогает при массовой загрузке.
• Сеть. Если вы фотографируете вещи телефоном и заливаете фото сразу с мобильного интернета, важнее не пропускная способность сервера, а стабильность соединения — обрыв на середине аплоада крупного файла надёжнее ловится тайм-аутом клиента, чем нехваткой ресурсов сервера.

Если помимо HomeBox на том же VPS планируете держать ещё пару лёгких self-hosted сервисов (заметки, чтение статей офлайн и подобное), ориентируйтесь на суммарные аппетиты — например, расчёт RAM для Wallabag даёт похожую картину для другого лёгкого Go/PHP-приложения того же класса, и вместе с HomeBox они спокойно делят один сервер на 2 ГБ.

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