n8n queue mode vs regular mode is a choice about where a workflow actually runs, not just how fast it runs. Regular mode, the documented default (EXECUTIONS_MODE=regular), is one process doing four jobs at once: serving the editor, running the API, listening for webhooks, and executing every workflow, with no limit on how many production executions run at the same time unless someone sets one. Queue mode restructures that into a main instance that only receives triggers, a Redis queue that holds the resulting execution IDs in transit, and separate worker processes that do the actual running. The part that catches teams out is not which mode is faster, it is what queue mode does not automatically hand off the moment it’s switched on: a single instance still owns timers, pollers, and every persistent connection, no matter how many workers are running underneath it.
n8n Queue Mode vs Regular Mode: What Actually Changes
Per n8n’s own documentation on scaling, the two options are stated as a single setting with two values: “n8n can run in different modes depending on your needs. The queue mode provides the best scalability.” That setting is EXECUTIONS_MODE, and n8n’s own executions environment variable reference confirms both the values and which one ships as standard: an “Enum string: regular, queue“, defaulting to regular, described plainly as “whether executions should run directly or using queue.” Nothing about queue mode is on unless that variable is deliberately changed.
The difference is not a performance tweak inside the same process, it is a different number of processes doing different jobs. Regular mode keeps the editor, the API, the webhook listener, and the workflow executor together in one Node.js process. Queue mode splits that single process into a main instance that receives the trigger and generates the execution, a Redis queue that holds the execution in transit, and one or more separate worker processes that pick it up and run it. Everything that follows in this article, concurrency, infrastructure, and the tasks that stay put no matter how many workers exist, follows from that one structural change.
How Regular Mode Runs Everything in One Process
Regular mode is the shape every self-hosted n8n instance starts in, and for a low volume of workflows it is also the simplest one to operate: a single process, a single deployment, nothing extra to run alongside it. The trade-off is that the same process handling a person editing a workflow in the browser is also the process running every production execution triggered by a webhook or a schedule. n8n’s own documentation on controlling concurrency states the risk directly: “In regular mode, n8n doesn’t limit how many production executions may run at the same time. This can lead to a scenario where too many concurrent executions thrash the event loop, causing performance degradation and unresponsiveness.” A burst of webhook traffic doesn’t just slow down the workflows it triggers, it can slow down the editor for whoever happens to be using it at the same moment, because both are competing for the same event loop.
The documented fix inside regular mode itself, before reaching for queue mode at all, is a single environment variable: N8N_CONCURRENCY_PRODUCTION_LIMIT, off by default, which queues any production execution over the configured limit and processes the backlog in FIFO order once capacity frees up. It’s a narrower fix than it first sounds. The same documentation is specific about its scope: “Concurrency control applies only to production executions: those started from a webhook or trigger node. It doesn’t apply to any other kinds, such as manual executions, sub-workflow executions, error executions, or started from CLI.” A workflow triggered manually from the editor, or called as a sub-workflow from another workflow, ignores the limit entirely and runs regardless of how full the production queue is.
How Queue Mode Splits the Work
Queue mode’s own documentation lays out the process flow in six explicit steps, and it is worth reading in full because each step names exactly which process does what: “The main n8n instance handles timers and webhook calls, generating (but not running) a workflow execution. It passes the execution ID to a message broker, Redis, which maintains the queue of pending executions and allows the next available worker to pick them up. A worker in the pool picks up message from Redis. The worker uses the execution ID to get workflow information from the database. After completing the workflow execution, the worker: writes the results to the database, posts to Redis, saying that the execution has finished. Redis notifies the main instance.” The main instance never runs the workflow itself in this flow; it only ever generates the execution and waits to be told it finished.
Turning this on needs real infrastructure, not just a flag. Per n8n’s own guide to enabling queue mode, the instructions are explicit that the setting has to be applied everywhere, not just once: “Set the environment variable EXECUTIONS_MODE to queue on the main instance and any workers.” Encryption has to match across every process too, since a worker that can’t decrypt a credential can’t run the node that needs it: “The encryption key of the main n8n instance must be shared with all worker and webhooks processor nodes to ensure these worker nodes are able to access credentials stored in the database.” And the database underneath the whole setup matters: “Running n8n with execution mode set to queue with an SQLite database isn’t recommended,” since a distributed system built from a main instance and one or more separate workers all reading and writing the same execution state doesn’t suit a single-file database designed for one process. Each worker is also, structurally, a full n8n instance in its own right: the documentation notes each one is “its own Node.js instance, running in main mode, but able to handle multiple simultaneous workflow executions due to their high IOPS.”
| Aspect | Regular mode | Queue mode |
|---|---|---|
| Default setting | Yes, EXECUTIONS_MODE=regular | No, must be explicitly enabled on every process |
| Who executes a workflow | The same single process handling the UI and API | A separate worker process, coordinated through Redis |
| Infrastructure required | None beyond the n8n process itself | Redis, one or more worker processes, a non-SQLite database |
| Concurrency control | Unlimited by default; N8N_CONCURRENCY_PRODUCTION_LIMIT to cap it | --concurrency flag per worker (default 10), overridden by N8N_CONCURRENCY_PRODUCTION_LIMIT if set |
| Editor UI under heavy load | Competes with executions for the same event loop | Isolated, since executions run on separate worker processes |
| Timers, pollers, persistent connections | Run in the same single process | Still run only on the main instance (or the leader, in multi-main) |
The Delegation Trap: What Queue Mode Does Not Hand Off to Workers
The assumption that trips teams up is that queue mode redistributes everything a workflow might do. It doesn’t. n8n’s own documentation on multi-main setup splits a single main process’s responsibilities into two categories, and only one of them is ever shared out: “regular tasks, such as running the API, serving the UI, and listening for webhooks, and at-most-once tasks, such as running non-HTTP triggers (timers, pollers, and persistent connections like RabbitMQ and IMAP), and pruning executions and binary data.” Workers are built to run executions the main instance has already generated; they were never built to originate a scheduled trigger or hold open a polling connection themselves. A Schedule Trigger node, a Gmail Trigger running in poll mode, or a persistent RabbitMQ listener all still depend on one process staying up and watching for them, regardless of how many workers are added underneath it.
Running more than one main process changes who holds that responsibility, but not how many processes hold it. Per the same documentation, in a multi-main setup, an Enterprise self-hosted feature, “there are two kinds of main processes: followers, which run regular tasks, and the leader, which runs both regular and at-most-once tasks.” Adding a second or third main instance for high availability adds more capacity for API and webhook handling; it does not create a second source of scheduled triggers. If the leader goes down, another main takes over leadership and, with it, the timers and pollers, but at any given moment exactly one process owns them.
Where Teams Get This Wrong
The first common mistake is starting a worker process without setting EXECUTIONS_MODE=queue on it, or without giving it the same N8N_ENCRYPTION_KEY as the main instance. n8n’s own documentation is explicit that the executions variable belongs “on the main instance and any workers,” not just the main one, and that the encryption key “must be shared with all worker and webhooks processor nodes.” A worker missing either setting either won’t behave as a worker at all, or will be unable to decrypt the credentials a workflow needs to run, and the failure surfaces as broken executions rather than an obvious configuration error naming the mismatch.
The second common mistake is adding the main process to the load balancer pool that routes webhook traffic, on the assumption that more entry points is simply more capacity. n8n’s documentation on scaling recommends the opposite directly: “n8n doesn’t recommend adding the main process to the load balancer pool. If you add the main process to the pool, it will receive requests and possibly a heavy load. This will result in degraded performance for editing, viewing, and interacting with the n8n UI.” The documented alternative is dedicated webhook processor instances, and, if needed, setting N8N_DISABLE_PRODUCTION_MAIN_PROCESS=true so the main process stops handling production webhooks entirely and leaves that job to the processors.
The third common mistake is treating N8N_CONCURRENCY_PRODUCTION_LIMIT as a regular-mode-only setting, and leaving it configured from an earlier regular-mode deployment after switching to queue mode. n8n’s own documentation on concurrency control states plainly that this is not how it works: “the environment variable N8N_CONCURRENCY_PRODUCTION_LIMIT controls both of them. In queue mode, n8n takes the limit from this variable if set to a value other than -1, falling back to the --concurrency flag or its default.” A limit left over from regular mode silently overrides the per-worker --concurrency flag in queue mode too, capping throughput well below what the worker fleet was actually provisioned for.
The fourth common mistake is assuming that adding more workers spreads scheduled and polling triggers across the fleet the same way it spreads webhook executions. It doesn’t: a Schedule Trigger node, a poll-mode trigger, or a persistent connection still depends on the main instance, or the leader in a multi-main setup, staying up and watching for it, exactly as documented for at-most-once tasks. Ten workers add execution capacity; they add nothing to how many processes can originate a timer.
Related Reading
For the wider architecture and infrastructure decisions a queue mode rollout sits inside, see n8n Consultancy. For the CRM side these workflows most often connect to, see HubSpot Consultancy. For the broader integration pattern most of these builds are based on, see HubSpot n8n Integration Guide.
Go deeper: Advanced n8n Error Handling Strategies for Resilient SaaS Workflows · n8n vs Zapier RevOps Automation · Scalable n8n Automation for RevOps: High Volume Workflow Optimisation
Frequently Asked Questions
Is queue mode always better than regular mode?
Not necessarily. Regular mode is the documented default and is simpler to operate for a low volume of workflows: one process, nothing extra to run. Queue mode adds real infrastructure, Redis, workers, and a non-SQLite database, so it’s worth adopting when concurrent production load is genuinely thrashing the event loop, not by default.
Do I need to set EXECUTIONS_MODE on every worker, or just the main instance?
Every worker. n8n’s own documentation on enabling queue mode instructs setting EXECUTIONS_MODE to queue “on the main instance and any workers.” A worker left on its default regular setting will not correctly join the queue as a worker process, regardless of what the main instance is configured to do.
Does queue mode move timers and scheduled triggers onto the workers?
No. n8n’s own documentation on multi-main setup describes timers, pollers, and persistent connections as “at-most-once tasks” that stay with the main instance, or the leader if there is more than one main. Workers only ever execute workflows the main instance has already generated and queued; they never originate a scheduled trigger themselves.
Can I run n8n queue mode with SQLite?
n8n’s own documentation advises against it directly: “Running n8n with execution mode set to queue with an SQLite database isn’t recommended.” Queue mode is a distributed system, with a main instance and one or more workers all reading and writing execution state, which doesn’t suit a single-file database built around one process accessing it.
Why does my worker fail to decrypt credentials in queue mode?
Almost always a mismatched encryption key. n8n’s own documentation states the main instance’s encryption key “must be shared with all worker and webhooks processor nodes to ensure these worker nodes are able to access credentials stored in the database.” A worker started with a different or auto-generated N8N_ENCRYPTION_KEY can pick up jobs but cannot decrypt the credentials those jobs need.
Does N8N_CONCURRENCY_PRODUCTION_LIMIT do anything in queue mode?
Yes, and it can override worker settings unexpectedly. n8n’s own documentation confirms this one variable “controls both” regular and queue mode concurrency: in queue mode, if it’s set to a value other than -1, n8n uses it instead of each worker’s --concurrency flag, which can cap throughput below what the workers were provisioned for.