Some links in this article are affiliate links. Automated Wealth Lab may earn a commission at no extra cost to you. See our Affiliate Disclosure.
Disclosure: This article contains affiliate links to n8n, DigitalOcean and Hostinger. If you sign up through them, Automated Wealth Lab earns a commission at no extra cost to you. Queue mode itself is a feature of the free self-hosted Community Edition — the links are for the servers (and the Cloud alternative) discussed in the cost section.
A single n8n container is a wonderful thing right up until it isn’t. The editor gets sluggish when a big execution runs. A webhook burst arrives and everything queues behind one long AI workflow. Executions that used to take seconds now wait — not because any single workflow is slow, but because one process is doing four jobs at once: serving the editor UI, listening for triggers, receiving webhooks, and executing every workflow itself.
Queue mode is n8n’s answer: split those jobs across processes. One main instance coordinates, a Redis queue holds incoming executions, and separate worker processes do nothing but execute. Add workers, add throughput. This guide explains when you actually need it (later than most people think), how the pieces fit, the settings and gotchas that decide whether it works, and what it costs compared with letting n8n Cloud scale for you.
How queue mode actually works
Queue mode changes one switch — the EXECUTIONS_MODE=queue environment variable, set identically on every n8n process in the deployment — and rearranges the architecture:
| Process role | Started with | What it does |
|---|---|---|
| Main instance | n8n (default) | Serves the editor and API, activates triggers/schedules, enqueues executions into Redis |
| Worker | n8n worker | Pulls jobs off the queue and executes workflows; this is the role you scale horizontally |
| Webhook processor (optional) | n8n webhook | Receives inbound webhooks and enqueues them, so webhook floods never compete with the editor |
The shared infrastructure every process must agree on:
- Redis — the queue itself, using n8n’s Bull-based queue settings (
QUEUE_BULL_REDIS_HOST, port, password). All instances point at the same Redis. - PostgreSQL (or MySQL) — the shared database. SQLite is not supported in queue mode; a single-container SQLite setup must migrate its database before it can scale out. This is the step that surprises people mid-migration.
- The same
N8N_ENCRYPTION_KEYon every process — workers must decrypt the credentials attached to workflows. A mismatched key is the classic queue-mode failure: the main instance enqueues a job, a worker picks it up, and it fails instantly because the credential can’t be decrypted. Copy the key verbatim, everywhere. - The same n8n version everywhere — main, workers and (in current versions) the external task runners that execute Code nodes should be pinned to the same release.
Worker throughput is tuned with the --concurrency flag (or QUEUE_WORKER_CONCURRENCY) — how many jobs one worker runs simultaneously. The documented default is 10. Two levers, then: more workers (more processes, more runners for CPU-bound work) and more concurrency per worker (more simultaneous jobs, best for I/O-bound workflows that mostly wait on APIs). A reasonable starting point cited in practitioner guides is 2 workers × 10 concurrency = 20 parallel executions, then adjust by watching the queue: workers pinned at full CPU with a growing backlog means add workers; workers idling means you’re paying for headroom you don’t use.
Two more settings worth knowing: N8N_CONCURRENCY_PRODUCTION_LIMIT caps how many production (trigger/webhook) executions run in parallel — excess executions queue FIFO — and works in both regular and queue mode; and OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS=true sends even manual editor runs to the workers, keeping the main instance responsive.
The signals that one container has stopped being enough
Queue mode is not a badge of seriousness; it’s a remedy for specific symptoms. You need it when you see several of these:
- The editor freezes or lags during heavy executions — execution is competing with the UI on one process.
- Webhook response times spike under bursts — a flood of inbound events queues behind long-running workflows.
- Executions wait in line — trigger volume exceeds what one process drains, and the backlog grows at peak times rather than shrinking between them.
- One heavy workflow blocks everything else — a 10-minute AI pipeline delays a 5-second notification flow.
- You’re approaching Cloud’s concurrency/run-time ceilings in self-hosted form — long or massively parallel workloads are simply the wrong shape for a single process.
Conversely, if your instance runs a few dozen workflows on schedules and webhooks at human scale — the typical solo-founder setup — a single container on a decent VPS is still the right answer, and queue mode is complexity purchased before its time. Practitioner guidance converges on the same threshold thinking: consistently high execution volume (on the order of a thousand executions an hour), visible queueing, or a genuine high-availability requirement. Below that, buy RAM, not architecture.
The cost of scaling: self-hosted queue mode vs. n8n Cloud
Self-hosted queue mode runs on the free Community Edition; what you pay for is servers. A realistic small queue-mode footprint: one VPS for main + Redis + Postgres, one for workers — or a single larger VPS running everything as containers, which is how most small deployments start.
| Setup | Monthly cost | What you get |
|---|---|---|
| Single container, Hostinger KVM 2 (2 vCPU, 8 GB) | $8.99 promotional / $14.99 renewal | The pre-queue-mode baseline |
| Queue mode on one bigger box, Hostinger KVM 4 (4 vCPU, 16 GB) | $12.99 promotional / $28.99 renewal | Main + Redis + Postgres + 2 workers, one machine |
| Queue mode split across DigitalOcean Droplets (main $24 + worker $24) | $48 | 4 GB / 2 vCPU per box, per-second billing, workers addable at $24 each |
| n8n Cloud Pro | $50 billed annually | 10,000 executions/mo, up to ~20–50 concurrent, zero servers to run |
Read that table honestly in both directions. At small scale, one $13–$29 VPS running the whole queue-mode stack undercuts Cloud Pro — this is the same math as our real cost of self-hosting n8n breakdown and the hosting comparison. But the self-hosted column omits your operations time: Redis and Postgres are now production services you patch, back up and resurrect. And Cloud’s execution meter cuts the other way at volume — our n8n vs Make vs Zapier cost comparison shows how quickly high-frequency workflows eat a 10,000-execution plan, which is precisely where self-hosted queue mode earns its keep: executions stop being a metered currency and become a capacity question you answer with one more $24 worker.
There’s also a licensing nuance worth stating plainly: queue mode and workers are available in the free Community Edition for your own use under n8n’s fair-code Sustainable Use License — the paid self-hosted tiers (Business, from ~€667/month billed annually) buy governance features like SSO, Git sync and shared projects, not the right to scale. We unpack that license in n8n’s fair-code license, explained.
A sane scaling path
- Start single-container on a VPS sized with headroom, with production error handling in place — scaling a setup that fails silently just fails at higher throughput.
- Measure before you migrate: execution volume per hour at peak, how long executions wait, whether the editor actually suffers.
- Migrate the database first if you’re on SQLite — Postgres is a queue-mode prerequisite, and it’s the riskiest step; do it as its own change, not bundled with the queue-mode switch.
- Turn on queue mode with 2 workers × 10 concurrency, same encryption key and version everywhere, and watch the queue for a week before tuning.
- Add webhook processors only when webhook traffic is the bottleneck — they’re an optimization for a specific symptom, not a default.
FAQ
What is n8n queue mode?
Queue mode is n8n’s scaling architecture for self-hosted instances. The main instance stops executing workflows itself and instead enqueues executions in Redis; separate worker processes pull jobs from the queue and run them. You scale by adding workers (and optionally dedicated webhook processors).
Do I need Redis and Postgres for queue mode?
Yes to both, in practice. Redis is the queue broker every instance must share, and queue-mode deployments require a shared PostgreSQL (or MySQL) database — SQLite is not supported for queue mode, so a single-container SQLite setup must migrate its database first.
Is queue mode free, or a paid n8n feature?
It’s available in the free self-hosted Community Edition under n8n’s fair-code license. Paid self-hosted tiers add governance features (SSO, Git, environments, shared projects), not the ability to run workers.
How many workers should I start with?
A common, sane starting point is 2 workers at the default concurrency of 10 (20 parallel executions). Then watch the actual signals: workers saturated with a growing queue means add workers; idle workers mean scale back. CPU-bound workflows (heavy Code nodes) scale with worker count; I/O-bound workflows scale with concurrency.
What’s the most common queue mode setup mistake?
Mismatched configuration across processes — above all the N8N_ENCRYPTION_KEY. If a worker’s key differs from the main instance’s, it cannot decrypt workflow credentials and every job it picks up fails. All instances also need the same EXECUTIONS_MODE, the same Redis, and the same n8n version.
When is n8n Cloud the better answer than queue mode?
When your execution volume fits comfortably in a Cloud plan and you’d rather not operate Redis and Postgres. Queue mode wins when volume makes Cloud’s per-execution meter expensive, when you need concurrency/run-time headroom beyond plan limits, or when the workflows must run on your own infrastructure anyway.
Methodology
What we did: Documented queue mode’s architecture (main / worker / webhook-processor roles), its prerequisites (Redis, PostgreSQL/MySQL — no SQLite), core configuration (EXECUTIONS_MODE=queue, Bull Redis settings, worker concurrency default of 10, production concurrency limit) and failure modes from n8n’s documented behavior as described in current setup guides and practitioner documentation, and priced three deployment shapes against October 2026 published rates for Hostinger, DigitalOcean and n8n Cloud.
What we did NOT do: We did not deploy a queue-mode cluster, load-test worker scaling, or measure throughput. Claims about relative scaling behavior (e.g., CPU-bound work scaling with worker count because each worker has its own task runner) reflect documented architecture and practitioner reports, not our benchmarks. Hosting prices are list/promotional figures with renewal rates stated where the vendor publishes them.
Conflict disclosure: n8n, DigitalOcean and Hostinger are affiliate partners. The article’s recommendation logic — stay single-container until symptoms say otherwise — argues against buying the bigger servers two of those partners sell, which is the honest math for most readers.
AWL verdict
Queue mode is the right answer to a specific problem — executions waiting on each other because one process does everything — and unnecessary complexity before that problem exists. When the symptoms show up, the migration is well-trodden: Postgres first, Redis as the queue, the same encryption key and version on every process, two workers to start. Scale by watching the queue, not by vibes — and keep Cloud in the comparison, because at moderate volume, paying n8n $50 to be your ops team is still the cheapest worker you’ll ever hire.
Sources
- Queue mode configuration — EXECUTIONS_MODE, Redis settings, worker concurrency defaults and production concurrency limits: https://gist.github.com/Ryan-PG/879ff8acaea8d70af265b9685a5d6d67 (verified October 2026)
- Queue mode architecture — process roles, shared Redis/Postgres, encryption-key failure mode: https://www.aiworkshack.com/tools/n8n/n8n-in-production-scaling-with-queue-mode-workers-and-concurrency.html (verified October 2026)
- Worker/task-runner scaling behavior and a worked queue-mode Docker Compose setup: https://www.rakibulinux.com/blogs/n8n-queue-mode-redis-workers (verified October 2026)
- Scaling levers — worker replicas vs. QUEUE_WORKER_CONCURRENCY, multi-VPS workers, sizing rules of thumb: https://www.triggerworkflow.com/2026/08/n8n-queue-mode-redis-workers-docker-setup.html (verified October 2026)
- n8n Cloud pricing (Starter $20/mo, Pro $50/mo billed annually; 2,500 / 10,000 executions; concurrency limits): https://www.stackscout.net/articles/cc_20261014_180524.html (figures checked on n8n.io/pricing, October 15, 2026)
- DigitalOcean Droplet pricing (Basic 4 GB / 2 vCPU, $24/month): https://www.digitalocean.com/pricing/droplets (verified October 2026)
- Hostinger VPS pricing (KVM 2: $8.99 promo / $14.99 renewal; KVM 4: $12.99 promo / $28.99 renewal): https://gizmodo.com/best-web-hosting/hostinger (verified October 2026)
