Режим черги n8n на Hostinger VPS: вправа з бюджетного розгортання
Ця вправа розгортає режим черги n8n на Hostinger VPS: передумови, підбір розміру, Redis і PostgreSQL, перевірка роботи воркерів.
Перевірено за наведеними джерелами .
Огляд завдання: що ви створите і перевірите
Ця стаття описує редакційну вправу з розгортання режиму черги n8n на Hostinger VPS: перехід від односерверного налаштування до main-процесу, підтримуваного Redis і одним або кількома воркерами, без одразу стрибка до сервера корпоративного розміру. Офіційна документація n8n з масштабування описує режим черги як режим виконання, що забезпечує найкращу масштабованість, і саме тому команди зрештою виходять за межі одного контейнера. Вправа нижче утримує все на одній скромній віртуальній машині, щоб технічний лідер міг побачити, що насправді вимагає цей перехід на практиці, а не лише читати про нього абстрактно.
Завдання: побудувати працюючий стек n8n у режимі черги — main-процес, Redis, PostgreSQL і принаймні один воркер — на одному бюджетному VPS, а потім перевірити, що запланований або вручну запущений робочий процес справді виконується воркером, а не main-процесом. Це подано як практичну вправу для виконання на вашій власній інфраструктурі; нижче ми описуємо документовані можливості та рекомендований шлях, але самі ми не виконували кожен крок і не вимірювали результат, тому сприймайте рекомендації щодо розміру як відштовхну точку, а не перевірений бенчмарк.
Sources: Scaling | Deploy | n8n Docs
Передумови, вхідні дані та обмеження
Передумови: акаунт Hostinger VPS (або еквівалентний провайдер, хоча нотатки щодо розміру нижче специфічні для Hostinger), встановлені на цьому VPS Docker і Docker Compose, достатня впевненість у роботі з Linux-терміналом для редагування файлів .env і запуску compose-команд, а також наявне налаштування n8n, яке ви вже розумієте у звичайному режимі без черги. Попередній досвід адміністрування Redis чи PostgreSQL не потрібен, але варто бути готовим читати логи контейнерів, якщо щось не запускається з першої спроби. Цей розділ описує саме те, що потрібно для режиму черги n8n на Hostinger VPS, а не те, що потрібно для звичайного сервера.
Вхідні дані та обмеження: ця вправа обмежена одним VPS, на якому працюють усі компоненти разом — main-процес, Redis, PostgreSQL і воркери — а не мультисерверним чи мульти-main налаштуванням. Головне обмеження — бюджет: таке налаштування потребує більше vCPU, ніж абсолютний мінімум (розмір визначено в наступному розділі), а власна документація n8n не рекомендує запускати EXECUTIONS_MODE=queue з базою даних SQLite, що виключає найлегшу можливу конфігурацію. Тож вправа передбачає тариф VPS із більшим запасом потужності, ніж абсолютний мінімум n8n для односерверного налаштування, і контейнер PostgreSQL із самого початку.
Sources: Enable queue mode | Deploy | n8n Docs, Parameters and limits of hosting plans in Hostinger, What are the VPS requirements for n8n?
Підбір розміру для режиму черги n8n на Hostinger VPS
Власний посібник Hostinger щодо вимог для VPS вказує абсолютний мінімум — 1 ядро vCPU, 2 ГБ RAM і 20 ГБ SSD-накопичувача — лише для того, щоб n8n взагалі запустився, але ця цифра описує односерверне налаштування, а не режим черги. Окремий посібник Hostinger щодо режиму черги рекомендує щонайменше 2 vCPU, коли Redis, PostgreSQL, main-процес і воркери працюють разом, і називає власний тариф KVM 2 комфортним варіантом для базового налаштування з трьома воркерами. Це рекомендації постачальника, а не результати незалежного навантажувального тестування, тож сприймайте їх як відштовхну точку для підбору розміру режиму черги n8n на Hostinger VPS, а не як гарантію.
Власна сторінка обмежень тарифів Hostinger зазначає, що ці показники vCPU, RAM і трафіку можуть змінюватися без попередження, тож сприймайте таблицю нижче як миттєвий знімок і перевіряйте поточні цифри у своїй панелі VPS, перш ніж орієнтувати на них покупку.
Той самий посібник Hostinger, посилаючись на документацію n8n, повідомляє, що пам'ять часто важливіша за процесор для продуктивності n8n, і це має значення, коли Redis і PostgreSQL конкурують за RAM поряд із main-процесом і воркерами. Це міркування має практичний наслідок для вибору тарифу: оскільки навантаження не є процесорозалежним, у разі подальшого оновлення варто пріоритизувати RAM, а не додаткові vCPU. Автор контенту Hostinger робить пов'язаний висновок про це саме налаштування:
| Тариф | Ядра vCPU | RAM | Трафік | Відповідність за джерелами |
|---|---|---|---|---|
| Абсолютний мінімум для n8n (будь-який VPS) | 1 | 2 ГБ | Не задокументовано | Загальний посібник Hostinger з n8n наводить це як нижню межу, не розраховану на режим черги |
| Hostinger KVM1 | 1 | 4 ГБ | 4 ТБ | Нижче власної рекомендації Hostinger щодо 2 vCPU для режиму черги |
| Hostinger KVM2 | 2 | 8 ГБ | 8 ТБ | Названий комфортним варіантом для main, Redis, PostgreSQL і трьох воркерів |
На нашу думку, одразу обрати тариф на рівні KVM2 — прагматичне рішення для цієї вправи, оскільки намагання втиснути main, Redis, PostgreSQL і воркери в абсолютний мінімум специфікацій здебільшого лише провокує зайве усунення несправностей. Щодо персистентності, власна документація Redis попереджає, що самого лише RDB-знімка недостатньо, якщо потрібно мінімізувати втрату даних при неочікуваній зупинці Redis, і натомість рекомендує стандартну політику AOF із fsync на диск кожну секунду; також варто зазначити, що змінна імені користувача Redis, яку відкриває n8n, потребує Redis версії 6 або новішої.
Sources: Configuring n8n in queue mode for improved scalability, Parameters and limits of hosting plans in Hostinger, What are the VPS requirements for n8n?, VPS Hosting | Powerful KVM-based Virtual Private Server, Redis persistence, Queue mode | Deploy | n8n Docs
Налаштування режиму черги та розгортання main і воркерів
Офіційний довідковий приклад Docker Compose від n8n встановлює EXECUTIONS_MODE=queue на кожному контейнері та спрямовує їх до сервісу Redis з назвою redis, із перевірками стану, увімкненими безпосередньо у файлі compose. У тому самому прикладі сервіс воркера повторно використовує спільний блок конфігурації main-сервісу та просто перевизначає команду для запуску в режимі worker замість запуску звичайного процесу, не потребуючи власного окремого образу чи збірки.
Кожен запущений воркер працює як власний екземпляр Node.js у режимі main, згідно з офіційною документацією n8n, і саме так режим черги розподіляє виконання між кількома процесами замість одного. n8n рекомендує встановлювати конкурентність воркера на рівні 5 або вище, хоча також попереджає, що поєднання низької конкурентності з великою кількістю воркерів може виснажити пул з'єднань бази даних. У режимі черги встановлення N8N_CONCURRENCY_PRODUCTION_LIMIT у будь-яке значення, відмінне від -1, перевизначає флаг --concurrency команди воркера, тоді як пов'язаний елемент керування конкурентністю у звичайному режимі стосується лише продакшн-виконань.
Відповідь у форумі спільноти n8n від січня 2022 року зазначає, що немає реальної різниці між Docker-образами worker, main і webhook, і що між ними змінюється лише команда запуску. Ми радимо ставитися до цієї примітки форуму з обережністю: це лише одна відповідь спільноти з 2022 року, позначена як потенційно застаріла, а не гарантія, що сьогоднішні образи worker і main досі поводяться ідентично. Як редакційну обережність ми пропонуємо встановити один N8N_ENCRYPTION_KEY і поширити його на main та кожен контейнер воркера з самого початку, щоб конфігурація, пов'язана з обліковими даними, залишалася узгодженою в міру додавання воркерів.
Sources: Enable queue mode | Deploy | n8n Docs, n8n-hosting/docker-compose/withPostgresAndWorker/docker-compose.yml at main · n8n-io/n8n-hosting · GitHub, Control concurrency | Deploy | n8n Docs, N8N Queue mode load testing - Questions - n8n Community
Критерії завершення, усунення несправностей та підсумки
Критерії завершення цієї вправи: офіційна документація n8n з моніторингу стверджує, що ендпоінт /healthz/readiness повертає HTTP 200, щойно встановлено з'єднання з базою даних, що є корисною першою перевіркою для main-процесу. Для воркерів зокрема і ендпоінт перевірки стану, і ендпоінт /metrics за замовчуванням вимкнені, тож для їх використання потрібно свідомо увімкнути QUEUE_HEALTH_CHECK_ACTIVE і флаг метрик. Посібник Hostinger із запуску режиму черги n8n на Hostinger VPS пропонує підтверджувати фактичну роботу, перевіряючи логи воркера на наявність запису 'Worker started execution' після запуску робочого процесу.
Якщо нічого не виконується, два найімовірніші винуватці — саме ті, на які прямо вказує документація: обмеження SQLite, вже згадане вище серед передумов, або налаштування конкурентності воркера, занадто низьке для кількості запущених воркерів, як пояснювалося раніше, коли ми розглядали конкурентність. Перевірте логи контейнерів як main-процесу, так і кожного воркера, перш ніж припускати, що проблема в самому Redis.
Підсумок: якщо ваші воркери реєструються і запущений робочий процес з'являється в їхніх логах, у вас справді працює налаштування режиму черги n8n на Hostinger VPS, свідомо обмежене однією машиною, а не розподіленим кластером. Ми вважаємо, що виконати цю вправу на бюджетному VPS, перш ніж братися за більший рахунок у хмарі, — гарне використання кількох годин, оскільки це виявляє кожне конфігураційне рішення, яке вимагає режим черги, — спільні ключі шифрування, PostgreSQL, конкурентність воркерів — без того, щоб команда спершу бралася за більшу інфраструктуру. Сприймайте масштабування за межі одного VPS, окремі хости для Redis і Postgres або налаштування з кількома main як подальшу амбітну мету, а не частину цієї вправи.
Sources: Monitor n8n | Deploy | n8n Docs, Configuring n8n in queue mode for improved scalability, Enable queue mode | Deploy | n8n Docs
