n8n Queue Mode: Production Scaling Guide

A self-hosted n8n instance runs perfectly well for a long time in its default configuration, right up until it doesn't. Once you are running enough workflows, or a few of them are heavy enough, the single n8n process that handles the editor, the webhooks, and the actual workflow execution all at once becomes the bottleneck. Queue mode is how you fix that without switching platforms.

I set this up for clients once their execution volume or workflow complexity crosses a point where a single process starts visibly struggling, either as slow webhook responses or executions queuing up behind each other for no good reason. This post covers what queue mode actually changes, why Redis is part of the picture, how workers fit in, and when it is genuinely worth the added infrastructure.

What Is n8n Queue Mode?

By default, n8n runs as a single process doing everything: serving the editor UI, receiving webhook calls, and running every workflow execution, one after another on the same process. Queue mode splits that single process into separate roles. A main process still handles the UI and receives webhook calls, but instead of running the workflow itself, it hands the job off to a queue. Separate worker processes pull jobs from that queue and actually execute them.

The practical effect: your main process stays responsive to incoming webhooks even while heavy workflows are running, because it is no longer the thing doing the heavy lifting. You can add more workers to handle more concurrent executions without touching the main process at all.

Main Mode vs Queue Mode

In main mode, one process does everything. It is simpler to set up, easier to reason about, and completely fine for low to moderate volume. There is no separate infrastructure to manage.

In queue mode, you have at minimum a main process, one or more worker processes, and Redis sitting between them as the message broker. It is more moving parts, but it decouples "receiving the trigger" from "running the workflow," which is exactly what you need once a single process can no longer keep up with both jobs at once.

The general guidance I use with clients: if you are comfortably under a few thousand executions a day and nothing individual is particularly heavy, main mode with a Postgres database is enough. Once you are consistently running high volume, or a handful of workflows are slow enough to visibly delay everything else, queue mode earns its complexity.

Why Redis Is Used

Redis acts as the job queue itself. When the main process receives a trigger, it generates the execution but does not run it. Instead it pushes the execution onto the Redis queue. Workers watch that queue and pick up jobs as they become free. Redis needs to be reachable by both the main process and every worker, and running this setup on SQLite instead of a proper database like Postgres is not supported once you are distributing work across multiple processes this way.

n8n Workers

Each worker is its own Node.js instance, technically running in main mode itself, but its only job is pulling and executing jobs from the Redis queue rather than serving the UI or handling webhooks. Because a worker can handle multiple simultaneous executions due to how Node.js manages I/O-bound work, a handful of workers can absorb a meaningful amount of concurrent load.

You can view running workers and basic performance metrics directly in n8n's settings once queue mode is active, which is the quickest way to tell whether you actually need more of them or whether the bottleneck is somewhere else entirely, like a slow external API a workflow depends on.

Scaling Workflow Executions

Scaling in queue mode is mostly a matter of adding worker instances. More workers means more executions can run concurrently without any of them blocking the main process. What queue mode does not automatically fix is a single workflow that is inherently slow, like one making dozens of sequential API calls. Adding workers gives you more parallel capacity across different executions, it does not make one execution finish faster.

A detail worth knowing if you use webhooks heavily: in queue mode, the HTTP request for a webhook is still received by the main or a dedicated webhook process, but the actual execution work is handed to a worker. That handoff adds a small amount of overhead and latency compared to main mode, which is a fair trade for the concurrency you gain, but it is worth knowing about if you are chasing sub-second webhook response times.

Database Architecture

Queue mode requires a proper database, not SQLite, since multiple processes need consistent, concurrent access to the same execution and workflow data. Postgres is the standard choice for this. n8n Self-Hosted Setup Guide covers getting a self-hosted instance running with Postgres from the start, which makes moving to queue mode later a much smaller step than migrating off SQLite at the same time you are also adding workers.

Docker Deployment

The typical production layout is a main container, one or more worker containers, a Postgres container, and a Redis container, usually via Docker Compose. The encryption key used to read stored credentials has to be identical across the main process and every worker, since a mismatch there means workers simply cannot decrypt credentials they need to run a workflow. This is the single most common misconfiguration I see when someone first stands up queue mode: workers up and connected to Redis, executions picked up, and then failing immediately because the encryption key does not match what the main process used.

Monitoring Workers

Beyond n8n's own worker view, watching Redis directly with basic commands to check memory and queue depth tells you quickly whether workers are keeping pace or whether jobs are piling up. If the queue depth keeps climbing rather than draining, that is your signal to add workers rather than waiting for it to resolve on its own, the same symptom as a backed-up webhook queue in Make.com Webhook Queue Explained, just on a different platform.

When Queue Mode Is Worth It

Queue mode is infrastructure you take on deliberately, not a default you should reach for on a small instance running a handful of light workflows. It earns its place once you have real concurrent load, workflows heavy enough to bottleneck a single process, or webhook traffic that needs the main process to stay responsive no matter what else is running. Below that threshold, main mode with Postgres is simpler to operate and just as reliable.

If you are deciding between n8n and Make.com for a new build rather than scaling an existing n8n instance, n8n vs Make.com covers the cost and architecture trade-offs between the two, and How to Build an n8n Workflow is the place to start if you have not built production n8n workflows before.

Setting up queue mode correctly the first time, with the right database, encryption key handling, and worker count for your actual load, is exactly the kind of infrastructure work I take on for clients. If your self-hosted n8n instance is starting to strain under load, book a free 30-minute call and bring your current execution volume, and we can work out whether queue mode is the right move and set it up properly.

Frequently Asked Questions

What is queue mode in n8n?

It splits the single default n8n process into a main process that handles the UI and webhooks, and separate worker processes that actually execute workflows, coordinated through a Redis queue. This lets you scale execution capacity by adding workers.

When should I use n8n queue mode?

Once a single n8n process is visibly struggling to keep up with your execution volume, or heavy workflows are delaying webhook responsiveness. For low to moderate volume, main mode is simpler and sufficient.

Does n8n queue mode require Redis?

Yes. Redis acts as the message broker between the main process and workers. Both need to be able to reach it, and it is a required piece of the architecture, not optional.

How many n8n workers do I need?

There is no fixed number. Start with one or two, watch queue depth in Redis and the workers view in n8n, and add more if jobs are piling up faster than they drain. It depends heavily on how heavy your individual workflows are.

Can queue mode make n8n faster?

It increases concurrent execution capacity, not the speed of any single workflow. If one workflow is slow because of sequential API calls, adding workers does not fix that specific workflow, it only lets more workflows run at once without blocking each other.

Is n8n queue mode available for self-hosted deployments?

Yes, it is a self-hosted feature and the standard way to scale a self-hosted instance. Cloud-hosted n8n handles scaling differently on n8n's own infrastructure.

What is the most common mistake when setting up queue mode?

A mismatched encryption key between the main process and worker processes, which causes workers to pick up jobs but fail immediately because they cannot decrypt the credentials the workflow needs.

If you would rather have this built than build it, I take on n8n and self-hosted automation infrastructure work through Upwork.