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

MAATRIX

Homepage (gethomepage.dev) — это стартовая страница домашнего сервера: карточки сервисов, живые виджеты с состоянием контейнеров, погодой, загрузкой диска, статусом Proxmox или Uptime Kuma, всё на одном экране вместо десятка вкладок в закладках браузера. Разработчики честно пишут, что приложение «лёгкое», но не называют конкретных цифр RAM — а когда вы добавляете 20 сервисов и десяток виджетов с опросом API каждые несколько секунд, разница между «работает» и «есть, но подвисает» становится ощутимой. Разберём, откуда берётся расход памяти в Homepage и сколько закладывать под разные сценарии.

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

Homepage — это Next.js-приложение, которое рендерится один раз при сборке и дальше отдаётся как статика с небольшим API-слоем для виджетов. В простое, без активных виджетов, процесс node внутри контейнера держит 60-100 МБ. С включённой связкой Docker-виджет + 3-5 виджетов мониторинга (Uptime Kuma, Proxmox, погода) это обычно 150-250 МБ. Дальше расход растёт линейно с числом виджетов, которые опрашивают внешние API по расписанию.

Практический ориентир:

Это не жёсткие пороги: Homepage физически запускается и на 256 МБ, но при сборке Docker-образа или при перезапуске контейнера в момент пиковой нагрузки на слабой машине легко словить OOM. Дальше — почему.

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

Три источника расхода памяти у Homepage устроены по-разному, и понимать их полезно, чтобы знать, что урезать при нехватке ресурсов.

Сам Next.js-рантайм. Node.js держит V8-движок в памяти даже для простого рендеринга статики — это базовые 50-80 МБ, которые никуда не деваются независимо от конфигурации. Это плата за то, что Homepage — не статический HTML-генератор вроде Hugo, а живое приложение с server-side логикой для виджетов.

Опрос виджетов (widgets). Каждый виджет в services.yaml — это отдельный HTTP-запрос к API стороннего сервиса (Docker socket, Uptime Kuma, Sonarr, Proxmox, погодный API) по таймеру, заданному параметром refreshInterval (по умолчанию много где 10-60 секунд). Сам запрос лёгкий, но при 20-30 активных виджетах с коротким интервалом обновления это уже заметная фоновая нагрузка на CPU и, соответственно, на память под буферы ответов.

Docker-виджет и сокет. Если вы подключили /var/run/docker.sock для отображения статуса контейнеров прямо на дашборде, Homepage периодически опрашивает Docker API за списком контейнеров и их состоянием. На хосте с полусотней контейнеров (обычная история для домашней лаборатории) объём данных на каждый опрос ощутимо больше, чем при пяти сервисах.

Кастомные виджеты и customapi. Гибкость Homepage — в возможности прикрутить виджет к любому JSON API через customapi. Каждый такой виджет — ещё один параллельный запрос по расписанию, и если вы подключили десяток самописных эндпоинтов, это складывается в фоновую нагрузку, сравнимую с полноценным Docker-виджетом.

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

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

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

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

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

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

Увеличить refreshInterval у тяжёлых виджетов. В services.yaml для каждого виджета можно задать индивидуальный интервал опроса:

- Radarr:
    icon: radarr.png
    href: http://radarr.local
    widget:
      type: radarr
      url: http://radarr:7878
      key: your-api-key
      refreshInterval: 60000  # 60 секунд вместо дефолтных

Для виджетов, где актуальность до секунды не критична (диск, погода, статистика Proxmox), интервал в 60-120 секунд вместо дефолтного заметно снижает фоновую нагрузку.

Отключить лишние виджеты, а не только карточки-ссылки. Ссылка на сервис без виджета состояния почти ничего не стоит по памяти — расход даёт именно опрос API. Если сервис нужен просто как быстрая ссылка, не подключайте к нему widget, оставьте только href.

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

services:
  homepage:
    image: ghcr.io/gethomepage/homepage:latest
    container_name: homepage
    environment:
      HOMEPAGE_ALLOWED_HOSTS: your-domain.com
    volumes:
      - ./config:/app/config
      - /var/run/docker.sock:/var/run/docker.sock:ro
    ports:
      - "3000:3000"
    deploy:
      resources:
        limits:
          memory: 256M
    restart: unless-stopped

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

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

docker stats homepage --no-stream
free -h

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

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

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

services:
  homepage:
    image: ghcr.io/gethomepage/homepage:latest
    container_name: homepage
    environment:
      HOMEPAGE_ALLOWED_HOSTS: homepage.example.com
    volumes:
      - ./config:/app/config
      - /var/run/docker.sock:/var/run/docker.sock:ro
    ports:
      - "3000:3000"
    restart: unless-stopped

Переменная HOMEPAGE_ALLOWED_HOSTS обязательна начиная с версии, где добавили защиту от подмены хоста (host header injection) — без неё интерфейс просто откажется открываться на домене, отличном от localhost. Конфигурация сервисов, виджетов и настроек живёт в YAML-файлах внутри ./config (services.yaml, widgets.yaml, settings.yaml, bookmarks.yaml) — их удобно держать в git для версионирования, отдельно от самого контейнера.

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

По CPU Homepage непритязателен — 1 vCPU хватает почти всегда, узкое место именно память при большом числе виджетов. Отдельный VPS под один только Homepage — избыточное решение: обычно его ставят на ту же машину, где уже крутится десяток-другой сервисов домашней лаборатории (медиасервер, торрент-клиент, *arr-стек, Uptime Kuma), и именно их совокупный аппетит к RAM определяет тариф, а не сам дашборд. Для сравнения — если один из отображаемых сервисов, скажем, Home Assistant, тоже нужно спланировать по памяти, ориентиры для него разобраны в статье сколько RAM нужно для Home Assistant.

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