Сценарий n8n хранится как JSON-файл с узлами, связями между ними и настройками, поэтому его можно выгрузить на одном сервере и загрузить на другом. В файл попадают ссылки на учётные данные, но сами пароли и токены остаются в хранилище n8n, если выгрузку делали обычным способом. Перенос подходит для связки «стенд — рабочий сервер» и для передачи заготовки коллеге, когда оба знают, какие секреты придётся создать заново.
Что внутри файла
JSON сценария описывает узлы, их параметры и соединения. Выгрузка переносит схему работы, а доступ к сервисам на новом месте настраивается заново.
Условный пример: отчёт по заказам собран и отлажен на тестовом сервере, теперь его нужно поднять на рабочем. Файл содержит имена узлов, их положение на холсте, параметры вроде адреса и расписания, а ещё поле версии у каждого узла. В узлах, которые ходят в сервисы, записана ссылка на учётные данные: название и внутренний идентификатор.
Из этого следует практическое правило: файл читается как текст, и его полезно открыть в редакторе до отправки. Найдите адреса внутренних систем, токены, вставленные прямо в поля, и тестовые данные. Секрет, который кто-то набрал в параметре узла вместо хранилища учётных данных, уйдёт вместе с файлом.
Чего в файле нет, тоже важно знать заранее. История прошлых запусков сценария в JSON отсутствует, поэтому на новом сервере журнал Executions начнётся с чистого листа. Права пользователей и сами значения доступов остаются на старом месте. Если команда привыкла разбирать прошлые сбои по истории, сохраните нужные записи отдельно до выключения старой установки.
Общую картину, как сценарий собирается из событий и действий, даёт материал про рабочие сценарии n8n. Здесь нас интересует только жизнь файла: выгрузка, передача, загрузка и первый запуск.
Секреты и доступ
Выгрузка сценария через CLI на своём сервере выглядит так: команда n8n export:workflow --id=<ID> --output=file.json сохраняет один сценарий в файл. Флаг --separate раскладывает каждый сценарий отдельным файлом (каталог задают через --output), что удобно для хранения в репозитории. Учётные данные выгружает отдельная команда n8n export:credentials, и её флаг --decrypted пишет их в открытом текстовом виде: такой файл равен связке паролей.
- Выгружайте сценарии без флага расшифровки, а учётные данные создавайте на новом сервере вручную.
- Файлы выгрузки передавайте по закрытому каналу компании и держите вне почты и общих чатов.
- Файл с расшифрованными доступами, если он всё же понадобился, храните как пароль: отдельное закрытое место и удаление после переноса.
- В репозиторий кладите только сценарии, прошедшие просмотр на токены в параметрах узлов.
Для правил доступа к самому серверу используйте то, что описано в материале про API и доступ к n8n: у выгрузки и загрузки должен быть отдельный человек с понятной ролью вместо общей учётки.
Версии узлов
У каждого узла в JSON есть тип и номер версии. Узел в файле запрашивает именно ту версию, с которой его сохранили. Если на рабочем сервере стоит более старый n8n, такой узел может остаться закрытым или потерять часть параметров; в обратной ситуации узел, как правило, открывается, однако новые поля остаются со значениями по умолчанию, и их нужно просмотреть глазами.
| Ситуация | Что видно после импорта | Что проверить |
|---|---|---|
| Новый n8n на целевом сервере | Узлы открываются, часть полей пустая | Параметры, добавленные в новых версиях |
| Старый n8n на целевом сервере | Узел способен остаться закрытым или показать ошибку | Версию n8n, обновление до импорта |
| Сторонний пакет узлов в файле | Узел недоступен без установки пакета | Источник пакета и его код до установки |
| Другие учётные данные | Узел просит выбрать доступ заново | Права нового доступа, минимально необходимые |
Отдельный случай — сценарий, который вызывает другие сценарии или принимает вебхуки. В файле лежат пути и ссылки на соседей, а на новом сервере у вебхука будет другой публичный адрес. Сервис, который присылает события, придётся перенастроить на новый адрес, иначе рабочий сценарий будет молчать, хотя в редакторе всё выглядит исправным.
Перед переносом запишите версию n8n на обоих серверах и список сторонних пакетов. Три строки в карточке переноса экономят разбирательство, когда сценарий открылся, но один узел светится красным. О выборе узлов и пакетов читайте в статье про узлы сценария.
Импорт на сервер
Загрузка через CLI подчиняется важной оговорке из документации: при экспорте n8n выгружает идентификаторы сценариев и учётных данных, а совпавшие идентификаторы в базе при импорте перезаписываются. Если на рабочем сервере уже живёт сценарий с таким же номером, загрузка заменит его. Перед импортом проверьте номера или удалите их из файла.
- Сделайте резервную копию текущих сценариев рабочего сервера, выгрузив их в отдельный каталог по одному файлу.
- Сверьте идентификаторы в новом файле с уже существующими и поменяйте совпавшие.
- Загрузите файл командой импорта с нужным проектом или пользователем; документация предусматривает флаги для обоих вариантов.
- Убедитесь, что сценарий загружен выключенным: по умолчанию импорт деактивирует сценарии, и включать его будете сами после проверки.
- Создайте учётные данные на новом сервере и привяжите их к узлам по очереди, проверяя каждый кнопкой теста.
Для регулярных переносов заведите репозиторий с файлами сценариев: по одному файлу на сценарий, с просмотром изменений другим человеком перед выкладкой. Разница между двумя версиями файла показывает, какой параметр поменяли, и избавляет от догадок, кто и когда перенастроил расписание.
Отдельное решение — что делать с закреплёнными данными в файле. Они лежат вместе со сценарием, поэтому перед рабочим переносом сотрите их или убедитесь, что там вымышленные записи. Копии рабочих сценариев должны лежать в одном месте, доступном владельцу процесса.
Где у вас сейчас хранятся копии рабочих сценариев?
Тест после переноса
Включать перенесённый сценарий сразу опасно: у него другое окружение, другие адреса и, возможно, настоящие получатели. Сначала запустите его вручную на вымышленных данных и посмотрите, куда он пытается писать. Если сценарий отправляет письма или создаёт карточки, поставьте перед боевым узлом заглушку или направьте запись в тестовую таблицу.
Проверка состоит из трёх вопросов. Все ли узлы открываются без красных меток. Использует ли каждый узел доступ, заведённый именно на этом сервере. Попадает ли результат туда, куда задумано, и больше никуда. После ответа «да» на каждый вопрос включайте триггер и наблюдайте за первым настоящим запуском во вкладке Executions.
Работа владельца продолжается и после передачи файла: рядом с ним лежит журнал переноса, в котором записано, кто выгрузил сценарий, когда и из какой версии. Через месяц эта запись избавит от споров о том, какая копия считается актуальной, и подскажет, у кого спросить про нестандартные настройки.
Если перенос повторяется регулярно, оформите его как короткую инструкцию с тремя разделами: подготовка файла, загрузка и проверка, откат. Откат означает возврат к резервной копии, снятой на втором шаге, и восстановление прежних адресов вебхуков у внешних сервисов.
Прежде чем переносить всё сразу, выгрузите один безобидный сценарий без учётных данных, откройте файл в текстовом редакторе и найдите в нём все адреса и токены. Затем загрузите его в тестовый экземпляр и сравните результат с оригиналом. Если нужен перенос целой системы сценариев с доступами и журналом, обсудите с нами внедрение ИИ и автоматизации.