Сколько RAM нужно для Home Assistant

MAATRIX

Home Assistant — самая массовая open-source платформа умного дома: тысячи интеграций, полный контроль над устройствами и никакой зависимости от облака производителя, которое завтра может закрыть API или поднять цену подписки. Проблема в том, что официальный минимум («2 ГБ RAM, 32 ГБ диска») не учитывает, что после установки вы почти наверняка добавите десяток интеграций, включите распознавание речи или подключите камеры — и память начнёт заканчиваться незаметно, пока однажды автоматизации не начнут срабатывать с задержкой в несколько секунд. Разберём, из чего складывается расход RAM и сколько реально закладывать под разные сценарии.

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

Сам процесс Home Assistant Core (Python-приложение, которое крутит логику интеграций и автоматизаций) в покое, сразу после первого запуска с парой демо-интеграций, занимает 200-350 МБ. Но реальная установка почти никогда не остаётся такой лёгкой — каждая активная интеграция держит в памяти своё состояние, а фоновые компоненты (база данных истории, Zigbee/Z-Wave координатор, голосовой ассистент) добавляют своё поверх базы.

Практический ориентир для установки в контейнере Docker на VPS (без встроенной ОС Home Assistant OS, о разнице ниже):

Это ориентир, а не жёсткий порог: у пользователя с пятью устройствами и без камер 1 ГБ может хватать месяцами, а у другого с теми же пятью устройствами, но с включённым Assist и потоком с камеры, 2 ГБ будет мало. Дальше — откуда именно берётся расход.

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

Четыре компонента съедают RAM неравномерно, и понимание их долей помогает решить, что урезать при нехватке памяти, а что не трогать.

Интеграции и их entity. Каждое подключённое устройство (лампа, розетка, датчик, термостат) — это одна или несколько entity в реестре, и каждая держит в памяти своё текущее состояние, атрибуты и историю последних изменений для быстрого доступа. Пять интеграций с двумя устройствами почти незаметны, но пользователи с 100+ устройствами (частый случай при полном покрытии Zigbee-сетью дома) видят, что базовый процесс Core вместо 300 МБ занимает уже 600-900 МБ просто на хранение состояния.

Recorder и база истории. Компонент recorder пишет каждое изменение состояния каждой entity в SQLite (по умолчанию) или внешнюю БД (PostgreSQL/MariaDB). По умолчанию purge_keep_days — 10 дней, и на активном доме с частыми датчиками (движение, температура, энергопотребление) база home-assistant_v2.db разрастается до сотен мегабайт-гигабайта, а сам процесс recorder держит буфер записи в памяти. Это самый частый источник постепенного роста потребления со временем, а не разовый скачок.

Zigbee/Z-Wave координатор. Если используете ZHA (Zigbee Home Automation, встроенный) или Zigbee2MQTT в отдельном контейнере — координатор держит в памяти таблицу маршрутизации сети и очередь команд. На небольшой сети (до 30-40 устройств) это 50-100 МБ, но растёт с размером mesh-сети и числом ретрансляторов.

Голосовой ассистент и дополнительные контейнеры. Assist Pipeline с локальным распознаванием речи (Whisper) и синтезом (Piper) в отдельных контейнерах добавляет заметный расход — Whisper даже на самой лёгкой модели держит от 200-500 МБ во время работы, и это отдельная статья бюджета сверх самого Home Assistant. Похожая логика с локальными моделями разобрана в материале сколько RAM нужно для Whisper по моделям — расход там растёт нелинейно с размером модели, и голосовой ассистент дома — тот же принцип.

Home Assistant OS vs Docker-контейнер на VPS

Важное решение до расчёта памяти — что именно вы разворачиваете, потому что цифры отличаются заметно.

Home Assistant OS (HAOS) — полноценная операционная система с супервизором, которая управляет аддонами (Node-RED, ESPHome, база данных и т.д.) через собственную панель. Она рассчитана на Raspberry Pi или мини-ПК и включает много служебных процессов супервизора — официальный минимум для HAOS 2 ГБ RAM не случаен, супервизор сам по себе не бесплатен по памяти.

Home Assistant Container — Core в чистом Docker-контейнере без супервизора, аддоны замещаются отдельными контейнерами в том же docker-compose, которые вы поднимаете и обновляете сами. Это заметно легче: нет накладных расходов супервизора, но и автоматических обновлений через UI нет — обновляете образ вручную.

Для аренды VPS почти всегда логичнее второй вариант — экономия 200-400 МБ RAM на серверах без лишних аддонов ощутима. Быстрый запуск:

services:
  homeassistant:
    container_name: homeassistant
    image: ghcr.io/home-assistant/home-assistant:stable
    volumes:
      - ./config:/config
      - /etc/localtime:/etc/localtime:ro
    restart: unless-stopped
    network_mode: host

network_mode: host нужен для корректного автообнаружения устройств в локальной сети (mDNS, SSDP) — без него часть интеграций типа Chromecast или HomeKit-совместимых устройств просто не найдёт оборудование в сети. Общие принципы работы с ресурсами контейнеров, если планируете держать рядом несколько сервисов, разобраны в статье лимиты CPU и памяти в Docker.

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

На VPS с 1 ГБ без свопа типичный сценарий поломки такой: вечером, когда активность датчиков движения и освещения пиковая, recorder пишет много событий одновременно, память заполняется, и OOM killer (Out-Of-Memory killer ядра Linux) убивает случайный процесс — иногда сам Home Assistant Core, иногда контейнер MQTT-брокера, от которого зависят все Zigbee-устройства. Проверить факт такого убийства:

dmesg | grep -i "killed process"
# Out of memory: Killed process 1842 (python3)
journalctl -u docker --since "1 hour ago" | grep -i oom

После такого падения все автоматизации, завязанные на текущее состояние (свет по датчику движения, отопление по расписанию), просто перестают срабатывать до перезапуска — и если это происходит ночью без присмотра, узнаёте вы об этом только утром. Второй, более мягкий симптом — не OOM, а активный свопинг: интерфейс начинает открываться на 3-5 секунд дольше обычного, автоматизации срабатывают с заметной задержкой, а карточки с графиками (history, statistics) подгружаются рывками. Как правильно рассчитать своп под такую нагрузку — в материале правильный размер swap для VPS: для Home Assistant своп — разумная подстраховка на пиковые моменты записи в базу, а не постоянный режим работы.

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

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

Ограничить хранение истории в recorder. В configuration.yaml:

recorder:
  purge_keep_days: 5
  commit_interval: 30
  exclude:
    domains:
      - automation
      - updater
    entity_globs:
      - sensor.*_uptime

Пять дней вместо десяти по умолчанию заметно уменьшают размер базы и, соответственно, память под её кэш и индексы. Исключение шумных entity (счётчики аптайма, служебные сенсоры) из записи в историю — второй быстрый выигрыш, они всё равно почти никому не нужны в графиках.

Перейти на MariaDB/PostgreSQL вместо SQLite при большом числе устройств — звучит контринтуитивно (лишний контейнер), но на активном доме SQLite с блокировками на запись начинает есть больше памяти на операции, чем полноценная СУБД с нормальным кэшированием, а заодно снижается нагрузка на диск при частых записях.

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

docker stats homeassistant
free -h

Отключить неиспользуемые интеграции, а не просто «поставить и забыть» — часто после экспериментов остаются активные, но никем не читаемые интеграции (демо-погода, тестовые webhook), которые всё равно опрашиваются по расписанию и держат состояние.

Разнести тяжёлые компоненты по отдельным контейнерам с явными лимитами памяти (mem_limit), чтобы один разросшийся сервис не смог забрать всю память сервера и уронить остальное через OOM killer.

Видеонаблюдение и Frigate: отдельная статья бюджета

Если планируете подключить камеры с распознаванием объектов через Frigate (детекция людей, машин, животных на видео) — это принципиально другой уровень нагрузки, не сравнимый с обычными интеграциями умного дома. Frigate держит в памяти буферы декодирования видеопотоков и очередь кадров на анализ, и даже при использовании внешнего Coral TPU для инференса (что снимает нагрузку с CPU, но не с RAM) память под сами потоки остаётся.

Практический ориентир: 2-4 камеры с детекцией добавляют 1-2 ГБ поверх базового Home Assistant, а не десятки-сотни МБ, как обычная интеграция. Подробный разбор ресурсов под видеопотоки — в статье сколько ресурсов нужно VPS для видеонаблюдения, готовые конфигурации серверов — в материале лучший VPS для видеонаблюдения. Закладывайте память под Frigate отдельно от бюджета самого Home Assistant, не пытайтесь уместить оба «на глаз».

Практическая конфигурация VPS

Для базовой установки Home Assistant без камер и голосового ассистента (десятки устройств, стандартный набор интеграций) достаточно 2 ГБ RAM и 1-2 vCPU — платформа не требовательна к процессору в фоне, пики нагрузки короткие и приходятся на запуск и обновление интеграций. Диск — от 20 ГБ, но если планируете хранить историю подолгу или подключить InfluxDB для долгосрочных графиков, закладывайте 40 ГБ и выше сразу, расширять раздел на живой системе с базой данных менее удобно, чем взять запас заранее.

Для сценария с Zigbee/Z-Wave, голосовым ассистентом и парой интеграций, тянущих облачные API (это тоже небольшая, но постоянная нагрузка на память под сетевые буферы), комфортный минимум — 4 ГБ. Пример docker-compose с MQTT-брокером для Zigbee2MQTT рядом с Home Assistant:

services:
  homeassistant:
    container_name: homeassistant
    image: ghcr.io/home-assistant/home-assistant:stable
    volumes:
      - ./ha-config:/config
    restart: unless-stopped
    network_mode: host
    mem_limit: 1500m

  mosquitto:
    container_name: mosquitto
    image: eclipse-mosquitto:2
    volumes:
      - ./mosquitto/config:/mosquitto/config
      - ./mosquitto/data:/mosquitto/data
    ports:
      - "1883:1883"
    restart: unless-stopped
    mem_limit: 128m

Явные mem_limit предсказуемее случайного выбора жертвы OOM killer: при превышении лимита Docker просто перезапустит конкретный контейнер. Развёртывание Docker с нуля разобрано в статье установка Docker на Ubuntu 24.04, общие практики продакшен-конфигурации — в материале Docker Compose для продакшена.

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