n8n self-hosted vs cloud: один webhook-воркфлоу у продакшені
Порівняння n8n self-hosted і cloud за критеріями: налаштування, ліміти payload, креденшели, оновлення, ретенція, масштабування, моніторинг.
Перевірено за наведеними джерелами .
Обсяг: один воркфлоу, два шляхи хостингу
Уявіть найпростішу корисну автоматизацію: нода Webhook отримує JSON-payload, нода HTTP Request викликає зовнішній API, а невелика трансформація даних формує відповідь. На вашому ноутбуці це працює. Питання в порівнянні n8n self-hosted vs cloud не в тому, чи запуститься цей воркфлоу — n8n документує обидва варіанти розгортання як придатні для продакшену, — а в тому, що оточує його, коли надходить реальний трафік.
Документація прямо говорить про стартову різницю: Cloud не потребує ані встановлення, ані технічної експертизи для запуску, тоді як self-hosting вимагає налаштування через npm, Docker або сервер, плюс експертизи для конфігурації. Документація також рекомендує self-hosting досвідченим користувачам, зазначаючи, що помилки можуть призвести до втрати даних, проблем із безпекою та простоїв. Це порада, а не вимірювання, але вона задає тон кожному критерію нижче.
Ще одне уточнення обсягу. Для цієї статті не було доступних цін, бенчмарків чи порівнянь затримок, тому порівняння залишається якісним і зосередженим на механізмах. Перевіряйте поточну сторінку цін n8n щодо цифр за планами, а не довіряйте числам, наведеним деінде.
Налаштування, база даних і сама webhook-URL
Для self-hosting n8n перелічує кілька шляхів встановлення й рекомендує Docker Compose для продакшен-розгортань із базами даних та додатковими сервісами. За замовчуванням self-hosted інстанс зберігає креденшели, минулі виконання й воркфлоу в SQLite, а PostgreSQL налаштовується через змінні середовища. Це замовчування нормальне для одного оцінювального інстансу й стає обмеженням пізніше — саме тому рішення щодо бази даних має бути ухвалене до першої публікації в продакшені, а не після.
Нода Webhook поводиться однаково в обох середовищах. Вона дає тестову URL і окрему продакшен-URL, і n8n реєструє продакшен-вебхук, коли ви публікуєте воркфлоу. Практично це означає, що воркфлоу, прототипований деінде, потрібно перетестувати після публікації в цільовому середовищі, бо URL, яку використовує ваш клієнт, — не та, на яку ви клікали під час розробки.
Розмір payload — це те, де шляхи розходяться. Максимальний payload вебхука становить 16MB, і лише self-hosted користувачі можуть змінити його через змінну середовища N8N_PAYLOAD_SIZE_MAX. Якщо ваша інтеграція з API отримує великі завантаження або об'ємні JSON-документи, це єдине налаштування може саме по собі вирішити питання хостингу. Надана документація не пропонує безпечних верхніх значень і не описує вплив на пам'ять від його підвищення, тож ставтеся до будь-якого збільшення як до того, що треба протестувати.
Креденшели, ключі шифрування та переїзд між варіантами
Self-hosted інстанс створює випадковий ключ шифрування під час першого запуску і зберігає його в домашній теці n8n; цей ключ шифрує ваші креденшели, а в режимі черги кожен воркер має його поділяти. Знати, де живе цей ключ — і подбати, щоб він пережив перезбирання контейнера, — це різниця між рутинним рестартом і ранком, витраченим на повторне введення API-токенів. Надані джерела не документують процедуру резервного копіювання чи ротації, тож вибудовуйте власне поводження свідомо.
Портативність асиметрична. Автоматизованої міграції з Cloud на self-hosted немає: воркфлоу експортуються й імпортуються вручну, а креденшели не можна експортувати з Cloud із міркувань безпеки, тож їх доведеться вводити руками. Натомість self-hosted інстанси мають CLI-команди експорту й імпорту, включно з експортом креденшелів у відкритому тексті, призначеним для переїзду між інсталяціями з різними секретними ключами. Ця зручність водночас є ризиком, бо серверний CLI обходить контроль доступу, а експорт відкриває чутливі значення в чистому вигляді.
Якщо переїзд бодай імовірний, плануйте його як ручну вправу: експортуйте воркфлоу, введіть заново кожен креденшел, а потім перевірте кожне API-з'єднання, перш ніж перенаправляти вебхук.
Оновлення, дані виконань і ретенція
Відповідальність за оновлення — одна з найчіткіших ліній у порівнянні n8n self-hosted vs cloud. У Cloud версія рантайму, гілка релізів Beta чи Stable, частота оновлень і вікно обслуговування — це налаштування, якими керує власник інстансу, а зміна версії спричиняє короткий рестарт приблизно на хвилину-дві. Незалежно від обраної частоти, n8n завжди застосовує оновлення безпеки та стабільності автоматично. Ви міняєте фіксацію версії на те, що патчі накочує хтось інший.
Self-hosted команди повністю володіють календарем оновлень — це перевага, коли community-нода або кастомне налаштування чутливі до змін версій, і зобов'язання, коли за це ніхто не відповідає.
Дані виконань слідують тому самому патерну. Cloud автоматично чистить логи виконань за планом — наприклад, плани Pro зберігають щонайбільше 25000 виконань із ретенцією 30 днів. Self-hosted інстанси керують ретенцією через змінні EXECUTIONS_DATA зі значеннями очищення за замовчуванням 336 годин і 10 000 виконань. Одне застереження, що болить користувачам SQLite: видалені рядки не звільняють місце на диску без VACUUM.
Масштабування, моніторинг і обмеження функцій
Cloud накладає ліміти RAM і CPU за планом — задокументовано від 320MiB на Trial і Starter до 4096MiB на Enterprise — і застосовує контроль конкурентності на рівні інстансу до продакшен-виконань, тобто саме тих, які стартує ваш вебхук, ставлячи в чергу все понад ліміт. Цифри конкурентності за планами живуть на сторінці цін, а не в тексті документації, використаному тут.
Масштабування self-hosted означає режим черги з Redis і воркер-процесами. Розподілені конфігурації не підтримуються на SQLite — це друга причина обрати PostgreSQL рано. У режимі черги відповіді вебхука ретранслюються через Redis із типовим обмеженням розміру 64 MiB, що налаштовується через N8N_WEBHOOK_RESPONSE_RELAY_SIZE_MAX; вивантаження більших тіл потребує свіжої версії n8n на кожному main-інстансі плюс спільного сховища. Режим multi-main доступний лише в Enterprise і недоступний у Cloud.
Моніторинг — найочевидніший розкол у порівнянні n8n self-hosted vs cloud. Ендпоінт /metrics існує лише в self-hosted у всіх редакціях і вимкнений, доки ви явно його не увімкнете; /healthz доступний в обох. Стрімінг логів у зовнішні системи — це Enterprise і в Cloud, і в self-hosted, тож сам по собі self-hosting його не відкриває.
Обмеження функцій заслуговує окремого прочитання. Безкоштовна self-hosted редакція Community не включає SSO, середовища, проєкти, зовнішні секрети, стрімінг логів і контроль версій через Git, але включає режим черги. Реєстрація цієї безкоштовної редакції через email відкриває теки, дебаг у редакторі та кастомні дані виконань. Переліки функцій змінюються, і сама документація вказує на сторінку цін як джерело істини.
Sources: S7, S8, S5, S14, S15, S3
n8n self-hosted vs cloud: компроміси, невідомі й як вирішувати
Стосовно одного воркфлоу з вебхуком і API порівняння n8n self-hosted vs cloud зводиться до кількох чесних компромісів. Cloud дає керовані оновлення, автоматичне очищення й відсутність турбот про інфраструктуру ціною фіксованої стелі payload, ресурсів, прив'язаних до плану, черг конкурентності на рівні інстансу та відсутності ендпоінта метрик. Self-hosting дає бажані розмір payload, політику ретенції, метрики й масштабування в режимі черги в обмін на володіння базою даних, ключем шифрування, оновленнями та тими сценаріями відмов, про які документація попереджає навіть досвідчених користувачів.
Кілька речей лишаються невідомими з доступної документації. Тут немає цін, немає цифр конкурентності за планами, немає процедури резервного копіювання й відновлення для self-hosted інстансів і немає бенчмарку, що порівнює той самий воркфлоу в обох середовищах. Ставтеся до цих прогалин як до власних завдань з оцінювання, а не припускайте паритет.
Робоча послідовність: прототипуйте там, де можете почати найшвидше; якщо хоститеся самі — визначте базу даних, постійний том і поводження з ключем шифрування до першої публікації в продакшені; перетестуйте після публікації, бо саме тоді реєструється продакшен-URL; і звіряйте поточні ліміти на сторінці цін, перш ніж брати зобов'язання.
