Контроль версій воркфлоу n8n: Git, експортований JSON чи ручні бекапи
Контроль версій воркфлоу n8n: нативний Git, експорт JSON і ручні бекапи за критеріями історії, рев’ю, відкату та вимог до редакції.
Перевірено за наведеними джерелами .
Три підходи до контролю версій воркфлоу n8n
Команди, яким потрібен контроль версій воркфлоу n8n, зазвичай обирають між нативним Git source control, експортованими JSON-файлами та ручними бекапами. У цьому порівнянні кожен підхід оцінюється за чотирма критеріями: історія, рев’ю, відкат і вимоги до редакції.
Підтвердження беремо з документації та блогу n8n, тож описаний тут контроль версій воркфлоу n8n відображає те, що документує n8n, а прогалини ми позначаємо по ходу.
Sources: Use source control and environments | Administer | n8n Docs, Workflow Versioning for Reliable Automation and Maintenance – n8n Blog
Git source control: нативний контроль версій n8n
Згідно з документацією n8n, нативний Git source control доступний лише в планах Business і Enterprise. Власники інстансу або адміністратори вмикають і налаштовують його, а адміністратори проєктів можуть робити push, але не pull.
Історія створюється через push, а в n8n commit і push відбуваються разом. Документація також зазначає, що інтеграція не є повноцінним контролем версій і не пропонує рев’ю на кшталт pull request, тож рев’ю відбувається у вашому Git-провайдері. Push надсилає збережену версію воркфлоу, а не опубліковану, разом із тегами та заглушками credentials з ID, назвою і типом, тому секрети не потрапляють у коміти. Дані рядків data table не надсилаються. Власний блог n8n, який є рекомендацією вендора, описує diff, що показує додані, змінені та видалені ноди перед push або pull, і стверджує, що захищені інстанси не дозволяють прямо редагувати ресурси під source control.
Відкат означає pull раннього стану репозиторію, а pull перезаписує локальні зміни, які не були надіслані. Документація n8n додає, що він не виявляє конфліктів воркфлоу, що репозиторій є джерелом істини, а push перезаписує Git, тому радять односпрямований потік. Ми вважаємо, що односпрямований потік варто запровадити як жорстке правило, бо інструмент не попередить, коли двоє людей розійдуться.
Sources: Use source control and environments | Administer | n8n Docs, Use Git in n8n | Administer | n8n Docs, Push and pull changes | Administer | n8n Docs, Workflow Versioning for Reliable Automation and Maintenance – n8n Blog
Контроль версій n8n через експортований JSON і ручні бекапи
Документація n8n каже, що JSON воркфлоу можна експортувати чи імпортувати через меню редактора, копіювання-вставлення, CLI або API. Self-hosted Server CLI може експортувати один файл на воркфлоу, що описано як корисне для версіонування, а також експортувати конкретну історичну версію. Документація також радить для нових задач використовувати n8n CLI замість Server CLI і планує вилучити експорт та імпорт Server CLI, без визначеної дати.
Документація наводить кілька застережень щодо експорту та відновлення. Чекліст нижче — наш підсумок.
Публічний API доступний на Cloud Starter, Pro і Enterprise та в усіх self-hosted редакціях, але не на безкоштовному пробному періоді, тож скриптовий експорт JSON через API можливий без плану Business, хоча ця документація не описує, як спроєктувати воркфлоу для бекапу. Для Community Edition власний блог вендора за серпень 2026 року пропонує воркфлоу за розкладом, що зберігає змінений JSON у приватний Git-репозиторій. Він називає це процесом бекапу, а не заміною нативних середовищ, і радить тестувати відновлення. Ми вважаємо це розумним компромісом для команд на Community Edition, якщо ніхто не плутатиме його із середовищами.
Ручні бекапи зводяться до ручного завантаження воркфлоу як JSON із меню редактора та зберігання файлу в обраному вами місці.
Sources: Use the command line | Deploy | n8n Docs, Export and import | Build | n8n Docs, n8n API | Connect | n8n Docs, Workflow Versioning for Reliable Automation and Maintenance – n8n Blog
Вбудована історія воркфлоу та іменовані версії
Вбудована історія воркфлоу зберігає версії в базі даних інстансу n8n, а не в Git. Документація описує повну історію на Enterprise, у Cloud чи self-hosted, тоді як усі користувачі отримують версії за останні 24 години, а Cloud Pro — за п’ять днів. Версію можна відновити, клонувати в новий воркфлоу або завантажити як JSON.
Іменовані версії, які n8n ніколи не видаляє автоматично, доступні на Cloud Pro та Enterprise і на self-hosted Business та Enterprise.
Sources: View change history | Build | n8n Docs
Порівняння історії, рев’ю, відкату та редакції
Таблиця застосовує однакові чотири критерії до трьох підходів, розділяючи експортований JSON на форму за розкладом у Git і ручні експорти, а для повноти додає вбудовану історію воркфлоу. Користуйтеся нею, щоб обрати серед підходів до контролю версій воркфлоу n8n для вашої редакції.
| Підхід | Історія | Рев’ю | Відкат | Редакція |
|---|---|---|---|---|
| Нативний Git source control | Створюється при кожному push | У Git-провайдері, не в n8n | Pull раннього стану репозиторію; перезаписує непересланi зміни | Business, Enterprise |
| Експорт JSON у Git за розкладом | Git-історія змінених файлів, за пропозицією блогу n8n | Unknown | Повторний імпорт; збіжні ID можуть бути перезаписані при імпорті Server CLI | Публічний API на Cloud Starter, Pro, Enterprise і в усіх self-hosted; CLI поза self-hosted — Unknown |
| Ручні експорти | Лише те, що ви самі зберігаєте й іменуєте | Unknown | Повторний імпорт вручну; поведінка перезапису при імпорті в редакторі — Unknown | Unknown |
| Вбудована історія воркфлоу | Версії в базі даних інстансу | Unknown | Відновити, клонувати або завантажити як JSON | Повна на Enterprise; 24 години для всіх користувачів; п’ять днів на Cloud Pro |
Клітинки з позначкою Unknown — це пункти, не вказані в документації n8n, а не доказ відсутності можливості.
Sources: Use source control and environments | Administer | n8n Docs, Use Git in n8n | Administer | n8n Docs, View change history | Build | n8n Docs, Use the command line | Deploy | n8n Docs, Export and import | Build | n8n Docs, n8n API | Connect | n8n Docs, Workflow Versioning for Reliable Automation and Maintenance – n8n Blog
Що залишається невідомим
Кілька пунктів у переглянутих матеріалах лишаються непідтвердженими. Не визначено, чи Community Edition зберігає історію воркфлоу довше за 24 години, як і точні кроки для pull конкретного старішого Git-коміту.
Джерело щодо Server CLI, яке ми мали, було обрізане, а документація n8n позначає його пакети як Preview. Ручні бекапи ґрунтуються на висновках із документації про експорт. Нарешті, ніщо з цього не походить із власного тестування.
Sources: Use Git in n8n | Administer | n8n Docs, View change history | Build | n8n Docs, Use the command line | Deploy | n8n Docs, Export and import | Build | n8n Docs
Редакційні рекомендації
Це наші пропозиції, а не перевірені результати, і вони випливають із наведеного порівняння.
- На Business або Enterprise використовуйте нативний Git з односпрямованим потоком dev, staging, production та рев’ю у вашому Git-провайдері.
- На Community Edition налаштуйте експорт JSON за розкладом, по одному файлу на воркфлоу, у приватний Git-репозиторій і розглядайте його як бекап з історією.
- Ручні експорти залиште для разових знімків: називайте їх, зберігайте приватно й не покладайтеся на них як на командну історію.
- Протестуйте відновлення на непродакшн-інстансі та перевірте поведінку перезапису ID під час імпорту.
Ми ставимо на те, що тест відновлення важливіший за вибір підходу, бо бекап, який ніхто не відновлював, — це лише надія.
