Docker Compose для n8n: оптимальная конфигурация с PostgreSQL и Redis

Введение

Когда вы начинаете знакомство с n8n, самый простой способ закрепить результат — запустить его локально через npm или базовый Docker-контейнер со встроенной базой данных SQLite. Этого вполне достаточно для тестирования пары-тройки ботов. Однако, как только ваша автоматизация переходит в стадию Production, и от нее начинает зависеть реальный бизнес (например, обработка сотен заказов в день или массовые рассылки), базовая установка перестает справляться. SQLite блокируется при одновременной записи, памяти не хватает, а сервер "падает".

Для создания отказоустойчивой, масштабируемой инфрастурктуры n8n в 2025 году стандартом де-факто является связка из n8n + PostgreSQL + Redis, управляемая через Docker Compose. В этой статье мы шаг за шагом разберем "боевую" конфигурацию, которая выдержит высокие нагрузки и обеспечит бесперебойную работу ваших сценариев.

Почему SQLite больше не подходит?

По умолчанию контейнер n8n хранит все данные (настройки рабочих процессов, учетные данные, историю выполнений) во встроенном файле базы данных SQLite. У этой архитектуры есть фундаментальный архитектурный изъян для высоконагруженных систем: database lock (блокировка базы данных). SQLite может обрабатывать только одну операцию записи (Write) в единицу времени.

Представьте, что вы запустили рассылку на 5000 контактов через Webhook. Если 500 человек одновременно кликнут по ссылке, 500 воркеров n8n попытаются одновременно записать результат в базу. SQLite заблокирует файл, возникнет очередь, которая мгновенно превысит таймаут, и 450 процессов упадут с ошибкой SQLITE_BUSY.

Перевод системы на полноценную реляционную базу данных PostgreSQL (версии 15 или 16) решает эту проблему. Postgres великолепно справляется с огромным количеством параллельных транзакций, обеспечивая стабильную запись логов выполнения.

Роль Redis: Очереди и масштабирование (Queues)

Переход на Postgres — это первый шаг. Второй шаг — это внедрение Redis. Зачем n8n нужен In-Memory кэш?

Допустим, ваш сценарий обрабатывает тяжелое видео для Telegram-бота: скачивает файл, конвертирует его через FFmpeg и отправляет обратно. Эта задача забирает почти 100% ядра процессора. Если в этот момент придет еще 10 таких запросов, ваш сервер (даже виртуальный VPS на 4 ядра) "ляжет" из-за OOM (Out Of Memory).

Чтобы этого избежать, разработчики n8n добавили режим Queue Mode. В этом режиме архитектура меняется:

• Узел Main (Webhooks): Только принимает запросы, быстро отвечает "200 OK" и складывает задачу в очередь (в Redis).
• Узлы Workers (Воркеры): Отдельные контейнеры (может быть 1, а может быть 10 на разных серверах), которые забирают задачи из Redis по мере освобождения ресурсов и выполняют тяжелую логику.

Если вдруг задач стало слишком много, они просто копятся в памяти Redis, ожидая своей очереди, а не 'уронят' всю платформу.

Пишем "боевой" docker-compose.yml

Давайте соберем все воедино. Вот пример Production-ready манифеста docker-compose.yml. Обратите внимание, что мы используем переменные окружения (.env файл) для сокрытия паролей.

version: '3.8'

volumes:
  db_storage:
  n8n_storage:
  redis_storage:

services:
  # Основная база данных
  postgres:
    image: postgres:16-alpine
    restart: always
    environment:
      - POSTGRES_USER=${DB_USER}
      - POSTGRES_PASSWORD=${DB_PASSWORD}
      - POSTGRES_DB=${DB_NAME}
    volumes:
      - db_storage:/var/lib/postgresql/data
    healthcheck:
      test: ['CMD-SHELL', 'pg_isready -h localhost -U ${DB_USER} -d ${DB_NAME}']
      interval: 5s
      timeout: 5s
      retries: 10

  # Очередь задач
  redis:
    image: redis:7-alpine
    restart: always
    volumes:
      - redis_storage:/data
    command: redis-server --appendonly yes --requirepass ${REDIS_PASSWORD}

  # Главный узел n8n (Webhooks + UI)
  n8n-main:
    image: docker.n8n.io/n8nio/n8n
    restart: always
    environment:
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=${DB_NAME}
      - DB_POSTGRESDB_USER=${DB_USER}
      - DB_POSTGRESDB_PASSWORD=${DB_PASSWORD}
      - EXECUTIONS_MODE=queue
      - QUEUE_BULL_REDIS_HOST=redis
      - QUEUE_BULL_REDIS_PASSWORD=${REDIS_PASSWORD}
      - N8N_HOST=${SUBDOMAIN}.${DOMAIN_NAME}
      - WEBHOOK_URL=https://${SUBDOMAIN}.${DOMAIN_NAME}/
      - NODE_ENV=production
    ports:
      - "5678:5678"
    volumes:
      - n8n_storage:/home/node/.n8n
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_started

  # Узел обработки задач (Воркер 1)
  n8n-worker-1:
    image: docker.n8n.io/n8nio/n8n
    restart: always
    command: worker
    environment:
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      # ... все те же переменные подключения к DB и Redis как у n8n-main ...
      - EXECUTIONS_MODE=queue
      - QUEUE_BULL_REDIS_HOST=redis
      - QUEUE_BULL_REDIS_PASSWORD=${REDIS_PASSWORD}
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_started
        

Тюнинг (Optimization) и уборка логов

Даже с Postgres вы можете столкнуться с проблемой нехватки места на жестком диске. По умолчанию n8n сохраняет данные и логи каждого успешного выполнения каждого сценария. В высоконагруженных системах таблица execution_entity может вырасти до 50-100 гигабайт за пару месяцев!

Чтобы этого избежать, обязательно добавьте в переменные окружения вашего n8n-main (и воркеров) настройки автоматической очистки базы данных (Data Pruning):

      - EXECUTIONS_DATA_PRUNE=true
      - EXECUTIONS_DATA_MAX_AGE=168      # Хранить логи максимум 7 дней (168 часов)
      - EXECUTIONS_DATA_PRUNE_MAX_COUNT=50000 # Лимит в 50 000 записей
        

Кроме того, в критически важных (но простых) процессах, таких как пинги или базовые редиректы, не забывайте отключать сохранение успешных выполнений прямо в настройках самого Workflow в интерфейсе (Settings -> Save Data on Success = None). Это радикально снизит нагрузку на жесткий диск.

Заключение

Переход от "коробочной" установки n8n к архитектуре с PostgreSQL и Redis через Docker Compose — это квантовый скачок в стабильности вашей автоматизации. Эта конфигурация защищает вас от потерь данных (webhooks drop) на пиках нагрузки, позволяет масштабироваться горизонтально (добавляя новые контейнеры-воркеры) и делает процесс обновления системы безопасным и предсказуемым.

Инвестировав один вечер в грамотную настройку инфраструктуры, вы получите надежный ИИ-движок, который будет стабильно обрабатывать миллионы транзакций год за годом без вашего вмешательства.