Для Home Assistant зі 100–300 пристроями, історією за 30 днів і стандартними інтеграціями достатньо 2 vCPU, 4 GB RAM та 80 GB NVMe-диска; відеопотоки, Frigate і база даних за кілька років потребують значно більше ресурсів.
Від чого залежать вимоги Home Assistant до сервера?
Пристрої та сутності — не одне й те саме
Ключовий параметр home assistant server requirements — це не лише кількість фізичних пристроїв, а й число сутностей, частота їх оновлення та набір додатків. Один датчик температури зазвичай створює 2–5 сутностей: температуру, заряд батареї, рівень сигналу, стан доступності. Один лічильник енергії може додавати 10–30 сутностей, а сучасна кліматична система — десятки.
Будинок із 50 Zigbee-пристроями нерідко має 200–400 сутностей. Якщо інтеграції регулярно надсилають телеметрію, recorder записує тисячі подій на добу. Саме операції запису, індексація БД та автоматизації частіше спричиняють затримки, а не базове споживання ресурсів Home Assistant Core.
Під час вибору VPS варто враховувати загальні принципи з матеріалу про вимоги до сервера для self-hosted застосунків: CPU обирають під пікові завдання, RAM — із запасом для кешу та контейнерів, а диск — за IOPS і прогнозом зростання даних.
Що найбільше навантажує сервер
- Recorder та історія: запис станів, подій, логів і статистики в SQLite або PostgreSQL.
- Енергетичні панелі: часті оновлення power, voltage, current і consumption.
- ESPHome: компіляція прошивок використовує 1–2 CPU-потоки та може споживати 1–3 GB RAM.
- Node-RED, AppDaemon, pyscript: додають окремі процеси, бібліотеки й фонові завдання.
- Frigate і камери: декодування RTSP-відео, виявлення об'єктів і запис архіву не належать до «легкого» навантаження Home Assistant.
- Хмарні інтеграції: API-опитування, webhooks, голосові асистенти, MQTT і віддалені панелі.
Для встановлення у віртуальній машині, Docker або Home Assistant OS важливі ті самі ресурси, але Docker дає змогу ізолювати PostgreSQL, MQTT і Node-RED в окремих контейнерах. Практичну інструкцію з розгортання наведено у статті Home Assistant на VPS: встановлення, налаштування та обслуговування.
Який сервер потрібен для Home Assistant залежно від навантаження
Таблиця «масштаб → специфікація»
Для Home Assistant із 1000 сутностями, recorder за 30 днів і без декодування відео достатньо 4 vCPU, 8 GB RAM та 160 GB NVMe-диска.
| Масштаб навантаження | vCPU | RAM | Диск | Мережевий порт | Ціна, орієнтовно (березень 2026) |
|---|---|---|---|---|---|
| 20–80 пристроїв, до 300 сутностей, 2–4 інтеграції | 1 vCPU | 2 GB | 40 GB NVMe | 100 Mbps | від $6/міс. |
| 80–300 пристроїв, 300–1000 сутностей, MQTT, ESPHome | 2 vCPU | 4 GB | 80 GB NVMe | 1 Gbps | від $12/міс. |
| 300–700 пристроїв, 1000–3000 сутностей, Node-RED, історія 90 днів | 4 vCPU | 8 GB | 160 GB NVMe | 1 Gbps | від $24/міс. |
| 700–1500+ пристроїв, 3000–10 000 сутностей, PostgreSQL, кілька користувачів | 6–8 vCPU | 16 GB | 320 GB NVMe | 1 Gbps | від $48/міс. |
| Home Assistant + Frigate, 4–8 камер без GPU | 8 vCPU | 16–32 GB | 500 GB NVMe | 1 Gbps | від $80/міс. |
Ціни наведено як загальноринкові орієнтири станом на березень 2026 року для VPS відповідного класу; підсумкова вартість залежить від регіону, резервного копіювання, виділеної IP-адреси, обсягу NVMe та доступності GPU.
Як інтерпретувати розрахунок
Відповідь на запит home assistant how many devices не можна звести до фіксованого числа. 500 вимикачів із рідкісними змінами можуть працювати на 2 vCPU і 4 GB RAM, тоді як 100 пристроїв обліку енергії з оновленням кожні 5 секунд здатні створити інтенсивніше навантаження на БД. Для production-інсталяції варто залишати 30–50% запасу CPU та не заповнювати NVMe більш ніж на 75–80%.
Якщо на сервері працюватимуть камери, розраховуйте їх окремо. Home Assistant отримує стани від Frigate, але декодування H.264/H.265 та object detection створюють основне навантаження. Для такого сценарію використовуйте рекомендації зі статті про вимоги до сервера Frigate, CPU, GPU та Coral.
Шукаєте надійний сервер для своїх проєктів?
VPS від $10/міс. і виділені сервери від $9/міс. з NVMe, DDoS-захистом та підтримкою 24/7.
Переглянути пропозиції →Вимоги до обладнання для Home Assistant: CPU, RAM і NVMe
Який CPU потрібен для Home Assistant
Home assistant hardware requirements починаються з продуктивного однопотокового CPU: автоматизації, обробка подій Python і частина операцій SQLite не масштабуються лінійно на 8–16 ядер. Для середнього будинку краще обрати 2–4 сучасні vCPU із частотою від 2,5 GHz, а не велику кількість повільних потоків.
Нормальний робочий режим — середнє завантаження CPU до 30–40%, із короткочасними піками до 70%. Якщо процес python3, postgres або контейнер recorder стабільно утримує 80–100% одного ядра, інтерфейс відповідатиме повільніше, а автоматизації виконуватимуться із затримкою.
docker stats --no-stream
uptime
free -h
df -h
iostat -xz 1 5У виводі iostat звертайте увагу на %util та затримку запису. Для активної БД постійна затримка запису понад 15–20 ms — сигнал перевірити NVMe, обсяг історії та виключення recorder. HDD для основної БД Home Assistant не рекомендується: випадкові записи та VACUUM помітно збільшать час відгуку інтерфейсу.
Скільки RAM потрібно для Home Assistant
Відповідь на питання «скільки RAM потрібно для Home Assistant» залежить від контейнерів. Сам Home Assistant Core із десятками інтеграцій зазвичай вкладається у 500 MB–1,5 GB, але ОС, файловий кеш, MQTT, Node-RED, ESPHome та PostgreSQL змінюють розрахунок. 2 GB підходять для мінімального домашнього екземпляра, 4 GB — практичний мінімум для постійної роботи, а 8 GB — безпечний вибір для сотень пристроїв і кількох add-ons.
- 2 GB RAM: Core, Zigbee2MQTT або ZHA, базовий recorder, до 300 сутностей.
- 4 GB RAM: MQTT, ESPHome, HACS, 300–1000 сутностей, кілька дашбордів.
- 8 GB RAM: Node-RED, PostgreSQL, 1000–3000 сутностей, тривала історія.
- 16 GB RAM: велика інсталяція, аналітика, тестові контейнери або Frigate без важкого GPU-пайплайна.
Не розраховуйте на swap як на заміну оперативної пам'яті. Swap у 1–2 GB корисний як аварійний захист від OOM, але активне використання swap на NVMe погіршує час відгуку. Для Linux-сервера можна задати помірний параметр:
sudo sysctl -w vm.swappiness=10
echo "vm.swappiness=10" | sudo tee -a /etc/sysctl.conf
Розмір бази даних Home Assistant recorder: диск, retention і PostgreSQL
Як оцінити обсяг історії
Home assistant recorder database sizing залежить від кількості змін станів, а не від розміру YAML-конфігурації. Для будинку з 300–800 сутностями та retention 30 днів SQLite зазвичай займає 2–10 GB. За активного енергомоніторингу, частих MQTT-повідомлень і 3000 сутностей база може зростати на 1–5 GB на місяць навіть після очищення старих записів.
Практичний запас диска для Home Assistant має включати розмір поточної БД, тимчасові файли VACUUM, резервні копії, журнали та оновлення. Якщо база займає 20 GB, не виділяйте для неї розділ на 25 GB: під час обслуговування знадобиться щонайменше 40–60 GB вільного простору. Для VPS з історією 90 днів розумний старт — 160 GB NVMe.
Обмежуйте запис шумних сутностей. Наприклад, заряд батареї датчика, RSSI, uptime та діагностика не завжди потрібні в історії. Конфігурація нижче зменшує кількість записів і знижує IOPS:
recorder:
purge_keep_days: 30
auto_purge: true
exclude:
entity_globs:
- sensor.*_linkquality
- sensor.*_rssi
- sensor.*_uptime
domains:
- sun
- updaterКоли варто перейти з SQLite на зовнішній Postgres
SQLite залишається хорошим варіантом для невеликого будинку: вона не потребує окремого сервісу, проста для резервного копіювання та стабільно працює на NVMe. Перехід на PostgreSQL виправданий, коли база перевищує 10–20 GB, є понад 1000 сутностей, що активно змінюються, одночасно відкрито кілька дашбордів або очищення історії створює помітні затримки.
PostgreSQL особливо корисний за тривалого зберігання історії — від 90 днів до кількох років. Розміщуйте БД на тому самому приватному VPS або в окремому контейнері зі швидким NVMe; не відкривайте порт 5432 в інтернет. Приклад рядка підключення:
recorder:
db_url: postgresql://ha_user:strong_password@postgres:5432/homeassistant
purge_keep_days: 90
auto_purge: trueБаза даних не скасовує потреби в резервному копіюванні. Щоденний pg_dump, snapshot VPS і перевірка відновлення важливіші за вибір самого рушія. Для зберігання кількох копій і відокремлення production-даних від архіву стане в пригоді підхід із матеріалу про розрахунок обсягу бекапів і дедуплікацію.
Вимоги до сервера Home Assistant для інтеграцій і додатків
MQTT, Zigbee, Z-Wave та ESPHome
Вимоги до сервера Home Assistant для інтеграцій зазвичай визначає частота повідомлень. Mosquitto для 1000 MQTT-повідомлень за хвилину рідко потребує понад 256–512 MB RAM, але постійний запис кожного повідомлення в recorder може швидко збільшити БД. Обмежуйте history для налагоджувальних топіків і не публікуйте телеметрію кожні 1–2 секунди без реальної потреби.
Zigbee- та Z-Wave-координатори можна підключити через USB до локального міні-ПК або передати у віртуальну машину. Для віддаленого VPS краще використовувати мережевий координатор, VPN-тунель чи локальний MQTT-шлюз: USB-over-IP через нестабільний інтернет створює ризик втрати пристроїв після обриву з'єднання.
ESPHome має два режими навантаження. Звичайна робота підключених пристроїв майже не впливає на CPU, але збирання firmware потребує компілятора, Python-пакетів і пам'яті. На 1 vCPU та 2 GB RAM компіляція може тривати 5–15 хвилин; 2–4 vCPU і 4 GB RAM помітно прискорюють оновлення кількох ESP32.
Автоматизації, HACS і голосовий доступ
Node-RED і складні шаблони Jinja корисні, але збільшують споживання пам'яті. Якщо автоматизація обробляє десятки подій за секунду, додайте 1 vCPU і 1–2 GB RAM до базової конфігурації. HACS сам по собі не створює значного навантаження, проте непідтримувані кастомні інтеграції можуть спричиняти витоки пам'яті або часті помилки в логах.
Для зовнішнього доступу використовуйте HTTPS, окремого користувача з MFA та VPN або reverse proxy. Не відкривайте Home Assistant напряму без TLS на порт 8123. Перевірити активні з'єднання та мережеву активність можна командами:
ss -tulpn
docker logs --tail 100 homeassistant
curl -I https://your-domain.exampleТрафік, відеопотоки та розміщення Home Assistant на VPS
Скільки трафіку споживає розумний дім
Звичайний сервер Home Assistant з MQTT, Zigbee і хмарними інтеграціями рідко використовує понад 5–30 GB зовнішнього трафіку на місяць. Webhooks, сповіщення, синхронізація мобільних застосунків і віддалені дашборди збільшують обсяг помірно. Основне джерело трафіку — камери: один RTSP-потік 1080p з бітрейтом 4 Mbps передає близько 1,3 TB на місяць за безперервної трансляції.
Не спрямовуйте постійні потоки камер через VPS лише для відображення в інтерфейсі, якщо можна передавати події або використовувати локальний proxy. Для 4–8 камер пріоритетними є локальний сервер, GPU, Intel Quick Sync або Coral TPU. Детальні розрахунки CPU, RAM і мережевого каналу наведено у статті про сервер для Frigate.
Коли VPS кращий за локальний міні-ПК
VPS зручний для публічного HTTPS-доступу, надійної IP-адреси, автоматичних snapshot і розміщення PostgreSQL, Node-RED або віддаленого Home Assistant. Локальний міні-ПК вигідніший, коли потрібні USB-координатори, мінімальна затримка до Zigbee/Z-Wave та обробка камер без передавання відеопотоків через інтернет.
Гібридна схема часто практичніша: Home Assistant і координатори працюють вдома, а VPS приймає VPN, зберігає резервні копії та запускає зовнішні сервіси. Якщо весь екземпляр розміщено в дата-центрі, налаштуйте WireGuard до домашньої мережі та забороніть доступ до IoT-пристроїв з усіх підмереж, крім VPN.
# Приклад дозволу доступу до Home Assistant лише через VPN
sudo ufw allow from 10.8.0.0/24 to any port 8123 proto tcp
sudo ufw deny 8123/tcp
sudo ufw enableМоніторинг і резервне копіювання Home Assistant
Які метрики контролювати
Для Home Assistant корисно відстежувати CPU, вільну RAM, swap, вільне місце на NVMe, затримку диска та розмір бази. Попередження варто налаштувати за заповнення диска на 80%, постійного використання swap понад 256 MB або зростання БД більш ніж на 20% за тиждень без зміни кількості пристроїв.
Перевіряйте розмір бази та каталогу конфігурації щонайменше раз на тиждень:
du -sh /config
du -sh /config/home-assistant_v2.db*
docker exec -it postgres psql -U ha_user -d homeassistant -c "\l+"Правило 3-2-1 для розумного дому
Мінімальна стратегія — щоденний backup Home Assistant, одна локальна копія та одна копія поза основним сервером. До backup мають потрапляти configuration.yaml, каталог .storage, секрети, користувацькі компоненти, база даних і ключі VPN. Зберігайте щонайменше 7 щоденних і 4 щотижневі копії.
Раз на квартал відновлюйте backup у тестовий контейнер або окрему VM. Файл резервної копії без перевіреного відновлення не гарантує працездатність автоматизацій, токенів інтеграцій та історії PostgreSQL.
Часті запитання
Скільки RAM потрібно для Home Assistant?
Для невеликого будинку до 300 сутностей достатньо 2 GB RAM, якщо використовуються лише Home Assistant, Zigbee та базовий recorder. Для 300–1000 сутностей, MQTT, ESPHome і HACS краще обрати 4 GB. Конфігурація з PostgreSQL, Node-RED і тривалою історією потребує 8 GB RAM, щоб уникнути активного swap і затримок інтерфейсу.
Скільки пристроїв може обслуговувати Home Assistant?
Home Assistant може працювати з 1000 і більше пристроями, але рахувати потрібно сутності та частоту оновлень. Близько 300 пристроїв зазвичай створюють 1000–3000 сутностей. Для такого обсягу підходять 4 vCPU, 8 GB RAM і 160 GB NVMe за зберігання історії 30–90 днів. Камери та Frigate слід розраховувати як окреме навантаження.
Коли потрібно переходити з SQLite на PostgreSQL?
SQLite підходить для інсталяцій до кількох сотень пристроїв і бази розміром приблизно до 10 GB на швидкому NVMe. PostgreSQL варто впроваджувати за 1000+ сутностей, що часто змінюються, історії від 90 днів, бази 20 GB і більше або затримок під час очищення recorder. Для PostgreSQL бажано виділити щонайменше 2 GB додаткової RAM.
Скільки диска виділити для Home Assistant?
Мінімум 40 GB NVMe підходить для тестового екземпляра або будинку без тривалої історії. Для постійної роботи з 300–1000 сутностями обирайте 80 GB, а для PostgreSQL і retention 90 днів — від 160 GB. Не заповнюйте диск більш ніж на 80%: очищення бази та створення backup можуть тимчасово потребувати десятки додаткових гігабайтів.
Висновки
Практична рекомендація
Для більшості будинків оптимальна конфігурація — 2 vCPU, 4 GB RAM і 80 GB NVMe; для 1000+ сутностей, PostgreSQL і Node-RED обирайте 4 vCPU, 8 GB RAM та 160 GB NVMe. Відеоспостереження з Frigate розміщуйте окремо або закладайте щонайменше 8 vCPU, 16 GB RAM і швидкий диск від 500 GB.
NVMe VPS з активацією за 60 секунд: повний root-доступ, 20+ локацій, оплата карткою або криптовалютою.
Обрати тариф
