Сохранить в мой план Открыть мой план

Queue mode в n8n: Redis, workers, webhooks и масштабирование без хаоса ¶

Обновлено: 2026-05-29

Queue mode нужен не “чтобы n8n был быстрее” сам по себе, а чтобы разделить роли: один процесс обслуживает UI и API, Redis хранит очередь запусков, workers выполняют workflows, а webhook-процессы могут принимать внешние события отдельно. Это полезно, когда один контейнер уже не справляется с параллельными executions или когда падение тяжёлого workflow не должно уносить за собой весь интерфейс.

Архитектура ¶

Browser / API client
        ↓
Main n8n process: UI, API, scheduler, workflow management
        ↓
Redis queue
        ↓
Worker processes: execute workflows
        ↓
PostgreSQL: workflows, credentials metadata, executions

Production webhooks → webhook process или main process → Redis → workers

Все процессы должны использовать один и тот же PostgreSQL, Redis, N8N_ENCRYPTION_KEY и базовые настройки URL. Если worker запущен с другим encryption key, он может не прочитать credentials.

Когда queue mode действительно помогает ¶

Минимальные env-переменные ¶

EXECUTIONS_MODE=queue
QUEUE_BULL_REDIS_HOST=redis
QUEUE_BULL_REDIS_PORT=6379
DB_TYPE=postgresdb
N8N_ENCRYPTION_KEY=long-random-secret

Для Redis с TLS, паролем или cluster-настройками добавляйте соответствующие переменные. Важно не хранить пароль Redis в compose-файле, если репозиторий видят другие люди.

Main, worker и webhook process ¶

Main process должен быть публично доступен только там, где нужен UI/API и тестовые endpoints. Worker не должен торчать наружу: он читает задачи из Redis и работает с PostgreSQL. Webhook process имеет смысл, когда поток production webhooks большой и вы хотите отдельно масштабировать приём внешних HTTP-запросов.

Не ставьте “10 workers на всякий случай”. Если каждый worker одновременно стучится в CRM, Telegram или Google Sheets, вы быстрее упрётесь в rate limits. Начните с 1–2 workers, посмотрите длительность executions, очередь Redis и ошибки внешних API.

Как понять, что очередь застряла ¶

• В UI execution висит слишком долго, а worker в логах молчит.
• Redis жив, но jobs не разбираются.
• Workers постоянно перезапускаются из-за памяти.
• Webhook отвечает, но действие внутри workflow не выполняется.
• После деплоя часть процессов использует старые env.

Проверяйте не только Redis. Часто причина в том, что worker не видит PostgreSQL, не может расшифровать credential или стартовал с другой версией образа n8n.

Порядок запуска ¶

1. Сначала переведите n8n на PostgreSQL и убедитесь, что бэкап восстанавливается.
2. Добавьте Redis в ту же закрытую Docker-сеть.
3. Запустите main n8n с EXECUTIONS_MODE=queue.
4. Запустите один worker и выполните простой manual workflow.
5. Проверьте production webhook.
6. Добавьте второй worker только после логов и метрик.

Что логировать ¶

Типовые ошибки ¶

docker compose ps
docker compose logs --tail=200 n8n
docker compose logs --tail=200 n8n-worker
printenv | grep -E 'N8N_|WEBHOOK_|DB_|QUEUE_'
# перед изменениями: backup базы + проверка N8N_ENCRYPTION_KEY

Связанные материалы ¶

• Redis для queue mode
• Runbook по workers
• Redis Bull stalled jobs
• PostgreSQL для n8n

Официальные источники ¶

• n8n queue mode
• n8n queue mode env vars