# n8n Multi Main Setup: Queue Mode and Failover
By Gustavo Peixoto · 2026-10-26 · Source: https://www.activepieces.com/blog/n8n-multi-main-setup-queue-mode-and-failover
---
Multi main means running several main n8n instances side by side in queue mode, so that losing one main doesn't take away your entry point.
That's how the n8n docs describe it, and it's a different thing from adding workers, which is the part people tend to mix up, whether they're comparing it with [Activepieces](https://www.activepieces.com) or any other automation tool that splits its work across processes.
## n8n multi main definition and failure prevention
### 02:14: the main instance goes down while workers are fine
The pager text reads `ECONNREFUSED` on the webhook URL, and nothing else.
At 02:14 a team's only main instance crashes. Redis is up. Postgres is up. Every worker reports healthy, and each one is still connected to the queue and waiting for jobs.
### Why healthy workers did not keep the workflows running
Workers execute jobs, **but they don't create them**. In queue mode the main instance is what receives webhooks, fires schedule and polling triggers, and puts executions onto the Redis queue. When it dies, the **queue simply stops receiving work**.
In that state, incoming webhook calls from outside systems get refused. Cron-style triggers never fire, so scheduled jobs don't run late; they don't run at all. The workers aren't broken; they are idle, which is worse, because no alert is tied to idleness.
## Single-main outage costs in hours and executions
The cost of the outage was one stretch of downtime, plus every schedule, webhook call and hand replay that stretch created, even though the queue-mode workers never stopped.
The ledger below is illustrative; the "how counted" column matters more than any number you would put in it.
| Figure | Unit | How counted |
|---|---|---|
| Hours down | Hours | Main process unreachable, from first failed health check to first successful execution |
| Schedules missed | Executions | Expected firings from each Schedule Trigger during the window, minus those that actually ran |
| Webhook calls missed | Requests | Inbound calls at the proxy or load balancer that returned an error or timed out |
| Senders who got errors | Distinct senders | Unique source systems in those failed requests |
| Hours of manual replay | Person-hours | Time spent re-triggering, reconciling and checking for duplicates afterwards |
Illustrative ledger; replace the descriptions with your own logs.
Because the main instance runs the timers, a dead main means the executions are never created. Don't assume n8n makes up the missed firings afterwards; check that against your own workflows.
When a webhook call arrives, the proxy in front of n8n answers for it, usually with a gateway error. The sender sees that error, not an n8n message. Whether it retries depends entirely on the sender, so some of those calls are gone for good.
### Manual replay of missed n8n executions
Replay is the expensive line, because someone has to work out what was missed. That means comparing the proxy's failed requests against the executions that ran, then re-sending without double-processing.
## Multi main with leaders, followers, Redis and workers
Multi main runs several n8n main instances behind a load balancer. All share one Postgres database and one Redis, with Redis deciding which main is the leader and workers executing the jobs. That's why each prerequisite from the last section matters.
### How n8n multi main leader election works
Each main tries to set a leader key in Redis. The one that holds it is the leader and renews it on a timer. Followers poll that key, and if it expires because the leader stopped renewing, one of them claims it.
Two settings control this: the key's time-to-live and the check interval. Together they set how long a dead leader goes unnoticed, so tune them knowing that faster detection also makes a Redis hiccup more likely to trigger a needless handover.
### n8n multi main leader versus follower duties
**Only the leader owns the work** that must happen exactly once. Everything that's safe to do on any node is spread across all mains.
| | Leader | Follower |
|---|---|---|
| Triggers and schedules | Registers and fires them | Does not run them |
| Webhooks | Receives and enqueues | Receives and enqueues |
| UI and API | Serves requests | Serves requests |
| Failover | Loses the key if it stops renewing | Claims the key when it expires |
The table shows that losing a follower costs you capacity, while losing the leader stops every cron and polling trigger until someone else takes the key. Webhooks and the UI survive either way, provided the load balancer stops sending traffic to the dead node.
When the key expires, a follower takes it and re-registers the triggers and schedules. n8n doesn't replay anything that should have fired in the gap.
A webhook that reached a dead main before the balancer noticed is a separate failure, and no Redis setting fixes it.
Workers aren't part of the election. They pull jobs from the Redis queue and run them, whichever main enqueued them. Healthy workers keep executing queued jobs through a leader change, but they can't start a schedule that no main is registering.
## Licence, infrastructure and cost for multi main
Skip any one of the paid licence, Postgres, Redis, a load balancer or a shared encryption key and the second main protects nothing. Multi main needs a paid licence, since Community lacks it, plus the rest.
### n8n multi main licence and plan requirements
Community costs 0 € per month, according to n8n's pricing page, and has no multi main, so a free install stays a single point of failure however many workers you add.
The paid tiers on that page are Starter at $20, Pro at $50 and Business at $800 per month, billed annually. The jump from Pro to Business is **more than thirteen times**, so check which plan your redundancy requirement actually lands on before budgeting.
Queue mode comes first, and multi main sits on top of it.
1. Postgres as the database, since the mains and workers must share state.
2. Redis, which carries the queue and coordinates which main is leader.
3. A load balancer in front of the mains, with health checks that drop a dead one.
4. The same encryption key on every main and worker, or credentials fail to decrypt.
The table shows what each route costs in money and effort, and what it survives.
| | Plan or licence | Infrastructure | Monthly cost | Setup effort | Failure tolerance |
|---|---|---|---|---|---|
| Single main | Community | One main, workers optional | 0 € licence | Low | None if the main dies |
| Multi main, self-hosted | Paid licence; Community excluded | Postgres, Redis, load balancer, several mains | Licence plus your servers | High | Survives a main failing, if every piece above is right |
| n8n Cloud | Starter, Pro or Business | Run by n8n | 20 €, 50 € or 667 € by plan | Low | Depends on n8n's platform, not your config |
You can't run a second main without a licence. Either move to Cloud, where n8n operates the infrastructure, or keep a single main and automate its restart and monitoring so a dead one is noticed in minutes.
Here the paid door is the only way to a second main, and that's the usual way control gets sold: the self-hosted or air-gapped build ships cut down, and the features the buyers with the strictest requirements need stay behind the licence.
Activepieces has an MIT-licensed core and doesn't sell those buyers a smaller product. Its air-gapped build runs the same enterprise controls as the managed cloud: single sign-on, SCIM provisioning, custom roles, audit logs, release management and external secret managers.
MoneyGram, Moneypenny, Alan and FundingSocieties run Activepieces in production.
## Mistakes that left the second main useless
Five setup gaps, all documented and all missed, kept the second main idle instead of taking over. The list below is the root-cause set for this outage, so run it as a checklist against your own deployment before the next restart.
- The multi-main flag was set without a shared Redis, so the mains had no common state to elect a leader from (multi-main setup page, queue mode docs).
- The load balancer had no health checks, so it kept routing to the dead main (the docs' monitoring page on the health check endpoints).
- The mains ran different versions or different encryption keys (configuration and environment variables docs).
- The webhook URL was pinned to one host instead of the balancer (the webhook URL variable in the endpoint environment variables docs).
- Nothing alerted on a leader change: (monitoring docs).
The flag `N8N_MULTI_MAIN_SETUP_ENABLED=true` changes nothing for traffic. n8n doesn't route requests between mains; your balancer does. Without health checks against `/healthz`, it kept sending webhooks to the dead host. The flag was on, and users still got a 502.
If the mains don't run the same n8n version and share one encryption key, failover breaks. A different key means one main can't decrypt credentials the other saved, so a failover fails on the first credentialed node.
A different version means two mains disagreeing about the same database schema.
**Multi-main moves the single point of failure; it doesn't remove it.** Leader election and queue state live in Redis, and workflows live in Postgres. One Redis instance means one box whose loss stalls every main, however many you run.
**Multi-main moves the single point of failure; it doesn't remove it.
Only a leader change tells you that the first main died and the second took over. With no alert on it, the team learned about the failure from a customer. Page on it, because the next failure may leave no leader at all.
## n8n multi main runbook after an outage
The team's fix was to write down what multi main needs, check it from outside the cluster, and rehearse losing the leader until recovery stopped being a surprise.
### n8n multi main configuration and health checks
Before the outage, the multi main setup lived in one engineer's head and a few environment variables nobody had listed together.
Now there's a single document in the repo covering the licence that enables multi main, the Redis connection every main and worker shares, the queue-mode settings, and which instance is expected to hold leadership at rest.
The other half went to the load balancer. It now probes each main's health endpoint and pulls a main out of rotation the moment it stops answering, instead of sending webhooks to a process that's up but useless.
The probe tells you whether a main is serving. It doesn't tell you whether a leader exists, which is why the alerts below matter.
### The failover drill
Once a quarter, someone kills the current leader on purpose, during working hours, with the team watching.
The drill has a recovery-time target written down beforehand, and the team measures against it: how long until another main takes leadership, and how long until scheduled triggers fire again.
If the number is worse than the target, the config or the health checks change before the next drill.
Two signals are covered by alerts: Redis becoming unreachable or degraded, and any change of leader. A leader change isn't always an incident, but you want to know it happened before a customer tells you. The drill also tests that these alerts fire.
For executions missed during a gap, the team wrote a replay procedure. It's: find the window, list what should have run, re-send webhooks the sender will retry or replay, and manually trigger the schedules that were skipped.
1. Document the multi main config: licence, Redis, queue-mode settings, expected leader.
2. Add load balancer health checks for every main.
3. Set alerts on Redis health and on leader changes.
4. Write the replay procedure for executions missed during a gap.
5. Run the kill-the-leader drill and record the recovery time against your target.
## What Activepieces does about this
The licence gap is the one Activepieces removes. Its core is MIT-licensed, so no licence key stands between you and a second instance, and a free install doesn't have to be a single point of failure.
You can add redundancy because your requirement calls for it, not because you've moved up a plan tier.
The air-gapped build carries the same enterprise controls as the managed cloud: single sign-on, SCIM provisioning, custom roles, audit logs, release management and external secret managers. Teams with strict requirements don't have to trade those away to stay self-hosted.
MoneyGram, Moneypenny, Alan and FundingSocieties run Activepieces in production.
**Licensing is only one of the gaps**. Whatever you run, the load balancer, health checks and alert on failover are still yours to set up and rehearse, and the checklist above applies to Activepieces as much as to n8n.
## Frequently asked questions
You can check each answer below against n8n's own pages, and the table at the end says which.
Is n8n multi main free on the community edition? No. Multi main is a licensed feature, so a community edition instance won't start in that mode without an enterprise licence key. Check the licence before you build the load balancer, not after.
Do I need queue mode to use multi main? Yes. Multi main sits on top of queue mode, so you also need Redis and a Postgres database shared by every instance.
Running the flag on a setup without those fails at startup rather than degrading quietly.
How many main instances can I run? The ceiling follows your licence, not the software. Read the limit off your plan or ask n8n, and don't assume more mains are allowed because the config accepts more.
Does multi main make workflows run faster? No. Workers execute workflows, so adding mains buys availability, not execution speed. Mains spread webhook and editor traffic, while one leader handles work like schedules and polling triggers. A slow queue still needs more workers.
### Can I move from a single main to multi main safely?
Yes, if you rehearse it. Move to Postgres and Redis first, keep the same encryption key and n8n version on every instance, and add mains one at a time. Check the leader's failover by killing it on purpose before you trust it.
The table puts the short answers next to the page that backs each one, so you can confirm them yourself.
| Question | Short answer | n8n source (as of 26 October 2026) |
|---|---|---|
| Free on community edition? | No, legal licence required | n8n pricing page |
| Needs queue mode? | Yes, plus Redis and Postgres | n8n docs, queue mode configuration |
| How many mains? | Set by your licence | n8n pricing page |
| Faster executions? | No, workers set throughput | n8n docs, queue mode configuration |
| Safe migration? | Yes, staged and rehearsed | n8n docs, multi-main setup |
Where a page and your own plan disagree, the plan and your account contact win.
## Related reading
- [Is n8n GDPR Compliant? Cloud vs Self-Hosted Setup](https://www.activepieces.com/blog/is-n8n-gdpr-compliant-cloud-vs-self-hosted-setup)
- [Self-Hosted LLM: Hardware, Cost, and Setup Guide for 2026](https://www.activepieces.com/blog/self-hosted-llm-hardware-cost-and-setup-guide-for-2026)
- [Self-hosted AI Platforms for Airlines](https://www.activepieces.com/blog/self-hosted-ai-platforms-for-airlines)
## References
- [n8n](https://n8n.io/pricing/)