Бета n8n 3.0 требует проверки старых автоматизаций до обновления. Стабильный выпуск ожидается в начале декабря; вернуться на 2.x после перехода можно только восстановлением резервной копии.
Что меняется в n8n 3.0?
n8n 3.0 меняет внутреннюю работу системы автоматизации: убирает устаревшие узлы, пересматривает ограничения выполнения и требует Docker для самостоятельного размещения. Сейчас доступна бета; стабильную версию команда планирует на начало декабря 2026 года.
n8n соединяет действия разных сервисов в сценарий. Например, обращение с сайта может запустить запись в системе продаж и уведомление ответственному. Если после обновления перестанет работать один узел такой цепочки, сама страница сайта при этом может выглядеть совершенно исправной.
В анонсе от 27 октября акцент сделан на надёжности и безопасности. Это полезное уточнение для тех, кто увидел крупную цифру версии и ждёт прежде всего новых возможностей. Часть изменений потребует переделать существующие сценарии или настройки.
Последняя строка не означает, что весь сценарий теперь обязан завершиться за минуту. В анонсе указан именно стандартный лимит узла кода, который можно настраивать. Распространять его на всю автоматизацию было бы неверно.
Где найти Migration Report и что он показывает?
Migration Report находится в Settings → Migration Report на установках n8n версии 2.39 и новее. Он показывает затронутые сценарии и общие настройки; обычный пользователь видит доступные ему сценарии, а владелец установки и администраторы — общую картину.
Перед проверкой команда рекомендует обновиться до последней 2.x, чтобы получить актуальный вариант отчёта. Подробный порядок есть в документации инструмента миграции.
Читать отчёт стоит по последствиям. Сначала разбирать то, что блокирует переход или остановит выполнение, затем возможные сбои и изменения поведения. Вкладку общих настроек должен проверить человек с соответствующим доступом: отсутствие её в вашем интерфейсе не означает, что замечаний нет.
Есть тонкость с отметкой «не исправлять». По документации, такой сценарий перестаёт считаться открытой проблемой. Редакция советует использовать её только после осознанного решения: например, для действительно заброшенной цепочки. Закрыть замечание в списке и подтвердить работу нужного процесса — разные результаты.
Можно ли довериться автоматическому исправлению?
Инструмент умеет автоматически переносить некоторые узлы, но сохраняет результат новой версией сценария. Опубликованная версия продолжает работать до отдельной публикации новой; перед этим n8n рекомендует проверить результат выполнения.
Это удобная возможность разделить подготовку и включение изменений. Само появление исправленной версии ещё не подтверждает, что на выходе получится правильная заявка, сумма или уведомление.
Предлагаем такой учебный пример проверки: у вас есть цепочка «форма → запись обращения → сообщение менеджеру». Для испытания подготовьте данные вымышленного клиента и отдельное место получения уведомления. Сравните результат старой и подготовленной версии по содержимому и количеству созданных записей.
- Обычное обращение должно дойти в нужное место со всеми полями.
- Вложение должно открыться у получателя, если цепочка работает с файлами.
- Ошибка внешнего сервиса должна быть заметна ответственному.
- Повторный запуск не должен незаметно создать лишнее обращение, если ваш процесс предусматривает защиту от повторов.
Это редакционный протокол приёмки, не наш эксперимент на подключённой компании. Конкретную проверку повторов нужно сопоставить с устройством вашего сценария. Если в цепочке меняются таблицы, сначала полезно разобраться, как устроены миграции базы данных.
Можно ли откатиться с n8n 3.0 обратно на 2.x?
Обычного возврата с 3.x на 2.x нет: команда предупреждает, что потребуется восстановление полной резервной копии. Поэтому сначала следует испытать переход на отдельной тестовой установке и заранее подготовить восстановление.
В анонсе рекомендован порядок: последняя 2.x, разбор отчёта, полная копия, обновление тестовой установки и только затем рабочей. Номер беты сам по себе не даёт оснований проверять её на живом потоке заказов.
Для подготовки договоритесь, сколько простоя допустимо и за какой период вы готовы восстанавливать данные. Эти два вопроса разобраны в материале о сроках восстановления и допустимой потере данных.
До стабильного выпуска можно заняться инвентаризацией: какие сценарии действительно нужны, кто за них отвечает и чем подтверждается их работа. Это конкретный результат подготовки, даже если обновлять рабочую систему сегодня вы не собираетесь.
