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

MAATRIX

Homarr — один из самых популярных дашбордов домашней лаборатории: карточки сервисов, drag-and-drop редактор досок прямо в браузере, встроенные интеграции с Docker, *arr-стеком, Proxmox и десятками других приложений без единой правки YAML руками. Разработчики удобно называют его «лёгким», но после переезда на архитектуру 1.0 с собственной базой данных и фоновыми задачами он ощутимо тяжелее своих предшественников вроде Homepage или Heimdall — и на VPS с 256-512 МБ без свопа это заканчивается падением контейнера в самый неподходящий момент. Разберём, откуда берётся расход памяти у Homarr и сколько реально закладывать под разные сценарии использования.

Сколько RAM нужно Homarr: короткий ответ

Homarr — это не статическая страница, а полноценное веб-приложение на Next.js с backend-слоем на tRPC, встроенной базой данных (по умолчанию SQLite, есть вариант с PostgreSQL) и внутренним планировщиком задач, который периодически опрашивает интеграции. В простое, сразу после старта контейнера, ядро Homarr обычно держит 250-400 МБ — это заметно больше, чем у более лёгких аналогов, и связано именно с архитектурой: рантайм Node.js, слой базы данных и фоновые джобы работают постоянно, а не только по запросу страницы.

Практический ориентир — держите в уме, что это ориентировочные цифры, у вас может отличаться в зависимости от числа досок, виджетов и версии Homarr:

Это не жёсткие пороги, а рабочий ориентир: Homarr технически стартует и на 512 МБ, но именно момент первого запуска (миграция базы, инициализация интеграций) — самый требовательный к памяти, и на границе лимита контейнер может не пережить именно его, а не спокойную работу дальше.

Из чего складывается потребление памяти

У Homarr несколько источников расхода памяти, и они устроены иначе, чем у более простых дашбордов на статике.

Node.js-рантайм и Next.js. Как и у большинства современных дашбордов, база — это V8-движок под капотом Node.js, который держит 60-100 МБ независимо ни от чего. Но поверх этого у Homarr работает полноценный backend-сервер (tRPC API), обслуживающий и статические страницы, и запросы редактора досок в реальном времени — это уже не просто отдача готового HTML.

Встроенная база данных. В отличие от конкурентов, которые хранят конфигурацию в YAML-файлах на диске, Homarr с версии 1.0 держит доски, виджеты и настройки в базе данных — по умолчанию SQLite внутри контейнера. Сама СУБД лёгкая, но постоянные операции чтения/записи при редактировании досок и работе интеграций добавляют накладные расходы к базовому потреблению.

Планировщик интеграций (integrations). Каждая подключённая интеграция — Docker, Sonarr, Radarr, Proxmox, Uptime Kuma, Home Assistant и десятки других — это фоновая задача, которая опрашивает соответствующий API по расписанию и кеширует результат для быстрого отображения на доске. Чем больше интеграций и чем короче интервал обновления, тем выше фоновая нагрузка на CPU и, соответственно, на память под очереди задач и кеш ответов.

Docker-интеграция. Если вы подключили Homarr к Docker-сокету для отображения статуса контейнеров и управления ими прямо с доски (запуск/остановка одной кнопкой), приложение периодически опрашивает Docker API. На хосте с большим количеством контейнеров — типичная ситуация для домашней лаборатории — объём данных на каждый цикл опроса заметно больше, чем при паре сервисов.

Редактор досок в браузере. Drag-and-drop интерфейс настройки — сильная сторона Homarr, но каждое открытие редактора и перетаскивание виджетов генерирует запросы к backend для сохранения layout в реальном времени, что даёт кратковременные пики потребления памяти сверх фонового уровня.

Что происходит при нехватке памяти

На VPS с 512 МБ без свопа типичный сценарий такой: контейнер запускается, инициализирует базу данных, но при первом прогоне миграций или при одновременной активации нескольких интеграций сразу после старта память упирается в лимит, ядро включает OOM killer (Out-Of-Memory killer — механизм Linux, который принудительно завершает процесс при нехватке памяти даже с учётом свопа), и контейнер перезапускается с кодом выхода 137. Проверить это можно так:

docker inspect homarr --format='{{.State.OOMKilled}}'
dmesg | grep -i "killed process"

Если видите true или строку Out of memory: Killed process с PID контейнера — дело в нехватке памяти, а не в ошибке конфигурации интеграций. Второй частый симптом — не падение, а видимые тормоза интерфейса: доска долго прогружается, drag-and-drop дёргается, виджеты обновляются с задержкой, потому что процесс постоянно свопится вместо того, чтобы держать рабочие данные в оперативной памяти. Подробно про расчёт объёма подкачки под такие пики — в статье правильный размер swap для VPS, а общие признаки нехватки RAM на сервере до того, как что-то упадёт, разобраны в статье что делать при нехватке RAM.

Как снизить потребление RAM

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

Сократить число активных интеграций. Каждая интеграция — это постоянная фоновая задача. Отключите те, что подключены «на будущее», но реально не используются на доске — в настройках интеграции это делается без удаления самой карточки сервиса.

Увеличить интервал обновления там, где это доступно. Для части интеграций в настройках можно задать более редкий период опроса — актуально для виджетов, где секундная точность не критична (диск, статистика Proxmox, погода).

Использовать SQLite вместо PostgreSQL, если инстанс небольшой. PostgreSQL как отдельный контейнер добавляет ещё 50-150 МБ базового потребления сверх самого Homarr — оправдано для крупных инсталляций с несколькими одновременными пользователями, но избыточно для одиночной домашней лаборатории.

Ограничить память контейнера явно в docker-compose.yml, чтобы Homarr не тянул ресурсы у соседних сервисов при аномальном поведении:

services:
  homarr:
    image: ghcr.io/homarr-labs/homarr:latest
    container_name: homarr
    environment:
      - SECRET_ENCRYPTION_KEY=your-64-char-hex-key
    volumes:
      - ./appdata:/appdata
      - /var/run/docker.sock:/var/run/docker.sock:ro
    ports:
      - "7575:7575"
    deploy:
      resources:
        limits:
          memory: 1024M
    restart: unless-stopped

Если контейнер регулярно упирается в лимит и получает OOM, это сигнал поднять память или почистить интеграции, а не просто снять ограничение вслепую.

Проверить фактическое потребление после изменений:

docker stats homarr --no-stream
free -h

docker stats покажет текущий расход конкретно контейнера Homarr, free -h — общую картину по серверу, включая своп, если он подключён.

Установка на VPS: практическая конфигурация

Homarr разворачивается через Docker — это единственный официально поддерживаемый способ. Минимальный рабочий docker-compose.yml:

services:
  homarr:
    image: ghcr.io/homarr-labs/homarr:latest
    container_name: homarr
    environment:
      - SECRET_ENCRYPTION_KEY=your-64-char-hex-key
    volumes:
      - ./appdata:/appdata
      - /var/run/docker.sock:/var/run/docker.sock:ro
    ports:
      - "7575:7575"
    restart: unless-stopped

SECRET_ENCRYPTION_KEY обязателен — это 64-символьный hex-ключ, которым шифруются хранимые в базе секреты (токены API интеграций). Сгенерировать его можно командой:

openssl rand -hex 32

Ключ нужно сохранить: при потере доступ к сохранённым в интеграциях API-ключам будет утерян, и их придётся вводить заново. Все данные — доски, настройки, база SQLite — живут в примонтированной директории ./appdata, её стоит включить в регулярный бэкап отдельно от самого контейнера.

Если Homarr нужен снаружи локальной сети, поднимите перед ним реверс-прокси с TLS — практическая настройка под Docker разобрана в статье Traefik как reverse proxy для Docker. Для управления самим набором контейнеров, которые Homarr выводит на доску, многие ставят рядом Portainer — пошаговая установка описана в статье Portainer на Ubuntu 24.04. Если для вас важнее простая связка ссылок без интеграций и встроенной базы, присмотритесь к более лёгкой альтернативе — сравнение по памяти есть в статье сколько RAM нужно для Homepage.

По CPU Homarr не так непритязателен, как более простые дашборды: 1 vCPU достаточно для базовой работы, но при большом числе одновременных интеграций с коротким интервалом опроса заметны кратковременные всплески нагрузки — 2 vCPU дают запас без просадок интерфейса. Отдельный VPS под один только Homarr — почти всегда избыточное решение: его ставят рядом с остальным стеком домашней лаборатории на той же машине, и именно совокупный аппетит соседних сервисов к памяти определяет итоговый тариф, а не сам дашборд.

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