Среды: dev, staging, production

Сценарий, который работает у вас на тестовом инстансе, и сценарий, который работает в продакшене, — это разные объекты. Их нужно разделять, иначе вы будете править рабочий сценарий на ходу и однажды этим сломаете боевые процессы.

Примечание. Конкретные возможности (работа со средами, окружениями, тегами) отличаются между Cloud-, self-hosted- и Enterprise-версиями n8n. Принципы — те же. Если в вашей версии нет встроенных «environments» — используйте описанные ниже общие подходы.

Зачем разделять

В разных средах разные риски:

  • Dev (или local) — здесь вы экспериментируете, ломаете и собираете заново. Никаких реальных клиентов.
  • Staging — копия продакшена с похожим, но «безопасным» окружением. Здесь проверяют изменения перед выкаткой.
  • Production — здесь работают реальные данные и реальные клиенты. Сюда не лазают «попробовать».

Когда у вас всё в одном месте, риск нечаянно отправить тестовое письмо реальному клиенту или провести тестовую оплату — близок к 100% «когда-нибудь».

Как это сделать на практике

Есть несколько уровней разделения, в порядке возрастания серьёзности:

  1. Один инстанс, два набора сценариев. Самое простое: на одном инстансе вы держите два сценария — Order processing (dev) и Order processing (prod). Они различаются учётными данными и URL-ами. Подходит для маленьких проектов и одного-двух людей.

  2. Один инстанс, разные credentials. Лучше: создаются отдельные учётные данные «sandbox» и «live», и для теста вы переключаете credentials в одной копии сценария. Минус — легко перепутать.

  3. Два разных инстанса n8n. Самое надёжное: отдельные сервера/Docker-контейнеры/cloud-аккаунты для dev и prod. Сценарий в dev никак не может физически достучаться до боевых данных. Это требует чуть больше инфраструктуры, но снимает целый класс проблем.

Если ваш сценарий обрабатывает деньги, персональные данные или что-то критичное для бизнеса — выбирайте вариант 3.

Что должно различаться между средами

  • Учётные данные — у dev должны быть свои (sandbox-ключи API, тестовые базы, песочницы платёжных систем).
  • URL-адреса webhook'ов — они автоматически разные на разных инстансах. Не зашивайте production-URL в код, который выгружаете в dev.
  • Расписания — в dev сценарии по расписанию выгоднее держать выключенными, чтобы они случайно не запускались.
  • Получатели уведомлений — в dev уведомления могут идти в отдельный «dev-alerts» канал, а не в общий боевой.

Переменные окружения

В self-hosted n8n многое можно вынести в переменные окружения (env vars). Это переменные, которые задаются на уровне сервера/контейнера, а сценарий обращается к ним через специальное выражение (имя переменной зависит от версии — обычно что-то вроде $env.MY_VAR).

Это удобно, чтобы:

  • иметь один и тот же файл сценария в dev и prod, но с разными значениями (например, разный домен webhook-цели);
  • не хранить в самих сценариях URL-адреса бэкендов и прочую конфигурацию.

Конкретный синтаксис обращения к env-переменным в выражениях лучше посмотреть в документации к вашей версии n8n.

Tagging

В большинстве версий n8n поддерживается тегирование сценариев. Полезные теги:

  • prod / staging / dev — чтобы фильтровать список сценариев.
  • critical — выделить те, за которыми смотрят в первую очередь.
  • deprecated — отметить, что сценарий устарел и его не трогают.

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