1. What is n8n queue mode and why do you need it for production?

In default mode, every workflow execution runs inside the main n8n process. This works for testing and low volumes, but when you exceed ~50 executions per day or need high concurrency, the main process becomes a bottleneck. Queue mode solves this by introducing a Redis queue between the trigger layer and the execution layer.

Without queue mode, you cannot scale beyond a single machine. Queue mode is the foundation for production n8n deployments handling thousands of executions per day. For a detailed comparison of scaling strategies, see the official queue mode overview.

2. What are the mandatory prerequisites for n8n queue mode?

Redis handles job queues, dead-letter queues, and worker heartbeats. PostgreSQL replaces SQLite because it supports concurrent writes, transaction locking, and multi‑worker coordination. Attempting to enable queue mode with SQLite results in runtime errors.

Minimum versions: Redis 6.0 (or later, including Redis 7.x), PostgreSQL 12 or higher. For production, use managed services (AWS ElastiCache, Google Cloud Memorystore, or a dedicated Redis container with persistence). The following Docker Compose snippet shows the required services:

services:
  redis:
    image: redis:7-alpine
    command: redis-server --appendonly yes
  postgres:
    image: postgres:15
    environment:
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: securepass
      POSTGRES_DB: n8n

Refer to the queue mode prerequisites for detailed setup.

3. How do you enable queue mode in a Docker Compose environment?

Below is a minimal production Docker Compose file with one main instance and two workers:

version: '3.8'
services:
  n8n-main:
    image: n8nio/n8n:1.78.1
    environment:
      - QUEUE_MODE_ENABLED=true
      - QUEUE_BULL_REDIS_HOST=redis
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=securepass
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - N8N_HOST=n8n.yourdomain.com
      - N8N_PROTOCOL=https
    ports:
      - "5678:5678"
  n8n-worker-1:
    image: n8nio/n8n:1.78.1
    environment:
      - QUEUE_MODE_ENABLED=true
      - QUEUE_BULL_REDIS_HOST=redis
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=securepass
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - EXECUTIONS_PROCESS=worker
  n8n-worker-2:
    ... same as worker-1

The main instance exposes the editor and webhooks. Workers do not need published ports. Scale workers by adding more containers. Use a load balancer in front of the main instances if you need high availability for the editor itself.

4. How do you control concurrency per worker with N8N_CONCURRENCY_PRODUCTION_LIMIT?

When a worker pulls a job from Redis, it starts executing it. If the worker has spare concurrency slots, it immediately pulls additional jobs. Without a limit, a worker may overload itself if workflows are CPU‑intensive. Start with a limit of 5 and adjust based on metrics.

Set this variable on the worker containers only (it is ignored on the main instance). For bursty traffic, a higher limit can reduce queue waiting time. For memory‑intensive workflows (e.g., large file processing), keep the limit low (e.g., 1 or 2). The environment variables reference provides further details.

5. How do you scale n8n workers horizontally in production?

Workers are stateless: they read the workflow definition from the database, execute it, and write results back. They do not store any persistent data locally. Therefore, you can add or remove workers at any time without disrupting ongoing executions (in‑flight jobs finish on the original worker).

To monitor scaling needs, observe the Redis queue length using redis-cli LLEN bull:queue:wait. If the queue grows consistently, add workers. Reduce workers when the queue stays empty. For Kubernetes, use the official Helm charts that support Horizontal Pod Autoscaling based on custom metrics.

6. What are n8n task runners and why are they important in queue mode?

Before task runners, Code node code ran inside the main worker thread. Malformed code could crash the worker. Task runners spawn a dedicated process for each Code node execution (or a pool of processes). The worker communicates with the task runner via gRPC. If a Code node crashes, only that task runner restarts; the worker continues processing other workflows.

Key task runner variables:

• N8N_RUNNERS_ENABLED=true (default in queue mode).
• N8N_RUNNERS_MAX_CONCURRENCY — max concurrent Code node executions per worker (default 5).
• N8N_RUNNERS_TASK_BROKER_URI — internal URI for task broker.

More details are available in the task runners documentation.

7. How do you monitor queue mode performance and worker health?

The Prometheus endpoint includes metrics for queue mode:

• n8n_queue_jobs_waiting — number of workflows waiting in Redis queue.
• n8n_queue_jobs_active — workflows currently being executed by workers.
• n8n_workers_count — number of connected workers.
• n8n_workflow_execution_total and n8n_workflow_execution_failed_total — success/failure counts.

Example Prometheus alert rule: if n8n_queue_jobs_waiting > 100 for 5 minutes → scale up workers. Also monitor Redis eviction and memory fragmentation.

For full metrics reference, see the metrics documentation.

8. What are common queue mode failures and how to fix them?

Below is a troubleshooting table:

Always run docker logs <main_or_worker_container> to see detailed error messages. For persistent issues, refer to the n8n community forum or the GitHub issues.