n8n queue mode with Redis: scaling your AI workflows

A pack that runs flawlessly in testing — ten emails triaged, fifty PDF pages ingested — can behave very differently the day a client imports 3,000 emails at once, or a whole team queries the RAG chatbot at the same time. On a standard self-hosted n8n instance, the editor, the API, and workflow execution all share the same process: a load spike can slow down the interface while executions pile up. Queue mode, which splits the work between a main instance and workers via Redis, solves exactly this problem — provided you know when and how to turn it on.

What n8n does by default, and where it strains

In the standard configuration (EXECUTIONS_MODE=regular, the default), a single n8n instance does everything: it serves the UI, receives webhooks, fires crons, and executes every workflow. That works great up to a point, but has two concrete limits for AI workflows:

• CPU contention: a Code node processing a large batch, or several AI executions running in parallel (see our article on 429 errors and pacing AI calls), compete for the same resources as the interface. The result: the editor gets sluggish exactly when you'd want to watch an execution closely.
• Single point of failure: if the n8n process crashes or restarts, every in-flight execution is lost, including webhooks that were waiting for a response.

For most freelancers and small teams, this isn't a problem: the FlowKit packs run just fine in standard mode. Queue mode becomes relevant once real volume exceeds what a single instance comfortably handles — typically a large document ingestion job (see our Supabase pgvector RAG guide) or a high-traffic shared inbox used by several teams.

The queue mode architecture

Switching EXECUTIONS_MODE to queue fundamentally changes how work is distributed:

1. The main instance keeps serving the editor and API, receives webhooks, and fires crons — but instead of executing the workflow itself, it drops a job into a Redis queue.
2. Redis stores pending jobs. It's the only new piece of infrastructure compared to a standard instance (which is already connected to PostgreSQL).
3. One or more workers — n8n processes launched with the n8n worker command — watch Redis, pick up available jobs, and actually run the workflows, each reading the data it needs from the same shared PostgreSQL database.

This decoupling changes everything under load: the main instance stays responsive (it now only stacks jobs, a lightweight operation), and execution throughput scales directly with the number of active workers — you scale by adding processes, not by upgrading to a bigger server.

Step-by-step configuration

The key environment variables to set on the main instance and on every worker:

EXECUTIONS_MODE=queue
QUEUE_BULL_REDIS_HOST=redis
QUEUE_BULL_REDIS_PORT=6379
# Optional, depending on your Redis deployment:
# QUEUE_BULL_REDIS_PASSWORD=...
# QUEUE_BULL_REDIS_DB=0

On a typical Docker Compose setup, that means a redis service (the official redis:7-alpine image is enough for most cases, no special config needed), an n8n service for the main instance, and an n8n-worker service running the same image with the n8n worker --concurrency=10 command — the --concurrency flag sets how many executions a single worker handles in parallel. Two independent levers to add capacity:

• Scale horizontally: docker compose up --scale n8n-worker=3 launches three worker processes sharing the same Redis queue, with no extra configuration.
• Raise concurrency: bump --concurrency on an existing worker, as long as the server's CPU and memory can keep up.

For high webhook volume (beyond 10,000 executions per day), n8n also lets you run a process dedicated solely to receiving webhooks (n8n webhook), so the main instance can focus on the UI and cron scheduling.

What stays the same — and what to check before switching

Queue mode doesn't change workflow logic, credentials, or data structure: an imported pack keeps working identically once switched over. Two things are worth checking before going to production, though:

• Error Workflows remain essential: with several workers, an execution that fails permanently still needs to be caught by a dedicated Error Workflow rather than disappearing silently into one worker's logs among several.
• Credentials and environment variables must be identical on the main instance and on every worker — a worker that starts without the right OpenAI or Anthropic key will fail on any execution it picks up, in a way that's hard to diagnose if only one worker out of three is misconfigured.

If your workflows already split logic into sub-workflows, queue mode integrates without changes: each sub-workflow call remains a normal execution, simply dispatched to whichever worker is available.

Redis: the one real new dependency to monitor

Under queue mode, Redis becomes as critical as PostgreSQL: if it goes down, the main instance can no longer dispatch new jobs, even if the workers themselves are running fine. For a production self-hosted instance, that calls for the same precautions as your database:

• A managed Redis instance (most cloud hosts offer one) rather than an isolated container with no backup, to avoid an unmonitored single point of failure.
• Basic monitoring (alert if Redis stops responding) — this connects directly to the reflexes covered in our self-hosted vs cloud guide: self-hosting gives you control, provided you accept the operational responsibility that comes with it.

Jobs stored in Redis are ephemeral (the execution ID and its status, not the business data itself, which stays in PostgreSQL): losing Redis doesn't corrupt the history of already-completed executions, but it does interrupt the flow of new ones.

When NOT to switch to queue mode

Queue mode adds an infrastructure component (Redis) and operational complexity (several processes to monitor instead of one). It isn't worth it:

• below roughly 1,000 executions per day, where a standard instance absorbs the volume without effort;
• if you're on n8n Cloud, where scaling is handled by n8n without any action on your part;
• during testing or the initial setup of a pack — better to validate the workflow in standard mode first, then switch once you know the real production volume.

Going further

Queue mode is an infrastructure layer, not a replacement for pacing AI calls: combined with Loop Over Items and rate-limit handling, it lets you absorb a genuine volume spike without ever exceeding OpenAI or Anthropic quotas. The workflows in the RAG Assistant Pack (€119) and the Inbox AI Pack (€79) are built to run equally well in standard or queue mode, unchanged: it's a hosting infrastructure choice, not a constraint imposed by the workflows themselves.