Как перенести рабочий n8n на другой VPS: ключ шифрования, база и вебхуки

Типичная картина неудачного переезда выглядит так. На новом сервере поднят чистый n8n, туда импортирован красивый JSON со схемами, все узлы на месте, стрелки ведут куда надо. Но стоит открыть любой узел с подключением к почте, CRM или Telegram, и вместо привычного «Connected» вы видите пустое или нерабочее подключение. Схемы есть, а ключей от дверей, в которые эти схемы стучатся, нет.

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

Из чего на самом деле состоит ваш n8n

Когда n8n живёт год-два, он обрастает связями, о которых вы уже не помните. Что-то лежит в базе, что-то в папке на диске, что-то в переменных окружения, а что-то вообще на соседнем сервисе и подключено через сеть. Документация по резервному копированию описывает полную копию как набор из нескольких частей: пользовательская папка, внешняя база данных, если вы её используете, внешнее хранилище, custom nodes и ключ, без которого credentials не расшифровать. Это удобная отправная точка, но к ней стоит добавить собственную карту соответствия: что именно у вас лежит и для чего оно нужно.

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

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

Экспорт схем: чертёж без дома

Теперь понятно, почему экспорт workflow в JSON нельзя считать резервной копией. Это ценный артефакт: его удобно хранить в репозитории, сравнивать версии, переносить отдельные схемы между средами. Но он описывает логику, а не состояние. В нём нет ваших сохранённых секретов в пригодном для использования виде, нет истории запусков, нет custom nodes, нет файлов, на которые ссылаются узлы. Разница примерно такая же, как между чертежом здания и самим зданием с мебелью и ключами у жильцов.

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

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

Репетиция на новом сервере: пока без реальных событий

Главная ловушка переезда в том, что рабочий n8n нельзя проверить «понарошку» в боевом режиме. Если вы поднимете копию с включёнными триггерами и живыми credentials, она начнёт опрашивать почту, забирать задачи из CRM, отправлять сообщения клиентам, пока старый экземпляр делает то же самое. Поэтому репетиция проходит по другому сценарию: сначала вы убеждаетесь, что копия читается, и только потом даёте ей право действовать.

Для репетиции подойдёт отдельный VPS. У MAATRIX в публичном каталоге есть n8n с установкой, но точное наличие и ОС стоит смотреть в форме заказа, а не полагаться на память. Сервер при этом даёт root-доступ, на NVMe-диске удобно разворачивать базу и распаковывать копию, а локацию можно выбрать из списка: в публичном предложении названы Великобритания, США, Россия и Франция. Какой тариф брать, зависит от вашей нагрузки. Линейка идёт от Ba с 1 vCPU, 2 ГБ RAM и 40 ГБ NVMe до Djed с 16 vCPU, 32 ГБ и 320 ГБ, но эти цифры описывают ресурсы, а не обещание, сколько запусков в минуту выдержит ваш поток. Практичный ориентир тут один: посмотрите на старом сервере, сколько памяти и диска n8n и база реально занимают в обычный день и в пиковый, и возьмите с запасом. А ёмкость конкретной конфигурации проверяйте не по таблице, а по собственным замерам во время репетиции.

Порядок репетиции такой:

1. Разверните n8n на новом сервере с теми же настройками, что и на старом: тот же режим работы, та же СУБД, та же ветка версии. Переезд заодно с обновлением версии превращает любую ошибку в загадку с двумя неизвестными.
2. Остановите свежеустановленный экземпляр и подложите в него копию базы и пользовательской папки, а также custom nodes и внешние файлы по тем же путям, что были раньше.
3. Задайте тот же ключ шифрования, что был на старом сервере. Проверьте, что он попал в конфигурацию, не выводя его значение в логи или терминал на общем экране.
4. Запустите экземпляр в изолированном виде: без доступа извне и без активных триггеров. Самый надёжный способ того добиться: оставить все workflow выключенными, как они были в копии, и ничего не включать вручную.
5. Откройте несколько ключевых credentials и убедитесь, что они читаются и проходят проверку подключения. Если проверка подключения для безопасного ресурса возможна, выполните её. Для платёжных систем и рассылок не нажимайте ничего, что может отправить настоящее сообщение или создать запись.

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

Два адреса одного вебхука

Следующий вопрос касается входящих событий. Всё, что запускается снаружи, будь то платёжный сервис, форма на сайте, бот или CRM, стучится по определённому адресу. Узел Webhook в n8n запускает workflow по входящему событию, и у него есть два адреса: тестовый и рабочий. Они различаются, и это принципиально для переезда.

Тестовый адрес работает, пока вы смотрите на редактор и слушаете событие вручную: удобно для отладки, бесполезно для реального потока. Рабочий адрес, как сказано в той же документации, регистрируется при публикации workflow. Следовательно, на новом сервере рабочие адреса не заработают, пока вы не опубликуете схемы заново или не убедитесь, что они опубликованы в восстановленном состоянии. А это в свою очередь означает, что включение workflow на новом сервере и есть момент, когда он начинает принимать события. Репетиция должна учитывать это поведение: отдельно проверять, как выглядит адрес, который n8n сформирует, и отдельно проверять, что внешние системы смогут до него достучаться.

Здесь легко споткнуться о две вещи.

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

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

Прекратить новое, дожить начатое

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

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

Второй тип: исполнения, которые уже идут. Некоторые workflow короткие и закончатся за секунды, другие ждут ответа внешней системы, паузы или подтверждения человека. Для коротких достаточно подождать. Для долгих придётся решить, что с ними делать: дождаться завершения, перенести окно переезда или признать, что часть исполнений придётся перезапустить вручную. Хорошая привычка — перед окном посмотреть в журнал исполнений старого экземпляра и выписать, какие workflow длиннее нескольких минут. Именно они составляют зону риска.

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

Передача потока: не переключатель, а плавный переход

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

Из этого следует несколько практических решений.

• Заранее уменьшите TTL. За сутки или двое до окна переезда снизьте время жизни записи, чтобы к моменту переключения старые значения успели выйти из большинства кешей. Это снижает риск, но не обнуляет его.
• Старый сервер не должен вести себя как полноправный обработчик. Если в течение переходного периода на него всё ещё прилетают события, у вас есть выбор: пусть он принимает и пересылает их на новый, пусть отвечает ошибкой, чтобы отправитель повторил доставку позже, либо пусть принимает и складывает в очередь для ручной обработки. Какой вариант лучше, зависит от того, повторяет ли отправитель попытки и что стоит дороже: потерянное событие или задержанное.
• Выберите окно с малым потоком. Это не про дату, а про ваш трафик: посмотрите по журналу исполнений, когда события приходят реже всего, и выберите именно это время.
• Один обработчик в каждый момент. Принцип простой: у любого типа события в любой момент времени должен быть один ответственный экземпляр. Для вебхуков это обеспечивается включением workflow на одном сервере и выключением на другом. Для расписаний и опросов — аналогично.

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

Финальная копия нужна ещё и потому, что за время репетиции на старом сервере могли появиться новые схемы, обновлённые credentials и свежая история. Нередкая ошибка — перенести состояние недельной давности, потому что именно с ним репетировали, и потерять правки, внесённые коллегами в последние дни. Поэтому в плане должен быть явный шаг «последняя синхронизация состояния» после остановки триггеров на старом.

Дорога назад должна оставаться открытой

Возврат — это не признак неуверенности, а часть плана. Пока старый сервер цел и его конфигурация не тронута, откат сводится к обратной смене DNS и повторному включению триггеров на нём. Но есть тонкость: за время работы нового сервера в нём могли появиться свежие данные, а со старым их уже не объединить без усилий. Поэтому первые часы и дни после переключения старый сервер лучше держать в состоянии «холодного резерва»: данные на месте, триггеры выключены, доступ ограничен.

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

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

Первое настоящее событие

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

Первое, что нужно увидеть, — сам приём. В журнале исполнений нового экземпляра должна появиться запись, созданная вебхуком, с временем, близким к моменту отправки формы. Если её нет, возможные причины такие: событие по-прежнему уходит на старый сервер из-за кеша DNS, workflow на новом не опубликован и рабочий адрес не зарегистрирован, либо базовый адрес экземпляра настроен неверно. Проверьте журнал старого сервера: если событие осело там, это просто вопрос времени кеширования, и его нужно переслать вручную.

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

Третий шаг — результат во внешнем мире. Сверьте, что в таблице появилась ровно одна строка, в трекере ровно одна задача, а менеджеры получили ровно одно уведомление. «Ровно одно» здесь важное слово: оно проверяет, что обработчик в данный момент один и дублей не возникло. Если вы видите два экземпляра результата, значит, старый сервер тоже успел обработать это событие, и надо вернуться к шагу с остановкой триггеров.

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