Обновление n8n с 1.x до 2.x: проверяем сценарии, код и возврат

MAATRIX · 17 октября 2026 · 9 мин чтения

У автоматизации есть особенность: пока она работает, о ней почти не думают. Заявка превращается в строку таблицы, документ уходит на согласование, бот присылает результат. Обновление платформы внезапно напоминает, сколько рабочих процессов держится на нескольких цветных прямоугольниках.

Переход n8n с 1.x на 2.x нельзя свести к замене тега Docker-образа. Во второй основной версии изменились правила выполнения кода, некоторые настройки безопасности и поведение отдельных сценариев. Правильный вопрос перед обновлением — не «открылась ли панель», а «получит ли каждый рабочий процесс тот же ожидаемый результат».

Начните с перечня автоматизаций, которым нельзя потеряться

Запишите установленную версию n8n, способ запуска, тип базы, расположение файлов и наличие workers. Выделите активные сценарии, внешние webhooks, задания по расписанию и процессы, находящиеся в ожидании. Длинное согласование документа может пережить обычное окно обновления и потребовать отдельной проверки.

Для каждого важного сценария нужен владелец и пример входных данных. Если никто не может объяснить назначение автоматизации, не удаляйте её сразу: посмотрите расписание, последние исполнения и получателей. Иногда «старый тест» исправно отправляет единственный финансовый отчёт компании.

Разделите сценарии по риску. Чтение открытой страницы, изменение карточки клиента и отправка платёжного запроса требуют разной строгости. Для операций с внешним эффектом заранее предусмотрите учебные учётные записи и защиту от повторов.

Сохраните идентификатор текущего выпуска, compose-файл или другой способ запуска, список переменных и установленные community nodes. Версии дополнений должны быть известны. Их совместимость не следует автоматически из совместимости самой n8n.

Что действительно меняется во второй версии

В официальном перечне несовместимых изменений собраны обязательные проверки. Среди них — выполнение Code nodes через task runners, более строгий доступ к окружению и файлам, отключённые по умолчанию потенциально опасные узлы и обновлённая модель публикации сценариев.

Если рабочая база самой n8n находится в MySQL или MariaDB, её нужно перенести на поддерживаемый backend до обновления. Это не означает удаления узла MySQL для интеграций: хранение внутреннего состояния платформы и обращение сценария к сторонней базе — разные функции.

Отдельно проверьте старый Start node и вложенные сценарии с ожиданием. Изменённое поведение возвращаемых данных способно пройти незамеченным, если тестировать только факт завершения. Нужен именно ожидаемый итоговый объект, который получает родительский сценарий.

Не включайте все прежние разрешения одной переменной ради быстрого исчезновения ошибок. Сначала выясните, какое действие требуется конкретному сценарию. Иначе обновление закончится переносом старых рисков в новую панель.

Резервная копия должна открывать credentials

Экспорт сценариев полезен, но не является полной резервной копией экземпляра. Нужны согласованная база, необходимые файлы и ключ шифрования credentials. В зависимости от установки ключ находится в конфигурации либо задаётся через N8N_ENCRYPTION_KEY.

Сохраните его отдельно и защищённо. Документация ключа шифрования объясняет его роль; без соответствующего ключа восстановленная база может оказаться бесполезной для подключения к сервисам. Не публикуйте ключ вместе с диагностическим выводом окружения.

Сделайте копию штатным способом используемой базы и проверьте восстановление в изолированном окружении. Для SQLite нельзя бездумно копировать один файл в момент записи, игнорируя режим работы и связанные журналы. Для PostgreSQL выберите согласованный способ резервирования и сохраните параметры восстановления.

Если используются внешнее хранилище бинарных данных или подключённые каталоги, включите их в план. Проверьте, какие файлы нужны для ожидающих и повторных исполнений. Резервная копия должна соответствовать одному понятному состоянию, а не состоять из базы понедельника и файлов среды.

Стенд не должен исполнять чужую рабочую жизнь

Поднимите отдельный экземпляр на копии данных с новым адресом. До запуска отключите исходящие действия и производственные триггеры предусмотренным для вашей установки способом. Не позволяйте восстановленным расписаниям немедленно отправить настоящие письма или повторить обработку заказов.

Для проверки интеграций создайте отдельные credentials и тестовые каналы. Если внешний сервис не предоставляет sandbox, используйте безопасные учебные сущности и явно ограниченный набор операций. Проверка обновления не должна становиться второй независимой системой продаж.

Стенд полезно разместить на отдельном VPS MAATRIX. Для небольшого экземпляра с PostgreSQL и task runner отправной точкой может быть Heka Standard с 4 vCPU и 8 GB памяти. Лёгкие сценарии иногда требуют меньше, но обработка крупных документов, несколько одновременных исполнений и ИИ-интеграции меняют расход памяти.

Выбирайте поддерживаемую Ubuntu или Debian и фиксируйте версии контейнеров. Стоимость внешних ИИ-API не входит в ресурсы VPS. Размер диска рассчитывайте по базе исполнений, бинарным данным и правилам очистки, иначе проверочный стенд быстро вырастет из учебного размера.

Проверка Code nodes — самостоятельный этап

Task runner исполняет код в отдельном контексте. Это означает, что привычный доступ к окружению, файлам и установленным библиотекам может измениться. Для производственной изоляции изучите внешний режим в руководстве task runners.

При использовании Docker внешний runner запускается отдельным образом n8nio/runners; его версия должна соответствовать используемой версии n8n по документации. Настройки связи, общий секрет и внутренние адреса нужно согласовать. Не публикуйте служебный порт runner в интернет только ради упрощения подключения.

Сначала сделайте маленький проверочный сценарий: Manual Trigger, безопасный Code node и просмотр результата. Он должен получить учебное значение, преобразовать его и вернуть ожидаемую структуру. Затем проверьте необходимые сторонние библиотеки и ограничения. Пустой успешный запуск не доказывает готовности реального кода.

Если JavaScript обращался к переменным окружения за секретами, перенесите чувствительные значения в подходящий механизм credentials либо перестройте сценарий. Не открывайте весь набор переменных любому редактору сценариев автоматически. У платформы может быть больше секретов, чем нужно одному узлу.

Для каждого фрагмента кода определите вход, выход и возможный внешний эффект. Такой маленький контракт помогает заметить изменения намного раньше, чем ошибка пройдёт через пять следующих узлов и превратится в неверный документ.

Python требует отдельной проверки совместимости

Старый Python Code node использовал Pyodide. В новой модели применяется нативный Python через внешний task runner. Прежние способы обращения к входным данным и встроенным объектам нельзя считать переносимыми без изменений.

Сверяйте код с разделом native Python в документации Code node. Проверьте режим обработки элементов, доступные переменные, структуру возвращаемого значения и разрешённые модули. Не ограничивайтесь заменой первой строки, на которую пожаловался интерпретатор.

Создайте набор учебных входов: пустое значение, один элемент, несколько элементов, некорректная дата и большая строка. Сравните выход по смыслу, а не только по зелёному индикатору. Если узел рассчитывает сумму, проверьте округление и отсутствие случайного превращения числа в текст.

Когда код зависит от локального файла, выясните, в каком контейнере находится этот файл. Каталог основного процесса не появляется у runner автоматически. Передавайте необходимые данные явно и ограничивайте монтируемые пути. Выдача доступа ко всему диску ради одного справочника — слишком широкое решение узкой задачи.

Сценарий с ожиданием нужно проверять до конца

Возьмите учебный процесс согласования: родитель передаёт заявку дочернему сценарию, тот ждёт решения человека и возвращает результат. Проведите оба исхода — одобрение и отказ. Затем убедитесь, что родитель читает именно итоговые данные, а не случайно сохранившийся вход.

Проверьте повторное обращение к ссылке ожидания, истечение согласованного срока и отмену. Старые незавершённые исполнения заслуживают отдельного решения: дождаться их завершения до обновления, перенести по поддерживаемой процедуре или обработать вручную с фиксацией результата.

После изменения модели публикации убедитесь, что редактируемый вариант и исполняемый вариант сценария понятны команде. Сохранённое изменение не следует автоматически считать опубликованным. Для каждого важного webhook отправьте запрос именно на production-путь стенда и проверьте, какой вариант исполняется.

Составьте короткий протокол приёмки: вход, ожидаемый выход, внешний эффект, фактический результат. Для важных интеграций добавьте идентификатор операции, чтобы повторный запуск не создавал дубликаты. Эта работа пригодится при следующем обновлении и не пропадёт после перехода на 2.x.

Как провести рабочее обновление

Следуйте официальной процедуре обновления для своего способа установки. Выберите конкретный поддерживаемый выпуск, прочитайте изменения от исходной версии до него и повторите проверенный маршрут со стенда. Не используйте плавающий тег как обозначение согласованного релиза.

Перед окном остановите новые поступления либо организуйте очередь, дождитесь завершения допустимых текущих задач и сделайте свежую копию. Для долгих ожиданий примените заранее выбранное решение. Запишите точное время и состояние, от которого начинается обновление.

Обновите все связанные компоненты согласованно, включая runners и workers. После запуска сначала проверьте вход, credentials и один безопасный сценарий. Затем возвращайте рабочие триггеры постепенно, начиная с наименее рискованных. Наблюдайте за ошибками, очередью и потреблением памяти.

Не запускайте старую и новую n8n одновременно на одной рабочей базе. Это не резервирование, а конкурирующие версии приложения со своими ожиданиями к схеме и выполнению задач.

Почему откат образа не равен откату системы

Новая версия может изменить структуру базы. Поэтому возврат только старого контейнера не гарантирует работоспособности. Нужен согласованный комплект прежнего образа, базы, ключа и файлов, восстановленный по проверенной процедуре.

При этом операции, выполненные после обновления во внешних сервисах, не исчезнут после восстановления базы. Отправленное письмо нельзя отменить откатом контейнера. Поэтому сохраните журнал выполненных действий и заранее определите, как исключить повторную отправку после возврата.

После успешного перехода проверьте резервное копирование уже новой версии и восстановление свежего состояния. Обновите список сценариев и назначенных владельцев. Хорошее обновление n8n оставляет не только более современный интерфейс, но и ясное понимание того, какие процессы работают, с какими правами и как их восстановить без повторного воздействия на клиентов.