Честно говоря, вы можете открыть любой другой официальный гайд по переносу данных.
По сути, мы сделали то же самое, просто собрали рекомендации из нескольких гайдов в один и приправили это нашим собственным опытом работы с n8n.
Плюс, мы предлагаем вам пропустить парочку шагов и упростить себе работу, но об этом уже в разделе с миграцией.
Если вы переезжаете с cloud n8n на собственный хостинг, то вам предстоит делать экспорт воркфлоу и ручной перенос, а после настройку.
Возможно, вам удастся договориться с поддержкой n8n о дампе данных, если у вас большой объем и платный тариф. Но мы бы не рассчитывали на легкий перенос, потому что кнопки с автоматической миграцией у n8n нет.
При переезде между серверами все чуть легче.
n8n Cloud — это полностью управляемый сервис. n8n хостит и обслуживает инстанс: инфраструктура, резервные копии, часть мер безопасности и т. д.
Self-hosted n8n на VPS или другом типе сервера — это ваш собственный экземпляр: контейнер или bare metal, база данных, свои переменные окружения, свои файлы.
Вы запускаете n8n на своем сервере и сами отвечаете за:
n8n отдельно подчеркивает, что для self-hosted шифрование данных at rest — зона ответственности хостера или владельца сервера, а TLS обычно делается через reverse proxy.
Обычно нужно забрать:
Workflow в n8n хранятся в JSON и спокойно экспортируются и импортируются.
Экспортированный JSON содержит имена и ID credentials — сами по себе ID не секрет, но имена могут быть чувствительными (если вы назвали credential “prod-mastercard-api-key”).
В self-hosted креды хранятся в базе данных в зашифрованном виде, и для расшифровки нужен ключ.
В n8n Cloud credentials не экспортируются (придется заводить заново).
n8n на первом запуске генерирует случайный ключ и сохраняет его в ~/.n8n, затем использует для шифрования credentials перед записью в БД. Этот ключ можно (и часто нужно) задавать явно через N8N_ENCRYPTION_KEY.
Если вы переносите базу или том с данными, но поменяете ключ — старые credentials не подтянутся.
В Docker-рекомендациях n8n явно сказано маппить постоянный volume на /home/node/.n8n для сохранности данных между перезапусками.
Даже при PostgreSQL persist .n8n все равно рекомендуется, потому что там остаются важные данные (ключи шифрования, логи инстанса и т. п.).
По умолчанию n8n использует SQLite для credentials, workflow и executions, но поддерживает PostgreSQL через переменные окружения.
Прибавьте к этому списку еще историю выполнения и очередь задач, если они вам необходимы.
Сценариев миграции по сути два — точечный и полный бэкап инстанса.
В теории можно:
Но тут слишком много “если”. Поэтому лучше перейдем к более реалистичному варианту.
Если вы арендовали чистый сервер, то надо начать с Docker и установки n8n.
В терминале выполните следующие команды, заменив <YOUR_TIMEZONE> на свой часовой пояс:
docker volume create n8n_data
docker run -it --rm \
--name n8n \
-p 5678:5678 \
-e GENERIC_TIMEZONE="<YOUR_TIMEZONE>" \
-e TZ="<YOUR_TIMEZONE>" \
-e N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true \
-e N8N_RUNNERS_ENABLED=true \
-v n8n_data:/home/node/.n8n \
docker.n8n.io/n8nio/n8n
Эта команда создает том для хранения постоянных данных, загружает необходимый образ n8n и запускает контейнер со следующими настройками:
Откройте http://localhost:5678, чтобы получить доступ к n8n.
По умолчанию n8n использует SQLite, но также поддерживает PostgreSQL через настройку с помощью переменных среды.
Используйте эти команды, если хотите работать с n8n на PostgreSQL. Заменив плейсхолдеры (обозначенные угловыми скобками, например <POSTGRES_USER>) своими значениями:
docker volume create n8n_data
docker run -it --rm \
--name n8n \
-p 5678:5678 \
-e GENERIC_TIMEZONE="<YOUR_TIMEZONE>" \
-e TZ="<YOUR_TIMEZONE>" \
-e N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true \
-e N8N_RUNNERS_ENABLED=true \
-e DB_TYPE=postgresdb \
-e DB_POSTGRESDB_DATABASE=<POSTGRES_DATABASE> \
-e DB_POSTGRESDB_HOST=<POSTGRES_HOST> \
-e DB_POSTGRESDB_PORT=<POSTGRES_PORT> \
-e DB_POSTGRESDB_USER=<POSTGRES_USER> \
-e DB_POSTGRESDB_SCHEMA=<POSTGRES_SCHEMA> \
-e DB_POSTGRESDB_PASSWORD=<POSTGRES_PASSWORD> \
-v n8n_data:/home/node/.n8n \
docker.n8n.io/n8nio/n8n
Полный файл docker-compose для PostgreSQL в репозитории хостинга n8n.
Обновите n8n в Docker Desktop через вкладку «Images» и выберите «Pull» в контекстном меню, чтобы загрузить последнюю версию образа n8n.
Или обновитесь через командную строку.
Загрузить последнюю (стабильную) версию:
docker pull docker.n8n.io/n8nio/n8n
Загрузить определенную версию:
docker pull docker.n8n.io/n8nio/n8n:1.81.0
Загрузить следующую (нестабильную) версию:
docker pull docker.n8n.io/n8nio/n8n:next
После загрузки обновленного образа остановите контейнер n8n и запустите его снова. Опять же, можно через командную строку.
Сперва найдите ID вашего контейнера:
docker ps -a
Замените <container_id> в командах ниже.
Остановите контейнер:
docker stop <container_id>
Удалите контейнер:
docker rm <container_id>
Запустите контейнер:
docker run --name=<container_name> [options] -d docker.n8n.io/n8nio/n8n
Если вы запускаете n8n с помощью файла Docker Compose, то вот шаги для вас:
Перейдите в каталог, содержащий файл docker compose:
cd </path/to/your/compose/file/directory>
Загрузите последнюю версию:
docker compose pull
Остановите и удалите старую версию:
docker compose down
Запустите контейнер:
docker compose up -d
Именно этот шаг вы можете пропустить, если у вас VPS с предустановленным n8n. Подходящий тариф можно выбрать вот тут.
В интерфейсе n8n Cloud:
На self-hosted:
Так можно быстро перенести только нужные сценарии.
Учетные данные (credentials) не могут быть экспортированы из облака по соображениям безопасности. Их придется вводить заново вручную.
Если вы используете триггеры (GitHub, Stripe, Telegram, формы, вебхуки), почти всегда есть reverse proxy и публичный домен. Тогда:
Если вы использовали или глобальные переменные, то в Cloud они настроены на стороне n8n. Поэтому в self-hosted вы прописываете их сами в .env файле контейнера или в настройках Docker Compose.
Запустите самые критичные сценарии вручную. После убедитесь, что OAuth callback URL и webhooks соответствуют новому домену.
И вот только потом меняйте DNS и интеграции на новый endpoint.
Переезд с сервера на сервер провести легче чем из облака. Можно перенести все как есть (volume/db) или провести экспорт и импорт через CLI.
Подходит, если вы хотите максимально идентичный инстанс.
Такой переезд подходит, если вы хотите перенос workflows и credentials, а не всего состояния.
n8n export:workflow --all --output=backups/latest/workflows.json
# или в раздельные файлы
n8n export:workflow --backup --output=backups/latest/
n8n export:credentials --all --output=backups/latest/credentials.json
Есть флаг --decrypted, который экспортирует credentials в открытом виде. Это удобно, если вы мигрируете на инстанс с другим secret key, но это чувствительные данные — храните и передавайте такой файл максимально осторожно.
n8n import:workflow --input=workflows.json
# или импорт из директории (если экспортировали отдельными файлами)
n8n import:workflow --separate --input=backups/latest/
n8n import:credentials --input=credentials.json
n8n import:credentials --separate --input=backups/latest/
После тест как обычно.
docs.n8n.io и support.n8n.io — два ресурса, которые расскажут про все дополнительные нюансы переноса. Или можно сразу написать в поддержку is*hosting, если вы переезжаете на n8n VPS.
Если у webhook URL все еще старый домен, часть триггеров просто перестанет приходить. А для reverse proxy у n8n есть отдельный гайд с обязательными переменными и заголовками.
Даже если вы используете Postgres, n8n рекомендует сохранять .n8n как persistent volume, потому что там остаются ключи, логи и другие данные инстанса.
Если используете --decrypted для credentials, вы фактически делаете дамп секретов. Всегда помните, что вся чувствительная информация будет видна в файлах.
Останется только проверить несколько рабочих цепочек и можно считать переезд завершенным.