n8n: автоматизация рабочих процессов и self-hosted развёртывание на ВМ и в Kubernetes

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

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

Разберём два варианта развёртывания для production: Docker Compose на облачной ВМ и Helm-чарт в Kubernetes. В обоих случаях предусмотрим внешнюю БД, постоянное хранение данных, HTTPS и очереди.

n8n — инструмент автоматизации рабочих процессов. Сценарий собирают в визуальном редакторе из нод (шагов) и связей между ними, а выполняет его серверный движок. Если готовых нод недостаточно, в сценарий можно добавить Code node с кодом на JavaScript или Python.

Большинство задач интеграции решается с помощью базовых возможностей платформы:

• визуального редактора сценариев из нод и связей;
• библиотеки встроенных интеграций с внешними сервисами и универсальной ноды HTTP Request для остальных подключений;
• Code node для собственной логики внутри сценария;
• трёх типов триггеров: webhook (входящий HTTP-запрос), расписания по cron и событийных;
• переменных окружения и учётных данных для подключения к внешним сервисам (credentials), которые хранятся отдельно от сценария.

Лицензия: модель fair-code

n8n распространяется под Sustainable Use License. Это модель fair-code, которая не относится к классическим open-source-лицензиям по определению OSI (Open Source Initiative). Исходный код доступен для просмотра, модификации и развёртывания на инфраструктуре организации, но коммерческое использование ограничено. Согласно документации n8n, предоставлять платформу третьим лицам как конкурирующий SaaS нельзя.

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

Self-hosted против n8n.cloud

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

• Main process обслуживает веб-интерфейс и REST API, запускает сценарии по расписанию и принимает webhook-запросы.
• Worker process выполняет сценарии в режиме очереди (queue mode). В Kubernetes worker-процессы запускаются в отдельных подах, в Docker Compose — в отдельных контейнерах.
• База данных хранит сценарии, зашифрованные учётные данные (credentials) и историю выполнений.
• Redis служит брокером очереди в queue mode.
• Хранилище бинарных данных содержит файлы, которые проходят через сценарии: вложения, выгрузки и изображения.

В queue mode основной процесс принимает webhook-запрос или обрабатывает срабатывание расписания и помещает задачу в очередь Redis. Свободный worker-процесс забирает задачу и выполняет сценарий, после чего результат и история выполнения записываются в базу данных. Такая схема позволяет масштабировать систему горизонтально: при росте нагрузки можно добавлять worker-процессы (см. документацию по queue mode).

n8n официально поддерживает развёртывание через Docker и Docker Compose (см. документацию по установке). Образ

публикуется в Docker Hub. Это самый быстрый способ развернуть платформу и запустить первый сценарий.

Требования к ВМ

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

Для первого запуска и знакомства:

• 2 vCPU, 4 ГБ RAM, 20 ГБ диска;
• Ubuntu 22.04 LTS;
• открытые порты 80 и 443. Порт прямого доступа к n8n открывайте только на стенде разработки.

Для production:

• 4 vCPU, 8 ГБ RAM;
• отдельный управляемый PostgreSQL вместо базы на той же ВМ;
• отдельный диск или объектное хранилище для бинарных данных, если сценарии обрабатывают файлы.

Для такой конфигурации у Cloud Servers в VK Cloud есть безлимитный трафик на скорости 1 Гбит/с, бесплатные внешние IP-адреса и программная СХД с тройной репликацией. Webhook-запросы и выгрузки не расходуют квоту трафика. Управление через CLI, API и Terraform-провайдер позволяет описать стенд в коде и воспроизводить его конфигурацию. Перед изменением конфигурации ВМ или размера диска в production проверьте документацию платформы: порядок действий и необходимость перезагрузки определяются регламентом сервиса.

На конец 2025 года управляемый PostgreSQL в Cloud Databases поддерживал версии 12–16. Актуальный список проверяйте в документации. Сервис автоматически создаёт резервные копии в объектном хранилище и поддерживает Point-in-Time Recovery. Автомасштабирование доступно только для дисков: конфигурацию CPU и RAM (флейвор) и число реплик нужно менять вручную. По мере роста истории выполнений n8n место на диске добавится автоматически, но переход на более мощный инстанс нужно планировать заранее.

Шаг 1. Установка Docker

Установим Docker Engine и плагин Compose из официального репозитория Docker:

sudo apt update && sudo apt upgrade -y
sudo apt install -y ca-certificates curl gnupg

sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
  | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" \
  | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

sudo usermod -aG docker $USER
newgrp docker

После установки команда

должна вывести версию плагина, а — завершиться без ошибки доступа к сокету.

Шаг 2. Базовый docker-compose.yml на SQLite

Этот вариант подходит для первого запуска и проверки гипотез. Он использует встроенную базу данных и хранит всё состояние в одном томе:

version: "3.8"

services:
  n8n:
    image: n8nio/n8n:latest
    restart: always
    ports:
      - "5678:5678"
    environment:
      - N8N_HOST=${N8N_HOST}
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - NODE_ENV=production
      # WEBHOOK_URL задаёт адрес, который n8n подставляет
      # в webhook-ноды; без него вебхуки указывают на localhost
      - WEBHOOK_URL=https://${N8N_HOST}/
      - GENERIC_TIMEZONE=Europe/Moscow
    volumes:
      - n8n_data:/home/node/.n8n

volumes:
  n8n_data:
    driver: local

Рядом с

создайте файл :

N8N_HOST=n8n.example.com

Имена и значения переменных сверяйте с документацией по переменным окружения для своей версии образа: набор параметров меняется между релизами.

Тег

оставлен здесь для простоты первого запуска. В production зафиксируйте конкретную версию: с при перезапуске контейнера может подтянуться новый образ, и обновление произойдёт вне запланированного окна. Меняйте версию явно и в выбранное вами время.

Шаг 3. Production-вариант: PostgreSQL, Redis и queue mode

В этой конфигурации основной процесс и worker работают в отдельных контейнерах, база данных вынесена за пределы ВМ, а общие настройки собраны в YAML-якорь:

version: "3.8"

# Общий блок переменных для main и worker: оба процесса
# должны видеть одну БД, один Redis и один ключ шифрования
x-n8n-common: &n8n-common
  image: n8nio/n8n:latest
  environment:
    - DB_TYPE=postgresdb
    - DB_POSTGRESDB_HOST=${POSTGRES_HOST}
    - DB_POSTGRESDB_PORT=5432
    - DB_POSTGRESDB_DATABASE=${POSTGRES_DB}
    - DB_POSTGRESDB_USER=${POSTGRES_USER}
    - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
    - EXECUTIONS_MODE=queue
    - QUEUE_BULL_REDIS_HOST=redis
    - QUEUE_BULL_REDIS_PORT=6379
    - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
    - N8N_HOST=${N8N_HOST}
    - N8N_PROTOCOL=https
    - WEBHOOK_URL=https://${N8N_HOST}/
    - GENERIC_TIMEZONE=Europe/Moscow

services:
  redis:
    image: redis:7-alpine
    restart: always
    volumes:
      - redis_data:/data
    command: redis-server --appendonly yes

  n8n:
    <<: *n8n-common
    restart: always
    ports:
      - "5678:5678"
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      - redis
    command: n8n start

  n8n-worker:
    <<: *n8n-common
    restart: always
    depends_on:
      - redis
    command: n8n worker

volumes:
  n8n_data:
  redis_data:

Файл

:

N8N_HOST=n8n.example.com
POSTGRES_HOST=db.internal
POSTGRES_DB=n8n
POSTGRES_USER=n8n
POSTGRES_PASSWORD=<strong-password>
N8N_ENCRYPTION_KEY=<32-char-random-key>

Значение

возьмите из консоли управления базой данных. Если управляемый PostgreSQL и ВМ находятся в одной приватной сети, соединение с базой не выходит в интернет.

Сгенерируйте ключ шифрования:

openssl rand -hex 16

Ключ из

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

Количество worker-контейнеров можно увеличить через Compose:

docker compose up -d --scale n8n-worker=3

Шаг 4. HTTPS через nginx и Certbot

n8n обслуживает веб-интерфейс по HTTP. Порт задаётся переменной

; в примерах выше используется 5678. Настроим терминацию TLS на nginx и получим сертификат Let's Encrypt:

sudo apt install -y nginx certbot python3-certbot-nginx

sudo certbot --nginx -d n8n.example.com

Конфигурация

:

server {
    listen 80;
    server_name n8n.example.com;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl;
    server_name n8n.example.com;

    ssl_certificate /etc/letsencrypt/live/n8n.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/n8n.example.com/privkey.pem;

    location / {
        proxy_pass http://localhost:5678;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_http_version 1.1;
        # Upgrade-заголовки нужны редактору для WebSocket-соединения
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        # Таймауты для долгих сценариев: иначе nginx может
        # закрыть соединение до завершения workflow
        proxy_read_timeout 300s;
        proxy_send_timeout 300s;
    }
}

Активируем конфигурацию и запускаем стек:

sudo ln -s /etc/nginx/sites-available/n8n /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
docker compose up -d

Ограничьте доступ к интерфейсу n8n перед публикацией в интернете. Минимальный набор мер — директивы

и в блоке nginx, отдельный блок для webhook-эндпоинтов, к которым обращаются внешние системы, и запрет прямого доступа к порту приложения в правилах безопасности ВМ.

Шаг 5. Проверка, что всё работает

# Все контейнеры в статусе running
docker compose ps

# В логах main нет ошибок подключения к БД и Redis
docker compose logs --tail=50 n8n

# Worker подключился к очереди
docker compose logs --tail=50 n8n-worker

Откройте

в браузере, создайте учётную запись владельца установки и соберите сценарий из двух нод: Schedule Trigger и HTTP Request. Запустите его вручную. Если выполнение появилось в истории, основной процесс, очередь, worker и база данных связаны корректно.

Отдельно проверьте webhook-ноду: адрес в редакторе должен начинаться с вашего домена, а не с

. Если редактор показывает , переменная не задана.

Если у команды уже есть Kubernetes-кластер, удобнее развернуть n8n через Helm. Worker-поды можно масштабировать независимо от основного процесса, Helm поддерживает обновление и откат, а постоянное хранение данных обеспечивает класс хранилища кластера. n8n поддерживает официальный Helm-чарт в отдельном репозитории проекта.

Предварительные требования

• Кластер Kubernetes. Managed Kubernetes от VK Cloud (прежнее название — Cloud Containers) совместим со стандартным Kubernetes API и сертифицирован CNCF как Certified Kubernetes — Hosted, поэтому чарт можно установить без адаптации под платформу.
• Helm 3 и
  kubectl
  , настроенный для работы с кластером.
• Ingress-контроллер nginx-ingress.
• cert-manager с настроенным
  ClusterIssuer
  для выпуска TLS-сертификатов.
• Внешний управляемый PostgreSQL вместо базы внутри кластера.

При подготовке кластера учитывайте два условия. Managed Kubernetes от VK Cloud поддерживает каждую версию Kubernetes 14 месяцев и уведомляет об окончании поддержки за 30 дней. Обновление проходит последовательно методом rolling update: сначала обновляются master-узлы, затем worker-узлы (см. документацию платформы). Часть worker-подов n8n при этом будет перезапущена, поэтому долгие сценарии в queue mode стоит делать идемпотентными.

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

Шаг 1. Подключить Helm-репозиторий

helm repo add n8n https://n8n-io.github.io/n8n-helm-chart
helm repo update
helm search repo n8n

Последняя команда покажет доступные версии чарта и приложения. Зафиксируйте обе: версию чарта укажите в

, а версию приложения — в теге образа.

Шаг 2. Собрать values.yaml

Структура

меняется между версиями чарта. Перед настройкой выгрузите значения по умолчанию командой и сверьте ключи с README чарта. Пример ниже показывает, какие блоки нужно настроить для production:

replicaCount: 1

image:
  # В production вместо latest укажите конкретную версию,
  # которую вы проверили на стенде
  tag: "latest"

config:
  generic:
    timezone: "Europe/Moscow"
  database:
    type: postgresdb
    postgresdb:
      host: "db.internal"
      port: 5432
      database: "n8n"
      user: "n8n"
  executions:
    mode: queue

secret:
  database:
    postgresdb:
      password: "<your-password>"
  encryptionKey: "<32-char-key>"

redis:
  enabled: true
  auth:
    enabled: false

worker:
  enabled: true
  replicaCount: 2

ingress:
  enabled: true
  className: nginx
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
  hosts:
    - host: n8n.example.com
      paths:
        - path: /
          pathType: Prefix
  tls:
    - secretName: n8n-tls
      hosts:
        - n8n.example.com

persistence:
  enabled: true
  size: 10Gi
  # Имя класса хранилища посмотрите в своём кластере:
  # kubectl get storageclass
  storageClass: "<storage-class>"

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

. В production храните их в отдельно созданном Kubernetes Secret или внешнем хранилище секретов, а в чарте настройте ссылку на существующий секрет. Redis без аутентификации допустим только внутри кластера, где доступ к нему ограничен сетевой политикой.

Шаг 3. Установка

kubectl create namespace n8n

helm install n8n n8n/n8n \
  --namespace n8n \
  --values values.yaml \
  --wait

# Проверить статус
kubectl get pods -n n8n
kubectl get ingress -n n8n

После установки поды основного процесса и worker-процессов должны перейти в статус

, у Ingress должен появиться адрес, а cert-manager должен создать секрет . Если сертификат не выпускается, проверьте события командой .

Шаг 4. Обновление и откат

# Обновить версию n8n
helm upgrade n8n n8n/n8n \
  --namespace n8n \
  --values values.yaml \
  --set image.tag="1.60.0"

# Посмотреть историю релизов
helm history n8n --namespace n8n

# Откатить при проблемах
helm rollback n8n 1 --namespace n8n

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

Шаг 5. Горизонтальное масштабирование worker-подов

Увеличить число worker-подов вручную можно командой:

kubectl scale deployment n8n-worker --replicas=5 -n n8n

Для автоматического масштабирования по загрузке CPU используйте HorizontalPodAutoscaler:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: n8n-worker-hpa
  namespace: n8n
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: n8n-worker
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

Масштабирование по CPU подходит не для всех сценариев. Если они большую часть времени ждут ответа внешнего API, нагрузка на процессор остаётся низкой, и HPA не реагирует на рост очереди. В этом случае настройте автомасштабирование по внешней метрике длины очереди в Redis или поддерживайте фиксированный запас worker-подов.

Число реплик основного процесса нельзя увеличивать так же свободно: он отвечает за планировщик. Поддержка нескольких main-инстансов зависит от версии и редакции n8n. Перед установкой

больше единицы проверьте доступные режимы в документации по масштабированию.

При резервном копировании особенно важно сохранить

. Без этого ключа сценарии из базы восстановятся, но расшифровать учётные данные не получится: доступы к внешним системам придётся настраивать заново. Храните ключ в менеджере секретов или Kubernetes Secret, а его копию — вместе с остальными критичными секретами команды. Не добавляйте его в Git-репозиторий.

Базовые команды для резервного копирования и восстановления PostgreSQL:

# Резервное копирование
pg_dump -h $POSTGRES_HOST -U n8n n8n | gzip > n8n_$(date +%Y%m%d).sql.gz

# Восстановление
gunzip -c n8n_20240115.sql.gz | psql -h $POSTGRES_HOST -U n8n n8n

Для управляемой базы ручной

дополняет штатные механизмы резервного копирования. Автоматические копии в объектном хранилище и Point-in-Time Recovery позволяют восстановить базу на произвольный момент времени, тогда как ежедневный дамп сохраняет её состояние только на момент создания копии.

История выполнений требует отдельного места в базе. Она растёт с числом запусков, поэтому выделенные на старте 20 ГБ могут быстро закончиться. Настройте автоматическую очистку через

и , иначе диск PostgreSQL придётся регулярно расширять.

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

Чаще всего упускают две настройки.

определяет часовой пояс расписаний: если не задать его явно, сценарий с запуском в 9 утра сработает по UTC. Очистку истории через и стоит настроить сразу, пока база ещё не заполнила диск.