← AI process automation with n8n
06 / 07 · 40 min

Self-hosting, credentials, and security

n8n Cloud versus self-hosted: Docker and Postgres, N8N_ENCRYPTION_KEY, credential storage, HTTPS, queue mode, and execution pruning.

Lesson content is currently available in Russian.

What you will learn

  • →Осознанно выбирать между n8n Cloud и self-hosted.
  • →Разворачивать n8n в Docker с Postgres, N8N_ENCRYPTION_KEY и корректным WEBHOOK_URL.
  • →Хранить секреты в credentials, закрывать периметр и масштабироваться через queue mode.

Cloud или self-hosted: честный выбор

n8n Cloud — управляемый сервис: обновления, бэкапы и публичный HTTPS-адрес для вебхуков из коробки; платите по плану, данные живут на инфраструктуре n8n. Self-hosted — образ docker.n8n.io/n8nio/n8n, который вы запускаете сами: полный контроль над данными, версией и окружением, доступ к $env в expressions, любые community-ноды — но TLS, бэкапы, обновления и мониторинг теперь ваша работа. Лицензия n8n (Sustainable Use License, fair-code) позволяет бесплатный self-hosting для внутренних нужд компании.

Когда что. Cloud: команда без DevOps-ресурса, быстрый старт, некритичные данные. Self-hosted: персональные данные и комплаенс (данные не покидают ваш контур), интеграции с внутренними сервисами за VPN, тяжёлые нагрузки, кастомные ноды.

Одно требование объединяет оба пути: для входящих вебхуков инстанс должен быть доступен извне по HTTPS. В Cloud это данность; в self-hosted понадобятся домен, reverse proxy с TLS и правильный WEBHOOK_URL — иначе Telegram и Stripe просто не достучатся, а webhook-ноды будут показывать localhost-адреса.

Для локальной разработки с внешними вебхуками выручает туннель (например, ngrok) с подстановкой его адреса в WEBHOOK_URL.

Docker-запуск: Postgres и N8N_ENCRYPTION_KEY

Минимальный запуск — docker run с volume: данные и SQLite-база лежат в /home/node/.n8n. Для production переходите на Postgres и фиксируйте ключ шифрования:

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    ports:
      - "5678:5678"
    environment:
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=${DB_PASSWORD}
      - WEBHOOK_URL=https://n8n.example.com/
      - GENERIC_TIMEZONE=Europe/Paris
    volumes:
      - n8n_data:/home/node/.n8n
  postgres:
    image: postgres:16
    environment:
      - POSTGRES_DB=n8n
      - POSTGRES_USER=n8n
      - POSTGRES_PASSWORD=${DB_PASSWORD}
    volumes:
      - pg_data:/var/lib/postgresql/data
volumes:
  n8n_data:
  pg_data:

N8N_ENCRYPTION_KEY — самая важная переменная инсталляции: этим ключом шифруются все credentials в базе. Потеряете ключ — потеряете ВСЕ сохранённые токены и пароли, восстановления нет. Задайте его явно до первого запуска (иначе n8n сгенерирует случайный и положит в файл внутри volume) и храните в секрет-менеджере вместе с бэкапами БД.

WEBHOOK_URL — внешний адрес инстанса за reverse proxy: без него webhook-ноды показывают внутренний хост. Обновления: фиксируйте тег версии вместо latest, читайте release notes и снимайте бэкап Postgres перед апгрейдом.

Credentials: как хранить секреты правильно

Credentials в n8n шифруются (AES) и хранятся в базе; расшифровать их можно только с N8N_ENCRYPTION_KEY. Отсюда несколько практических правил.

Секрет живёт ТОЛЬКО в credentials. Ключ, вписанный в URL ноды, заголовок или Code node, уезжает в экспортированный JSON workflow, а оттуда — в git и чужие руки. Экспорт workflow секретов не содержит: в JSON попадают только имена и id credentials, поэтому делиться workflow-файлами безопасно.

Разделяйте окружения и права: отдельные credentials для dev и prod; токен с минимальными правами — если нода только читает таблицу, ей не нужен админ-токен. В команде используйте sharing credentials, а не «один общий админ-токен на всех» — иначе ротация превращается в квест.

Переменные окружения доступны в expressions через $env (self-hosted). Помните: значение, выведенное expression-ом в поле данных, попадёт в сохранённый execution — не гоняйте секреты через данные workflow.

Для enterprise-инсталляций есть внешние секрет-хранилища (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault): n8n подтягивает секреты оттуда, ротация происходит централизованно. На бесплатном self-hosted тот же эффект частично даёт дисциплина: секреты в env, доставка через секрет-менеджер оркестратора, и никогда — в образ или репозиторий.

Защита инстанса и queue mode

Периметр. Редактор и API n8n не должны торчать в интернет голыми: reverse proxy (nginx, Caddy, Traefik) с TLS, доступ к редактору — по SSO/VPN или хотя бы allowlist IP, для аккаунтов включите 2FA. Публичным обязан быть только путь вебхуков. На webhook-эндпоинты вешайте Header Auth и проверку подписи из урока 3. Если публичный REST API n8n не используете — отключите его: N8N_PUBLIC_API_DISABLED=true.

Community-ноды — чужой код, который исполняется с доступом к вашим credentials. Ставьте только то, чему доверяете, и читайте, что нода делает.

Масштабирование. Один процесс n8n упирается в CPU на тяжёлых потоках. Queue mode (EXECUTIONS_MODE=queue) разделяет роли: main-инстанс принимает триггеры и складывает задания в Redis, отдельные worker-процессы (n8n worker) их исполняют; workers масштабируются горизонтально простым увеличением количества.

Гигиена базы: таблица executions растёт бесконечно, если её не чистить. Включите прунинг: EXECUTIONS_DATA_PRUNE=true и EXECUTIONS_DATA_MAX_AGE=168 (часов — неделя истории). Для экономии места можно сохранять только упавшие executions успешных потоков — но в первые недели production держите полную историю: она — главный инструмент отладки.

Practice

Production-ready инстанс

Поднимите n8n в Docker Compose с Postgres, явным N8N_ENCRYPTION_KEY и WEBHOOK_URL, перенесите workflow из урока 5 и проверьте production webhook снаружи (туннель или публичный хост).

Deliverable

docker-compose.yml с .env.example (без реальных секретов) и чеклист безопасности из 8-10 пунктов с отметками о выполнении.

Checkpoint

Объясните, что произойдёт с вашими credentials при переезде инстанса на новый сервер и как вы к этому подготовились.

  • ✓ Назван N8N_ENCRYPTION_KEY и его роль; ключ хранится вне контейнера.
  • ✓ Секреты не встречаются в экспортированных JSON workflow и полях нод.
  • ✓ Публично доступны только webhook-эндпоинты; редактор закрыт TLS и аутентификацией.

Check yourself

Что произойдёт, если при переезде инстанса потерять N8N_ENCRYPTION_KEY?

01Что произойдёт, если при переезде инстанса потерять N8N_ENCRYPTION_KEY?

Почему секрет нельзя писать прямо в поле ноды или Code node?

02Почему секрет нельзя писать прямо в поле ноды или Code node?

Зачем нужна переменная WEBHOOK_URL?

03Зачем нужна переменная WEBHOOK_URL?

Что даёт queue mode (EXECUTIONS_MODE=queue)?

04Что даёт queue mode (EXECUTIONS_MODE=queue)?

Зачем включать EXECUTIONS_DATA_PRUNE?

05Зачем включать EXECUTIONS_DATA_PRUNE?

Sources

Self-hosting, credentials, and security · AI process automation with n8n · VORCL