Archivio Domande

Как перенести n8n на другой VPS и сохранить рабочие интеграции

После переезда n8n может открываться, показывать все сценарии и при этом не выполнять свою работу: Google Sheets требует авторизацию, Telegram не присылает события, а заявки с сайта уходят на старый сервер. Перенос файлов сценариев не сохраняет всю установку.

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

Что переносить, кроме сценариев

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

Что сохранить	Зачем это нужно
Базу данных n8n	В ней находятся сценарии, зашифрованные credentials, пользователи и другие данные установки. Полная копия также сохраняет находящуюся в базе историю выполнений и состояние ожидающих задач.
Ключ шифрования и конфигурацию n8n	Без исходного ключа перенесённые credentials могут отображаться в интерфейсе, но n8n не сможет использовать сохранённые секреты.
Compose-файлы, .env и подключённые файлы секретов	Они задают подключение к базе, публичные URL, часовой пояс, параметры очереди и настройки, которые используют сценарии.
Постоянные тома и рабочие каталоги	Вложения, PDF, изображения и файлы для узлов чтения с диска могут храниться отдельно от базы. Перенесите также каталоги, подключённые к контейнеру.
Дополнительные узлы и зависимости	Community nodes, собственные узлы, модули для Code, внешние task runners и утилиты должны быть доступны на новом сервере в совместимых версиях.
Настройки внешнего доступа	Конфигурацию reverse proxy, HTTPS, домен, OAuth Redirect URL, адреса вебхуков и ограничения по IP у внешних сервисов.

Если файлы хранятся в S3 или другом внешнем хранилище, переносить их на диск VPS необязательно. Нужно сохранить доступ к прежнему хранилищу и настройки путей. Если используются локальные файлы, проверьте параметры хранения binary data, включая N8N_BINARY_DATA_STORAGE_PATH, когда он задан.

Где найти ключ шифрования и почему нельзя создать новый

n8n использует ключ шифрования для защиты сохранённых подключений. Обычно он задан через N8N_ENCRYPTION_KEY либо автоматически создан и сохранён в файле ~/.n8n/config. В стандартном Docker-контейнере этот файл находится по пути /home/node/.n8n/config; на хосте данные могут лежать в подключённом Docker volume.

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

Ошибка «Credentials could not be decrypted» означает, что в первую очередь нужно проверить ключ и подключение правильного каталога данных. Пересоздавать все интеграции до этой проверки не стоит.

Архив базы, конфигурации и секретов содержит чувствительные данные. Передавайте его через SSH/SFTP и храните вне публичного каталога сайта.

Подготовьте новый VPS до остановки старого

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

В Docker Compose версию можно узнать так, если сервис приложения называется n8n:

docker compose exec -T n8n n8n --version

На новом VPS закрепите эту версию в теге образа. Тег latest при новом скачивании может привести к установке другой версии и автоматическому изменению структуры базы.

Проверьте свободное место: должны поместиться база, вложения и резервная копия. Подготовьте Docker или другое используемое окружение, reverse proxy и HTTPS. Если были дополнительные контейнеры, например PostgreSQL, Redis или task runners, включите их в план переноса.

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

Остановите новые запуски и сделайте окончательную копию

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

Зафиксируйте опубликованные сценарии и приостановите новые запуски: входящие события у источников, расписания и опросы.
Дождитесь завершения выполняющихся задач. Отдельно запишите задачи со статусом Waiting, например ожидающие ответа пользователя через Wait.
Если используется queue mode, дайте workers обработать очередь. Не считайте переносом очереди запуск пустого Redis, если в старом ещё остались задания.
Корректно остановите процессы n8n, workers и обработчики вебхуков, которые могут продолжать работу или запись данных.
Сделайте финальную копию базы, конфигурации и файлов. После этого старый экземпляр должен оставаться остановленным.

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

Если используется SQLite

По умолчанию база находится в ~/.n8n/database.sqlite. После остановки приложения перенесите весь постоянный каталог .n8n, включая config и присутствующие служебные файлы базы. При обычном копировании работающей SQLite можно получить несогласованную копию; оставшиеся файлы журнала или WAL нельзя произвольно отбрасывать.

В Docker копируется содержимое тома, подключённого к /home/node/.n8n. Одних docker-compose.yml и .env недостаточно: на другом VPS Docker может создать новый пустой том с похожим именем.

Если используется PostgreSQL

Сделайте дамп базы средствами PostgreSQL. Сам PostgreSQL для создания дампа должен работать, а процессы n8n к этому моменту уже должны прекратить запись. Каталог .n8n и отдельные файловые хранилища сохраните дополнительно.

Пример команды из среды, у которой есть доступ к базе:

pg_dump -Fc -h DB_HOST -U DB_USER -d DB_NAME -f n8n.dump

На новом сервере восстановите дамп в заранее созданную пустую базу:

pg_restore --exit-on-error --single-transaction \
  -h NEW_DB_HOST -U DB_USER -d NEW_DB_NAME n8n.dump

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

Восстановите данные до первого рабочего запуска

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

Если используется PostgreSQL, убедитесь, что новый n8n подключается к восстановленной базе, а не к старой production-базе или пустой базе по умолчанию. Для queue mode основной процесс, workers и обработчики вебхуков должны использовать согласованные настройки базы, Redis и один ключ шифрования.

Появление экрана создания первого владельца вместо прежнего входа — повод проверить базу и тома. Частая причина: приложение запустилось с пустыми данными. Создание нового аккаунта не восстановит прежнюю установку.

Как сохранить домен и рабочие вебхуки

По возможности оставьте прежний адрес, например https://n8n.example.com. Тогда после смены IP не придётся менять URL во всех формах и интеграциях. При этом должны сохраниться протокол HTTPS и пути вебхуков.

До запуска проверьте публичные адреса в настройках n8n. Для версии 2.35 и новее при одном reverse proxy пример выглядит так:

N8N_HOST=n8n.example.com
N8N_PROTOCOL=https
N8N_EDITOR_BASE_URL=https://n8n.example.com/
N8N_WEBHOOK_URL=https://n8n.example.com/
N8N_PROXY_HOPS=1

Для более старых версий используется WEBHOOK_URL. С версии 2.35 это устаревшее имя остаётся совместимым псевдонимом N8N_WEBHOOK_URL. При переносе без обновления ориентируйтесь на установленную версию.

Reverse proxy должен передавать X-Forwarded-For, X-Forwarded-Host и X-Forwarded-Proto. Значение N8N_PROXY_HOPS должно соответствовать вашей схеме: пример с единицей рассчитан на один прокси перед n8n.

После восстановления запустите новый экземпляр при остановленном старом и проверьте HTTPS. Затем переключите DNS или адрес сервера в используемом прокси. Проверьте обе записи, A и AAAA: оставшаяся AAAA может направлять часть подключений на прежний IPv6.

Если проверяете новый VPS через запись в hosts на своём компьютере, это проверяет только ваше подключение. Внешняя CRM или Telegram продолжат использовать публичный DNS.

В каждом Webhook-узле сверяйте именно Production URL. В n8n 2.x рабочий вебхук регистрируется при публикации сценария; в старых версиях используется включение Active. После переезда восстановите работу тех сценариев и версий, которые были запущены раньше.

Для Telegram учитывайте отдельную особенность: у одного бота может быть только один зарегистрированный вебхук. Тестовый запуск способен заменить production-адрес. Для проверки двух установок используйте отдельного тестового бота, а после переключения проверяйте рабочий сценарий через production.

Нужно ли заново подключать Google, CRM и другие сервисы

Сначала проверьте существующие credentials. Если база и ключ сохранены, в них остаются прежние данные подключения, включая сохранённые OAuth-токены. Сам переезд не означает, что нужно создавать новые OAuth-приложения и переподключать всё вручную.

Если домен изменился, откройте credential в n8n и скопируйте показанный OAuth Redirect URL. Добавьте его в разрешённые адреса перенаправления соответствующего OAuth-приложения. Например, для Google это поле Authorized redirect URIs.

Сравнивайте адрес целиком: https или http, домен, порт и путь. Ошибка redirect_uri_mismatch указывает на несовпадение этого адреса. Повторное подключение с тем же неправильным URL проблему не решит.

Проверьте сохранность Client ID и Client Secret. Если сервис отозвал токен или требует повторной авторизации, подключите именно эту интеграцию заново после исправления адресов.

Отдельно обновите списки разрешённых IP у API, баз данных и других внешних систем. Домен n8n может остаться прежним, но исходящие запросы с нового VPS обычно приходят с другого IP. Также проверьте обращения к localhost и локальным адресам: после переезда они могут указывать уже на другую машину или контейнер.

Что проверить, если сценарий не работает

Что происходит	Первая проверка
Credentials could not be decrypted	Исходный ключ шифрования, фактически загруженную конфигурацию и правильный том .n8n.
redirect_uri_mismatch	OAuth Redirect URL в карточке подключения и разрешённый redirect URI у внешнего сервиса.
Сценарий запускается вручную, но не получает события	Публикацию или активность сценария, Production URL, DNS, HTTPS и журнал доставки у отправителя.
API возвращает 401 или 403	Текст ответа: токен, права подключения и ограничения по новому исходящему IP. Эти коды не доказывают ошибку шифрования.
Узел не находит файл или тип узла	Подключённые каталоги, пути внутри контейнера, права доступа и установку дополнительных узлов.
Расписание срабатывает в другое время	Часовой пояс самого workflow и GENERIC_TIMEZONE. TZ задаёт системный часовой пояс окружения.
Заявки или сообщения дублируются	Не продолжает ли работать старый экземпляр и не повторяет ли отправитель доставку одного события. Сверьте идентификаторы событий и выполнений.

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

До окончания проверки сохраните старый VPS и резервную копию, но оставьте старый n8n остановленным. Если новый экземпляр уже обработал события, перед откатом нужно сверить выполненные операции: возврат к старой базе может привести к повторной обработке или потере новых данных.

Проверьте реальный запуск от события до результата

Выберите действующий сценарий с понятным результатом. Например: заявка из формы должна создать запись в CRM и отправить уведомление в Telegram. Используйте тестовую заявку с уникальной меткой, чтобы её можно было найти на каждом этапе.

Создайте событие в исходной системе. Отправьте форму на сайте или сообщение боту. Кнопка Execute workflow не проверяет весь путь доставки.
Найдите выполнение на новом VPS. В разделе Executions проверьте время, входные данные и вашу метку. Убедитесь, что запрос действительно обработал новый экземпляр.
Посмотрите результат каждого важного шага. HTTP 200 от вебхука может означать только приём запроса. Успешный статус выполнения тоже нужно сопоставить с ожидаемым результатом.
Откройте конечные сервисы. Найдите запись в CRM или строку в таблице, получите уведомление, проверьте переданный файл. Сравните значения полей и количество созданных объектов.
Проверьте отдельные механизмы. Дождитесь запуска по расписанию; если есть Wait, проверьте продолжение ожидающей задачи. Для OAuth-подключений убедитесь, что работа продолжается и после обновления access token.
Проверьте автозапуск. В согласованное окно после завершения текущих задач перезагрузите новый VPS. После восстановления сервисов повторите внешний тест и убедитесь, что база, ключ и подключения сохранились.

Зафиксируйте результат: какое событие пришло, какое выполнение его обработало и какой объект появился во внешнем сервисе. Перенос проверен, когда рабочий путь проходит на новом VPS, данные доходят до получателя, а лишних операций не возникает.

0 Utenti hanno trovato utile questa risposta