n8n Queue Mode: Scaling with Redis and Workers

n8n Queue Mode is an execution mode for self-hosted n8n installations in which a main instance no longer executes workflows itself, but distributes execution jobs to separate worker processes via a Redis queue. The mode is activated with the environment variable EXECUTIONS_MODE=queue on the main and worker instances; as the database, n8n recommends Postgres instead of SQLite. Queue Mode makes sense with high webhook load or many parallel executions; for small setups with few daily runs, it is usually unnecessary infrastructure overhead. As of: July 2026.

How does n8n Queue Mode work technically?

The main instance handles triggers, webhook calls and the interface, but in Queue Mode no longer executes workflows itself; instead it generates an execution ID and places it in a Redis queue. An available worker picks up the job from this queue, loads the workflow details from the database using the execution ID, executes the workflow and writes the result back to the database. Redis reports the completion back to the main instance. Workers are independent Node.js processes that run in parallel to each other and are started individually, for example via the command n8n worker. n8n describes the details of this process in the guide Enable queue mode.

When is Queue Mode really necessary?

Queue Mode is worthwhile as soon as a single n8n instance reaches its limits, for example because very many webhooks arrive at the same time or several workflows need to run in parallel without slowing each other down. In the default configuration without Queue Mode, n8n does not itself limit the number of concurrent production executions, which under high load can cause the event loop to become overloaded and the instance to respond sluggishly. With Queue Mode, you distribute this load across several workers and can simply add more workers as demand grows, instead of scaling a single instance vertically. Queue Mode is also a prerequisite for high availability with multiple main instances, though this multi-main setup is an enterprise feature.

When is Queue Mode overkill for your setup?

For most small and medium-sized businesses with a few dozen automations and a manageable number of executions per day, a single n8n instance without Queue Mode is completely sufficient. Instead of setting up Redis, several worker containers and additional monitoring, impending overload can often already be prevented with the environment variable N8N_CONCURRENCY_PRODUCTION_LIMIT, which limits parallel production executions on a single instance without a separate queue infrastructure being necessary. Every additional component such as Redis or additional worker processes is also an additional part that must be monitored, updated and repaired in case of failure. Anyone who only occasionally processes form data, sends daily reports or synchronizes a CRM gets no noticeable benefit from Queue Mode, but significantly more operational effort.

What do you need to consider technically when setting it up?

For a production Queue Mode operation, n8n says you absolutely need a shared Redis instance as a message broker as well as Postgres as the database; SQLite is not recommended for distributed operation. The encryption key N8N_ENCRYPTION_KEY must be set identically on the main instance and all worker instances, otherwise workers cannot decrypt stored credentials. Each worker processes up to ten jobs in parallel by default, controllable via the --concurrency flag, whereby n8n recommends not setting the value too low, since otherwise, with many workers, the database's connection pool can become exhausted. It is also important that Queue Mode cannot store binary data in the local file system of the respective worker; external storage such as S3 is intended for this. n8n lists the complete list of environment variables under Queue mode environment variables at.

Anyone unsure whether their own n8n setup actually needs Queue Mode or can manage with a single, cleanly configured instance is best advised to have this checked as part of a technical assessment, for example in NordFlux's n8n consulting.

Frequently asked questions about n8n Queue Mode

Do I absolutely need Redis for n8n Queue Mode?

Yes, Redis is a fixed part of the architecture in Queue Mode and manages the queue from which workers pick up their jobs. Without a running Redis instance, the main instance and workers cannot communicate with each other, so Queue Mode cannot be operated without Redis.

Can I use Queue Mode with SQLite as the database?

No, for Queue Mode n8n recommends Postgres from version 13 onward; SQLite is not recommended for this distributed operation. Since several workers access the same database simultaneously for reading and writing, a server database designed for this, such as Postgres, is the more sensible choice.

How many workers should I plan for?

There is no general rule of thumb; each worker processes up to ten jobs simultaneously by default, configurable via the --concurrency flag. Rather than starting with many workers from the outset, it makes more sense to begin with one or two workers and add more specifically as load increases.

What happens to files and attachments in Queue Mode?

Binary data such as uploaded files cannot be stored in Queue Mode in a worker's local file system, because the next processing step may run on a different worker. Instead, external storage such as S3 must be integrated so that all workers can access the same binary data.