Апаратні вимоги n8n: як підібрати сервер для self-hosted продакшну
Практичний посібник з апаратних вимог n8n, вимог до сервера та налаштувань, коли робочі процеси переходять від локальної практики до реального продакшну.
Перевірено за наведеними джерелами .
Чому локальні апаратні вимоги n8n не переносяться в продакшн
Коли ви вчитеся запускати n8n локально, апаратні вимоги n8n майже не мають значення: контейнер на ноутбуці спокійно обробляє вебхук і кілька викликів API. У продакшні все інакше, бо той самий процес тепер несе на собі запуски за розписом, паралельний вебхук-трафік, історію виконань і креденшели цілої команди — і вимоги до n8n змінюються разом із цим.
Перед тим як називати будь-які цифри, варто розібратися, які є докази. Сторінка prerequisites у документації n8n публікує ілюстративний базовий рівень — мінімум 10 циклів CPU з масштабуванням за потреби, база даних на SSD від 512 МБ до 4 ГБ і від 320 МБ до 2 ГБ пам'яті — але прямо зазначає, що це приклад на основі n8n Cloud, лише для ілюстрації, і що реальні потреби залежать від користувачів, робочих процесів і виконань. Хостинг-провайдери натомість публікують вимоги до сервера n8n у вигляді тарифних рівнів: і Self-Hosting Requirements Guide від Cherry Servers (опубліковано в травні 2026, оновлено в липні 2026), і туторіал про VPS від Hostinger (серпень 2026) продають сервери, тож ставтеся до їхніх цифр як до комерційно мотивованих орієнтирів.
Жодне з наданих джерел не бенчмаркує n8n на визначеному навантаженні, тож кожна цифра нижче — це відправна точка для моніторингу й коригування, а не виміряна ємність.
| Джерело | Розробка | Продакшн |
|---|---|---|
| Сторінка prerequisites n8n | Ілюстративно: 320 МБ–2 ГБ пам'яті, база даних на SSD 512 МБ–4 ГБ | Та сама таблиця, подана лише як приклад, похідний від Cloud |
| Cherry Servers, 2026 | 2 ядра, 2 ГБ RAM, 20 ГБ SSD, SQLite | 4+ ядра, 8–16 ГБ RAM, 50–100 ГБ NVMe, PostgreSQL |
| Hostinger, 2026 | Мінімум 1 vCPU, 2 ГБ RAM, 20 ГБ SSD | 2–4 vCPU, 4–8 ГБ RAM, 40–80 ГБ NVMe |
| Тред у спільноті, 2023 | Свідчення: 1 спільний CPU і 1 ГБ RAM названі робочим варіантом | Той самий автор зазначає, що запасу на пікові навантаження немає |
Sources: Prerequisites | Deploy | n8n Docs, n8n Self-Hosting Requirements Guide (2026) | Cherry Servers, What are the VPS requirements for n8n?, Hardware For Self Hosting - Questions - n8n Community
Спочатку пам'ять, потім CPU
Документація n8n радить під час планування інфраструктури віддавати пріоритет пам'яті, а не CPU, бо n8n не є ресурсоємним щодо процесора, і зазначає, що нода Code створює копії ваших даних до і після обробки. Це якісна рекомендація від вендора, а не вимір, але вона вказує на правильний вимір для апаратних вимог n8n: розраховуйте RAM під найважчий окремий робочий процес плюс запас на все інше, що працює одночасно.
Коли self-hosted n8n вичерпує пам'ять, документація пропонує два напрямки: дати процесу більше пам'яті або споживати менше — розбивати дані на частини, уникати ноди Code, не робити ручних виконань на великих наборах даних і розділяти роботу на під-воркфлоу. Саме для помилки JavaScript heap out of memory n8n радить виділити більше old space для V8 через опцію max-old-space-size, задану в CLI або через NODE_OPTIONS; рекомендованого значення не задокументовано.
Sources: Prerequisites | Deploy | n8n Docs, Fix memory issues | Deploy | n8n Docs
База даних і зберігання: SQLite, PostgreSQL і pruning
Self-hosted n8n за замовчуванням використовує SQLite і опційно підтримує PostgreSQL. Станом на липень 2026 документація перелічує дві мажорні версії, що активно підтримуються, — 17 і 18, — плюс 16 для сумісності, зазначає, що підтримуваний діапазон зсувається щолистопада, і позначає Aurora як експериментальну, тоді як AlloyDB, CockroachDB і YugabyteDB не підтримуються. Оскільки цей перелік явно привʼязаний до часу, перевіряйте сторінку документації, а не фіксуйте версію зі статті.
Перехід на PostgreSQL — це не оновлення на місці. Практичний посібник (LumaDock, грудень 2025) описує експорт робочих процесів і креденшелів через n8n CLI, запуск нового інстансу на Postgres з тим самим ключем шифрування та імпорт креденшелів перед робочими процесами; історія виконань не переноситься, і автор зазначає, що не тестував експорт сутностей на великих обсягах. n8n також рекомендує окрему базу даних для кожного інстансу, щоб уникнути залежностей і деградації продуктивності, а разом із цим — сховище на SSD, збережені томи контейнерів, списки дозволених IP і резервні копії.
Редакційний погляд на перехід із SQLite на PostgreSQL
- Експорт: Використайте n8n CLI, щоб експортувати робочі процеси і креденшели з інстансу на SQLite.
- Підготовка: Підніміть окрему базу PostgreSQL на підтримуваній мажорній версії.
- Новий старт: Запустіть новий інстанс n8n на Postgres із тим самим ключем шифрування.
- Імпорт: Спочатку імпортуйте креденшели, потім робочі процеси.
- Прийміть втрату: Очікуйте, що історія виконань залишиться на старому інстансі.
Другий драйвер зростання — дані виконань. Pruning увімкнений за замовчуванням: виконання видаляються, коли перевищують EXECUTIONS_DATA_MAX_AGE (336 годин, тобто 14 днів) або EXECUTIONS_DATA_PRUNE_MAX_COUNT (10 000), починаючи з найстаріших, а анотовані виконання не видаляються ніколи. У базі SQLite за замовчуванням звільнене місце перевикористовується, а не повертається файловій системі, якщо ви не увімкнете DB_SQLITE_VACUUM_ON_STARTUP або не виконаєте VACUUM вручну. Обирайте період зберігання свідомо, а не успадковуйте значення за замовчуванням.
Sources: Choose n8n's database | Deploy | n8n Docs, Prerequisites | Deploy | n8n Docs, Manage execution data | Deploy | n8n Docs, PostgreSQL vs SQLite for n8n: When to switch and how - LumaDock
Один інстанс із контролем паралельності — чи queue mode
У звичайному режимі одного інстансу self-hosted n8n не обмежує, скільки продакшн-виконань іде паралельно, що під час стрибків навантаження може перевантажити event loop. N8N_CONCURRENCY_PRODUCTION_LIMIT ставить надлишок у чергу за принципом FIFO; він стосується лише запусків від вебхуків або тригерів, вимкнений за замовчуванням, а виконання з черги не можна повторити. Налаштуйте його до того, як він стане потрібним.
Коли один процес більше не здатен тримати редактор відзивним, n8n пропонує queue mode — головний інстанс плюс воркери, скоординовані через Redis — як найкраще масштабований варіант, адже воркери можна додавати чи прибирати під навантаження. Це архітектурне твердження з документації вендора, а не бенчмарк. Queue mode вимагає Redis і спільної бази даних; робота поверх SQLite не підтримується.
| Параметр | Один інстанс | Queue mode |
|---|---|---|
| Ліміт за замовчуванням | Немає ліміту на паралельні продакшн-виконання | Паралельність воркера за замовчуванням — 10 |
| Контроль | N8N_CONCURRENCY_PRODUCTION_LIMIT, вимкнений за замовчуванням | Паралельність воркера, рекомендовано 5 або більше |
| База даних | SQLite або PostgreSQL | Спільна база даних; SQLite не підтримується |
| Додаткові сервіси | Не задокументовано | Redis як брокер повідомлень |
| Повтор виконань із черги | Виконання з черги не можна повторити | У цих джерелах не задокументовано |
Паралельність воркера за замовчуванням — 10, і n8n рекомендує 5 або більше, попереджаючи, що багато воркерів із низькою паралельністю можуть вичерпати пул з'єднань до бази даних і спричинити затримки й збої. Окремі інстанси-обробники вебхуків за балансувальником навантаження — опційний додатковий шар, і n8n радить не включати головний процес у цей пул, бо високе навантаження погіршує редагування та продуктивність інтерфейсу.
Великі відповіді на вебхуки потребують уваги: у queue mode відповідь повертається через Redis у межах N8N_WEBHOOK_RESPONSE_RELAY_SIZE_MAX (за замовчуванням 64 МіБ), і n8n радить закладати приблизно в 1,5 раза більше на кожну відповідь «у дорозі». Вивантаження тіл у сховище доступне з n8n 2.34.0 на кожному головному та вебхук-інстансі, потребує сховища, доступного для читання всім інстансам, а режим filesystem не рекомендується. Висока доступність із кількома головними інстансами — це self-hosted Enterprise-функція, яка вимагає Postgres, Redis, однакових версій n8n, N8N_MULTI_MAIN_SETUP_ENABLED і балансувальника зі sticky sessions, і вона недоступна в n8n Cloud.
Sources: Control concurrency | Deploy | n8n Docs, Enable queue mode | Deploy | n8n Docs
Стартова конфігурація, яку можна моніторити
Обґрунтована відправна точка для апаратних вимог n8n: PostgreSQL на окремій базі даних, сховище SSD або NVMe зі збереженими томами, RAM, розрахована під найважчий робочий процес, а не під кількість ядер, свідомо встановлений ліміт продакшн-паралельності та обраний вами період зберігання. А далі — спостерігайте за реальним споживанням пам'яті й змінюйте розмір.
- Перейдіть на PostgreSQL, перш ніж додавати другий процес n8n.
- Виберіть вік і кількість для зберігання та припиніть зберігати успішні запуски, якщо ви дебажите лише збої.
- Встановіть ліміт продакшн-паралельності на одному інстансі.
- Переходьте на queue mode з Redis і воркерами з паралельністю 5 або більше, коли редактор починає гальмувати.
- Додайте обробники вебхуків за балансувальником навантаження, який не включає головний процес.
Ще одна деталь доступності має значення до того, як ви обіцяєте uptime: виконання, пропущені нодами Cron або Webhook, поки інстанс лежить або перезапускається, не можна відновити, тож розгортанням, чутливим до uptime, потрібен кешуючий проксі спереду. Резервні копії, налаштування reverse proxy і TLS та інструменти моніторингу лежать за межами цих джерел і потребують окремого дослідження.
Sources: Prerequisites | Deploy | n8n Docs, PostgreSQL vs SQLite for n8n: When to switch and how - LumaDock, Manage execution data | Deploy | n8n Docs, Control concurrency | Deploy | n8n Docs, Enable queue mode | Deploy | n8n Docs
