Варіанти розгортання n8n: self-hosting і режим черги
Практичний гід із розгортання n8n для команди: вибір способу встановлення та бази даних і момент переходу з main-режиму в режим черги.
Перевірено за документацією n8n .
До чого зобов'язує команду self-hosting n8n
Порівняння варіантів розгортання n8n починається з чесної оцінки того, що ви берете на себе. n8n документує self-hosting на власній інфраструктурі через Docker Compose, скрипт встановлення в один рядок чи інші методи й зазначає, що кожна self-hosted інсталяція запускає той самий основний продукт. Без ліцензійного ключа це безкоштовна Community-редакція; ключ відкриває Business або Enterprise.
Документація прямо говорить про компроміс: Docker рекомендовано для більшості потреб self-hosting, але self-hosting вимагає технічних знань про сервери, контейнери, масштабування і безпеку, а n8n Cloud рекомендовано тим, хто не має досвіду адміністрування серверів. Сприймайте це як питання кадрів, перш ніж воно стане питанням архітектури.
Важлива й частота релізів. n8n публікує нову мінорну версію майже щотижня, причому стабільна лінія призначена для продакшену, а beta може бути нестабільною. Фіксуйте стабільний реліз, а не стежте за beta. Номери версій змінюються щотижня, тож перевіряйте поточний реліз самі, а не довіряйте числу зі статті.
Одна операційна деталь легко губиться й дорого коштує згодом: навіть із PostgreSQL n8n рекомендує зберігати каталог .n8n постійним, бо в ньому лежать ключі шифрування, логи інстансу й ресурси системи контролю версій. Саме цей ключ шифрування ви згодом копіюватимете на кожен worker.
Sources: Host n8n | Deploy | n8n Docs, Install with Docker | Deploy | n8n Docs
Які варіанти розгортання n8n підходять вашій команді?
Документовані методи встановлення не взаємозамінні; кожен призначений для своєї ситуації, а неправильний вибір зазвичай виявляється пізніше у вигляді міграції.
Таблиця нижче підсумовує, як власна документація n8n позиціонує основні шляхи.
| Метод | Документоване призначення | Примітка |
|---|---|---|
| Docker Compose | Продакшен-розгортання з базами даних і додатковими сервісами | Рекомендований шлях для продакшену |
| Скрипт встановлення в один рядок | Швидке налаштування з мінімальною конфігурацією на Linux або macOS | Мінімальна конфігурація |
| npm | Локальна розробка або тестування | Застарілий з n8n 3.0 |
| Хмарні провайдери | Розгортання на керованій інфраструктурі | Кроки для кожного провайдера тут не розглядаються |
Sources: Host n8n | Deploy | n8n Docs
Встановлення в один рядок, Docker і Docker Compose
Встановлення в один рядок створене для швидкого налаштування з мінімальною конфігурацією на Linux або macOS. Це добрий спосіб побачити n8n у роботі, але командному інстансу потрібні база даних, резервні копії й визначений шлях оновлення, а саме для цього позиціонується Docker Compose: продакшен-розгортання з базами даних і додатковими сервісами.
На практиці команді найкраще написати Compose-файл, який можна закомітити й переглянути на рев'ю, бо цей самий файл документує підключення до бази, постійний том і змінні середовища, які згодом знадобляться режиму черги.
Sources: Host n8n | Deploy | n8n Docs
Хмарні провайдери, Kubernetes і застарілий шлях через npm
n8n перелічує цілі хмарного розгортання, зокрема AWS, Azure, Google Cloud Run і Google Kubernetes Engine, DigitalOcean, Hetzner, Heroku та OpenShift. Це варіанти, а не еквіваленти; вимоги окремих провайдерів виходять за межі цього гіда, тож читайте сторінку провайдера для обраної платформи.
Цей перелік показує, що варіанти розгортання n8n охоплюють дуже різні операційні моделі. Один droplet на DigitalOcean чи сервер у Hetzner дають одну машину, яку ви патчите самі. Контейнерна платформа на кшталт Cloud Run, Kubernetes Engine чи OpenShift дає планування й перезапуски, але вимагає від команди маніфестів, роботи з секретами й рішень щодо сховища, які Compose-файл тримає в одному місці.
Корисний спосіб вибору — запитати, на якій платформі ваша команда вже працює в продакшені. Запускати n8n поряд із системами, які ви моніторите й оновлюєте щотижня, зазвичай менш ризиковано, ніж вводити нову платформу заради одного навантаження, бо знання, яких вимагає n8n — сервери, контейнери, масштабування й безпека — це ті самі знання, яких уже вимагає ваша наявна платформа.
Шлях через npm заслуговує чіткого вердикту. Він задокументований як найкращий для локальної розробки чи тестування і є застарілим з n8n 3.0, натомість рекомендовано Docker Compose або встановлення в один рядок. Якщо командний інстанс сьогодні працює на npm, плануйте перехід, а не чекайте, доки оновлення змусить.
Sources: Host n8n | Deploy | n8n Docs
Яка база даних має бути в основі командного інстансу?
За замовчуванням self-hosted n8n використовує SQLite, збережений як файл ~/.n8n/database.sqlite. PostgreSQL опціональний і налаштовується через змінні середовища на кшталт DB_TYPE зі значенням postgresdb, DB_POSTGRESDB_HOST і DB_POSTGRESDB_PORT, який за замовчуванням 5432. n8n потрібні права створювати й змінювати власні схеми таблиць, тож надайте їх під час створення користувача бази.
- SQLite використовується за замовчуванням і не потребує налаштувань.
- PostgreSQL вмикається через DB_TYPE і змінні підключення.
- Користувач бази для n8n має вміти створювати й змінювати схеми таблиць.
Підтримка версій — рухома ціль. n8n підтримує дві останні активно підтримувані мажорні версії PostgreSQL, якими станом на липень 2026 були 17 і 18, плюс одну старішу мажорну — 16. Amazon Aurora PostgreSQL є експериментальним, а похідні на кшталт AlloyDB чи CockroachDB не підтримуються. Перелік мажорних версій змінюється щолистопада, тож звіряйте поточний список перед налаштуванням.
Редакційна рекомендація проста: починайте командний інстанс на PostgreSQL, а не на SQLite. Наступний розділ пояснює, чому цей вибір фактично є передумовою режиму черги, і старт саме з нього рятує від міграції бази під тиском.
Sources: Choose n8n's database | Deploy | n8n Docs, Enable queue mode | Deploy | n8n Docs
Чим SQLite і PostgreSQL відрізняються для командного інстансу
База за замовчуванням — не заглушка: SQLite зберігає облікові дані, минулі виконання й воркфлоу так само, як PostgreSQL, і невеликий командний інстанс може довго на ній працювати. Різниця проявляється в тому, що кожен вибір дозволяє далі, а не в якихось цифрах із документації, бо сторінки n8n описують підтримку й конфігурацію, а не порівняльну продуктивність.
Вирішальне обмеження — розподіленість. n8n зазначає, що режим виконання черги із SQLite не рекомендовано, а розподілене налаштування поверх SQLite не підтримується, бо Redis передає повідомлення, а база зберігає дані. Файлова база всередині одного контейнера не має ролі, коли кілька worker-процесів мають читати й писати ті самі записи виконань.
PostgreSQL також приносить обов'язки, яких немає у файлу. Ви обираєте підтримувану мажорну версію, надаєте користувачу n8n права створювати й змінювати схеми таблиць і вирішуєте, як налаштувати TLS між n8n і базою. n8n підтримує дві останні активно підтримувані мажорні версії, 17 і 18 станом на липень 2026, плюс 16, і просить перевіряти повторно, бо діапазон зсувається щолистопада.
| Аспект | SQLite | PostgreSQL |
|---|---|---|
| Конфігурація | За замовчуванням, змінні не потрібні | DB_TYPE і змінні підключення |
| Розташування | Файл ~/.n8n/database.sqlite | Зовнішній сервер, порт 5432 за замовчуванням |
| Режим черги | Не рекомендовано, розподілене налаштування не підтримується | Підтримується |
| Політика версій | Тут не задокументовано | Дві останні мажорні версії плюс одна старіша |
Ще два моменти легко зрозуміти неправильно. Amazon Aurora PostgreSQL є експериментальним, і підтримка версій n8n на нього не поширюється, а PostgreSQL-сумісні похідні на кшталт AlloyDB, CockroachDB чи YugabyteDB не підтримуються. Якщо хочете керовану базу, оберіть таку, що надає оригінальний PostgreSQL підтримуваної мажорної версії.
Sources: Choose n8n's database | Deploy | n8n Docs, Enable queue mode | Deploy | n8n Docs
Коли режим черги важливий і як він працює?
n8n документує, що робота в масштабі — з великою кількістю користувачів, воркфлоу чи виконань — потребує змін конфігурації, що режим черги дає найкращу масштабованість і що перегляд налаштувань збереження й очищення даних виконань може покращити продуктивність бази. Прочитати документацію n8n про режим черги разом зі сторінкою про масштабування варто ще до будь-яких змін.
Жоден задокументований поріг не визначає, коли починається «масштаб», тож перехід — це оцінка. Редакційні сигнали, які ми радимо відстежувати: обсяг виконань, що накопичується в чергу сам за собою, тривалі воркфлоу, які блокують інші, і повільний редактор під час виконань. Це орієнтири для рішення, а не виміряні пороги.
Сама архітектура проста. У режимі черги один головний інстанс обробляє таймери й виклики вебхуків, створює виконання й передає його ID у Redis. Worker забирає його, читає дані воркфлоу з бази, записує результати назад і повідомляє Redis. Масштабування — це додавання чи прибирання worker-ів.
Як виконання рухається в режимі черги
- Тригер: Головний інстанс обробляє таймери й вхідні виклики вебхуків.
- Створення виконання: Головний інстанс створює виконання для запущеного воркфлоу.
- У чергу: ID виконання передається в Redis.
- Забір: Worker бере ID виконання з Redis.
- Запуск: Worker читає дані воркфлоу з бази й виконує його.
- Звіт назад: Worker записує результати в базу й повідомляє Redis.
Серед варіантів розгортання n8n саме цей змінює вашу операційну модель, а не лише команду встановлення, тож ставтеся до нього як до поетапного кроку, а не як до типового вибору.
Sources: Scaling | Deploy | n8n Docs, Enable queue mode | Deploy | n8n Docs
Налаштування ключа шифрування, режиму виконань і Redis
Три передумови несуть більшість ризику, і нумерований список нижче подає їх у порядку застосування. Режим виконань має збігатися між процесами, ключ шифрування має бути спільним, щоб worker-и могли читати облікові дані, а Redis має бути доступним за хостом і портом, які ви налаштуєте; QUEUE_BULL_REDIS_HOST і QUEUE_BULL_REDIS_PORT за замовчуванням дорівнюють localhost і 6379.
- Встановіть EXECUTIONS_MODE у queue на головному інстансі.
- Задайте те саме значення на кожному worker-і.
- Скопіюйте ключ шифрування головного інстансу на кожен worker і вузол обробки вебхуків.
- Спрямуйте QUEUE_BULL_REDIS_HOST і QUEUE_BULL_REDIS_PORT на ваш Redis.
- Переконайтеся, що інстанс працює на PostgreSQL, а не на SQLite.
Деякі підтеми режиму черги задокументовані детальніше, ніж охоплює цей гід, зокрема вузли обробки вебхуків із маршрутизацією шляхів на балансувальнику, обмеження зберігання бінарних даних і ліміти розміру відповіді вебхука. Якщо ваші воркфлоу передають бінарні дані чи повертають великі відповіді вебхуків, прочитайте ці сторінки перед переходом.
Sources: Enable queue mode | Deploy | n8n Docs
Worker-и, паралельність і межі масштабування
Worker-и запускаються командою n8n worker або образом n8nio/n8n з аргументом worker у Docker. Вони можуть надавати опціональні endpoint-и здоров'я й готовності, зокрема /healthz, якщо увімкнено QUEUE_HEALTH_CHECK_ACTIVE. Паралельність за замовчуванням дорівнює 10, і n8n рекомендує 5 чи більше, бо низька паралельність, розподілена між багатьма worker-ами, може вичерпати пул підключень до бази.
Цей пул — практична стеля, у яку більшість команд упирається першою. Розраховуйте кількість підключень PostgreSQL як worker-и помножені на паралельність до того, як додавати нові worker-и, а не після.
Опціональні endpoint-и варто вмикати завчасно, а не під час інциденту. Endpoint готовності, який повідомляє, чи працюють підключення worker-а до бази й Redis, перетворює розмите сповільнення на конкретну відповідь і дає балансувальнику чи оркестратору щось конкретне, коли worker втрачає Redis.
Висока доступність із кількома головними інстансами задокументована як доступна в self-hosted Enterprise і недоступна в n8n Cloud. Усі головні інстанси мають працювати в режимі черги на PostgreSQL і Redis, мати однакову версію n8n, встановити N8N_MULTI_MAIN_SETUP_ENABLED у true й стояти за sticky-сесіями, а лідер виконує задачі типу at-most-once. Перегляд активних worker-ів у Settings, далі Workers, також лише для Enterprise. Залиште це командам, яким справді потрібна висока доступність і які мають цю ліцензію; один головний інстанс плюс кілька worker-ів — простіша модель.
Sources: Enable queue mode | Deploy | n8n Docs
Що змінюється в щоденній експлуатації після переходу
Режим черги змінює те, як робота потрапляє в базу і як ви міркуєте про повільний воркфлоу. В одному головному процесі тригер, виконання і його результат живуть в одному місці. Коли з'являються worker-и, запуск торкається головного інстансу, Redis і бази, перш ніж завершитися, тож розслідування починається з питання, який із цих трьох компонентів нездоровий.
Sources: Enable queue mode | Deploy | n8n Docs
Поетапний шлях від одного контейнера до режиму черги
Разом варіанти розгортання n8n утворюють послідовність, а не меню. Почніть із Docker Compose і PostgreSQL підтримуваної мажорної версії, дотримуючись чекліста на початку гіда. Такий інстанс уже відповідає всім передумовам режиму черги, крім Redis.
Коли один головний процес стає вузьким місцем, додайте Redis, задайте режим виконань на main і worker-ах і почніть з невеликої кількості worker-ів із паралельністю щонайменше 5. Додавайте worker-и лише після перевірки пулу підключень до бази. Тримайте вузли обробки вебхуків у резерві на випадок, коли обмеженням є саме обсяг вхідних вебхуків.
Пропонований поетапний розгортання для командного інстансу
- Compose плюс Postgres: Запустіть Docker Compose з PostgreSQL підтримуваної мажорної версії.
- Додати Redis: Введіть Redis і задайте змінні підключення черги.
- Спільний ключ: Скопіюйте ключ шифрування головного інстансу на кожен worker.
- Перемкнути режим: Встановіть режим виконань у queue на main і worker-ах.
- Масштабувати worker-и: Додавайте worker-и з паралельністю щонайменше п'ять, стежачи за пулом підключень.
Одне застереження обрамлює все вище: усе це походить із власної документації n8n, яка дає поради щодо архітектури й конфігурації, а не незалежні бенчмарки, цифри вартості чи дані про надійність. Власне навантажувальне тестування залишається єдиним способом дізнатися, де ваш інстанс не витримує.
Sources: Host n8n | Deploy | n8n Docs, Choose n8n's database | Deploy | n8n Docs, Enable queue mode | Deploy | n8n Docs
