n8n regular mode vs queue mode

Regular mode and queue mode compared by factor

This table compares n8n regular mode and queue mode across the factors that decide when a self-hosted instance needs to split up. Read each row against your expected execution volume, webhook traffic and availability requirement, then check the database and storage notes before you plan the build.

How the parts of each mode fit together

Regular mode runs triggers, webhooks and executions in one process, which is simple to operate but ties every workload to that process. Queue mode splits those roles across a main instance, Redis, workers and optional webhook processors, and each role below is a place where configuration can go wrong.

Deciding by load pattern, team and availability needs

Moving from regular mode to queue mode safely

This sequence takes a self-hosted n8n instance from one process that runs everything to a main instance, Redis and separate workers, with each prerequisite confirmed before traffic moves. The output is a queue mode deployment you can test, roll back and hand to operations.

1. Confirm the database is PostgreSQL

   The platform team checks the instance's database backend before anything else changes. Queue mode needs access to both Redis and the database, and the n8n docs say a distributed setup over SQLite is not supported, with PostgreSQL as the supported choice. If the instance runs on SQLite, plan a data migration to PostgreSQL in a separate, tested change, since the workers depend on that shared database. The step is done when the database engine and connection settings are documented and reachable from every planned node.

2. Provision Redis as the message broker

   The platform team deploys Redis that the main instance and every worker can reach over the network. Redis holds the queue of pending executions, and the main instance passes execution IDs to it, so its availability directly affects whether runs start. Confirm the access controls and network path with your security team and record who owns the Redis service. The step is done when a connection test from the main instance and from a worker succeeds and the team can state who is paged if Redis is unavailable.

3. Configure external binary data storage

   The platform team moves binary data, such as files handled by workflows, out of the local filesystem into external object storage. The n8n queue mode docs state that queue mode does not support binary data storage in the filesystem and point to S3 external storage for persistence. Any workflow that writes files locally will fail on a worker that cannot see the main instance's disk, so review workflows for this dependency first. The step is done when a test workflow with binary output runs on a worker and the object store holds the file.

4. Share the encryption key with all nodes

   The security or platform engineer copies the main instance's encryption key into the configuration of every worker and webhook processor, using the same secret store process you use for other n8n secrets. Workers need this key to read credentials stored in the database, so a mismatch shows up as failed credential lookups rather than a clear startup error. Restrict who can read the key and record where each node gets it. The step is done when a workflow using a stored credential runs successfully on a worker.

5. Set worker concurrency deliberately

   The platform team sets the concurrency value on each worker and records it in configuration. The default is 10, and the n8n queue mode docs recommend a value of 5 or higher, because low values across many workers can exhaust the database connection pool. Size the pool on the PostgreSQL side against the total number of workers and their concurrency, and confirm the connection limit with the database owner. The step is done when the chosen values are written down with the connection math and a load test shows no connection errors in the database logs.

6. Test webhook processor routing

   The integration team deploys webhook processors as separate nodes and routes a copy of production-like webhook traffic through the load balancer to them. The n8n docs advise against adding the main process to the load balancer pool, so verify that the load balancer rules send webhook paths only to the webhook processors and that the main instance still handles timers and triggers. Check that each test webhook produces one execution and that the response codes match the originals. The step is done when routing results are logged and no webhook reaches the main instance's public endpoint.

7. Remove the main process from the webhook pool

   After routing tests pass, the platform team removes the main instance from the webhook load balancer pool during a change window agreed with the business owners. Keep the main instance running so that timers and triggers continue, and watch execution counts, queue depth and error logs for the first run cycle. Confirm with the owners of each critical workflow that their webhooks still fire. The step is done when the pool lists only webhook processors, the queue drains normally, and the change record captures the before and after configuration.

8. Document the rollback path

   The platform team writes the steps to return to regular mode, including restoring the main instance to the webhook pool, pausing workers and confirming that pending executions in Redis are handled. Store the previous configuration and a database backup taken before the change, and test the restore procedure in a non-production copy. Name the person who can approve a rollback and the signals that trigger it. The step is done when the rollback runbook has been rehearsed once and stored with the change record.

Upgrades, backups and monitoring in each mode

This table compares what regular mode and queue mode ask of your team after go-live: upgrades, backups, monitoring and skills. Read it as a checklist of extra moving parts in queue mode, then confirm each item against your own environment and the n8n and PostgreSQL documentation for your target versions.

Which high availability setup needs an n8n Enterprise license

Questions buyers ask before moving to queue mode

What to confirm with n8n and your own environment

This sequence turns the queue mode decision into a checked list of licensing, database, Redis, binary data and network facts for your own n8n release and infrastructure. It ends with a written record that your team and any implementation partner can review before a scaling change is built.

1. Confirm the n8n license and edition for your use

   Start by reading the current n8n license file and pricing page against your intended use, because internal business use is covered by the Sustainable Use License while files with .ee in their name require an n8n Enterprise License. Ask n8n in writing which features you need, including multi-main high availability, which is restricted to Enterprise self-hosted deployments and is not available on n8n Cloud. You are done when a named owner has a written answer for each feature on your list, dated and filed with the architecture record.

2. Match the PostgreSQL version to your n8n release

   Check the n8n release you plan to run against the n8n documentation and confirm which PostgreSQL major versions it supports, since queue mode requires PostgreSQL rather than SQLite. Compare that list with the PostgreSQL versioning policy so you know which major versions are still within their support window for your planned operating period. You are done when the chosen PostgreSQL version, its end-of-support date and the n8n release are recorded together, and the team has confirmed that SQLite will not be used for any distributed component.

3. Verify Redis hosting and failover behavior

   Confirm where Redis will run, whether it is managed or self-operated, and how it fails over, because Redis holds the queue of pending executions and n8n needs access to it from the main instance and every worker. Ask your platform team how a Redis failure affects in-flight and pending executions, and whether your recovery procedure has been tested. You are done when you have a diagram showing Redis reachability from each n8n process and a written failover runbook signed off by the operations owner.

4. Decide where binary data will live

   Confirm that your queue mode design will not rely on filesystem storage for binary data, because n8n does not support queue mode with filesystem binary data and its queue mode documentation points to S3 external storage. Ask the storage team whether the S3 service you plan to use is compatible with the S3 interface n8n needs, and who holds the access keys and lifecycle rules. You are done when the storage target, the access model and the retention rule for binary data are documented and tested with a sample workflow that handles a file.

5. Map network placement for main and webhook processors

   Document which subnet the main instance, each worker, and any webhook processor will sit in, and which of them must accept inbound traffic from the internet or partner systems. The n8n documentation advises against adding the main process to the load balancer pool, so the webhook processors should be the only n8n processes exposed to incoming requests. You are done when a network diagram shows the allowed flows between processes, Redis, PostgreSQL and storage, and the security team has reviewed the firewall rules.

6. Configure the load balancer and encryption key sharing

   Set the load balancer so that it routes webhook traffic only to webhook processors, and confirm that the encryption key from the main instance is shared securely with every worker and webhook processor, since they need it to read stored credentials. Store the key in your approved secrets system and check that its rotation plan covers all processes at once. You are done when a test request reaches a webhook processor, a test execution runs on a worker, and the key distribution method is recorded in your change log.

7. Test worker concurrency against the connection pool

   Set worker concurrency with the n8n queue mode guidance in mind: the default is 10, and the documentation recommends a value of 5 or higher because low values with many workers can exhaust the database connection pool. Run a load test that matches your expected execution volume and watch PostgreSQL connection counts during the test. You are done when the test results, the chosen concurrency value and the connection pool limits are recorded and approved by the database owner.

8. Get the decision and the open items in writing

   Collect the answers from the earlier steps into a single record that lists each confirmed fact, its source, its date and the person who verified it, along with any open questions for n8n or your vendors. Share the record with your architecture review and any implementation partner so the scope of a queue mode change is agreed before work starts. You are done when the record is approved and every open item has a named owner.