Как переехать с n8n Cloud на свой VPS и сохранить автоматизации

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

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

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

Начните с реестра, а не с кнопки экспорта

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

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

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

Что содержит экспорт workflow

Через интерфейс n8n можно выгрузить workflow в JSON и импортировать его в другую установку. Документация экспорта объясняет этот механизм. Файл описывает сценарий, но не является полной резервной копией экземпляра.

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

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

Сохраните исходные файлы неизменными и работайте с копиями. Добавьте дату экспорта и название процесса. Когда автоматизаций много, файл с названием «последний-финальный» быстро перестаёт выполнять обещание.

Подготовьте новый экземпляр n8n

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

Настройте публичный домен, HTTPS, постоянное хранение и базу. Для развивающейся рабочей установки удобно заранее использовать PostgreSQL и ограничить хранение ненужных исполнений. Избыточные журналы с крупными данными могут занять диск быстрее, чем сами workflows.

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

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

Подключения создаём и проверяем заново

Импортируйте один неактивный workflow и создайте необходимые credentials. Для API-токена проверьте права и срок действия. Для OAuth выполните авторизацию с адресом возврата нового экземпляра. Внешний провайдер может требовать добавления этого адреса в настройки приложения.

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

Проверьте ограничения API и правила доступа по IP, если они используются. Новый сервер имеет другой исходящий адрес. Успешный вход в редактор n8n не подтверждает, что внешняя CRM разрешает ему запросы.

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

Вебхуки: новый адрес должен знать отправитель

За обратным прокси n8n требуется правильный публичный URL вебхуков и доверенная цепочка заголовков. В актуальном руководстве используется N8N_WEBHOOK_URL; старое имя переменной помечено устаревшим начиная с версии 2.35.0. Проверяйте настройки относительно установленной версии.

У сценария могут быть тестовый и рабочий адреса. Внешняя система должна отправлять события на адрес активного рабочего сценария. Временное прослушивание в редакторе полезно для диагностики, но не является постоянным приёмником.

Составьте список всех отправителей: форма сайта, CRM, бот, платёжный сервис. Для каждого укажите старый URL, новый URL, способ изменения и безопасное тестовое событие. Некоторые интеграции допускают только один webhook, поэтому активация нового экземпляра сразу изменит доставку.

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

Расписания и время ожидания

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

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

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

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

Приёмка на конкретном процессе

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

Следующая проверка — временная ошибка CRM. Сценарий должен сохранить понятное состояние, выполнить предусмотренную повторную попытку или уведомить ответственного. Сообщение «успешно» на последнем узле не должно скрывать пропущенную основную операцию.

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

Что сохранить для будущего администратора

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

Конфигурация MAATRIX и порядок перехода

Для пилота с умеренными сценариями можно начать с MAATRIX Uab Start: 2 vCPU и 4 ГБ памяти. При обработке крупных файлов, нескольких одновременных исполнениях и PostgreSQL рядом разумнее оценивать Heka Standard с 4 vCPU и 8 ГБ. Потребление зависит от данных внутри узлов, поэтому счётчик workflows мало говорит о требуемой памяти.

В MAATRIX доступен вариант установки n8n из каталога приложений. Он помогает подготовить площадку, но перенос credentials, событий и проверка логики остаются отдельной задачей. Выберите совместимую ОС и рассчитайте диск с учётом истории исполнений, файлов и резервного запаса. Внешние API оплачиваются отдельно.

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