n8n queue mode and worker scaling guide

Why n8n queue mode matters once heavy workflows share one instance

Queue mode is the usual way to separate intake from execution once heavy workflows share one n8n instance. It places a Redis broker between a main instance and a pool of worker processes, so the work of running a workflow no longer happens in the same process that serves the editor and receives webhooks. If your self-hosted instance slows down when long or frequent executions run, or webhook responses start arriving late, the cause is usually that intake and execution compete for the same resources. Before changing anything, review your execution history and identify which workflows run longest and which triggers fire most often. That tells you whether queue mode addresses your problem or whether the bottleneck sits elsewhere.

In queue mode, the main instance keeps responsibility for triggers and webhooks. When a trigger fires, the main instance hands the execution to Redis, and a worker picks it up and runs it. Workers read and write workflow data in PostgreSQL, so the database becomes a shared dependency for every process in the setup. This split is what makes the editor responsive under load, but it also means every worker must reach the same database with the same configuration. Confirm the exact database connection settings, the Redis connection settings and the worker startup commands against the current queue mode documentation for the release you plan to run, because these details change between versions.

The first hard part is the encryption key. Credentials are stored encrypted in the database, and in queue mode the main instance's encryption key must be shared with every worker and webhook processor so each one can decrypt them. A mismatch does not usually show up as a clear error at deployment time, so failures can appear later as credential errors inside individual workflows. Plan how the key is generated, stored, distributed and rotated before you add the first worker. Your secrets management process should cover every host that runs an n8n process, not only the main instance.

The second hard part is data growth and new single points of failure. Each execution writes records to PostgreSQL, and more workers mean more writes in the same period, so you need a pruning policy for execution data and a backup plan that matches it. Redis and PostgreSQL also become single points of failure unless you design redundancy for them. Multi-main high availability for the n8n instance itself is limited to Enterprise self-hosted deployments, so confirm your license before you assume that option. Finally, sizing depends on your workflows rather than on a fixed formula. Run length, payload size, node types, trigger frequency and external API rate limits all shape the answer, so ask any partner for a load test on representative workflows before fixing the worker count.

Which n8n and infrastructure components queue mode touches

Queue mode splits one n8n process into roles that share state through Redis and PostgreSQL. Each component below holds different data and needs its own configuration, so a change in one place can slow or break the others.

Main instance

The main instance serves the editor and the public API, handles triggers and schedules, and hands executions to the queue. It also holds the encryption key that protects stored credentials. Check that the main instance, the workers and the webhook processors run the same n8n release, because mismatched versions can fail in ways that are hard to trace. Confirm the queue mode settings for the release you run in the current n8n queue mode documentation, including how the instance is switched into queue mode.

Webhook processors

Webhook processors receive inbound HTTP calls and place the resulting executions on the queue, so heavy webhook traffic does not compete with the editor. They read workflow definitions and credentials from PostgreSQL, which means they need the same encryption key as the main instance. Size them separately from workers and place them behind your reverse proxy with the same external URL that the main instance advertises. Confirm the exact process type names and endpoints for your release before writing deployment templates.

Worker processes

Workers pull executions from Redis and run the workflow steps, which is where CPU, memory and outbound connections are consumed. Each worker runs a set number of concurrent executions, so total throughput depends on worker count and concurrency together. Workers also read credentials and write execution results to PostgreSQL, so they need the shared encryption key and network access to both data stores. Confirm the concurrency setting and its default in the documentation for your release before choosing values.

Redis as the execution broker

Redis holds the queue of pending executions and passes jobs from the main instance and webhook processors to the workers. Losing Redis data can strand queued jobs, so decide whether persistence is enabled and how it is backed up. Keep Redis on a private network, restrict access with authentication, and monitor queue depth so a growing backlog is visible before users notice delays. Confirm the connection and persistence settings in the current queue mode documentation for your release.

PostgreSQL as the shared data store

PostgreSQL holds workflow definitions, encrypted credentials, users and execution records, and every process in the cluster reads and writes it. Connection count grows with the number of workers and processors, so connection limits and pooling need to be planned, not left at defaults. Execution data also grows with volume, which makes pruning settings and table maintenance part of capacity planning. Confirm the database settings and pruning options for your release in the n8n documentation.

Encryption key stored with the main instance

The encryption key decrypts credentials in the database, and queue mode requires every worker and webhook processor to hold the same key. A key that differs between processes causes credential failures that appear only on some executions, which makes them hard to diagnose. Store the key in your secrets manager, inject it identically into every process, and record how it is rotated. Losing the key makes stored credentials unrecoverable, so include it in your backup procedure and access review.

Decisions to settle before scaling workers

This table compares the main architecture choices for n8n queue mode, with the fit and operational cost of each option. Read each row as a decision to settle before you size infrastructure, and treat the high availability row as a question to confirm with your license before design starts.

Decision	Option	Operational trade-off	When it fits
Main and webhook layout	Single main with workers	One main handles triggers, webhooks and the editor, so editor and webhook load can compete with heavy executions.	Moderate webhook volume and a small team that wants the fewest moving parts.
Main and webhook layout	Separate webhook processors	Extra processes to deploy, monitor and keep on the same encryption key, but webhook traffic is isolated from the editor.	Webhook-driven workflows with bursty inbound traffic or strict response-time expectations.
Redis broker	Hosted in-house	Your team patches, backs up and monitors Redis, and owns failover and capacity alerts.	Organizations that already run and support Redis under standard operating procedures.
Redis broker	Managed service	Recurring service fees and a dependency on the provider's network and maintenance windows, with less local administration.	Teams that want to avoid running a stateful broker and can accept the provider's terms and data location.
PostgreSQL	Shared with other applications	Execution data growth and lock contention can affect unrelated applications, and pruning settings affect the whole instance.	Small deployments where a separate database server is not justified and pruning is planned.
PostgreSQL	Dedicated to n8n	A separate instance, backups and sizing to maintain, but execution load and maintenance are isolated.	Production workloads with high execution volume or long retention of execution data.
Scaling method	Add workers by count	Each worker is a separate process or container, so scaling adds memory and CPU across nodes.	Workloads where individual executions are heavy in memory or CPU.
Scaling method	Raise per-worker concurrency	Fewer processes, but one heavy execution can slow others on the same worker, and memory limits are shared.	Many short executions where worker processes have spare capacity.
High availability	Multi-main setup	Available only on Enterprise self-hosted deployments, so confirm entitlement with your license before designing failover.	Organizations with an Enterprise license that require continuous editor and trigger availability.

How to build a queue mode deployment step by step

This sequence moves a self-hosted n8n instance into queue mode, with a main instance, workers and webhook processors sharing one database, one Redis queue and one encryption key. Each step ends with a check that confirms the layer works before the next layer depends on it. Run these checks on a staging copy before production.

Confirm the license and pin the release
Before any infrastructure is ordered, confirm that your intended use fits the Sustainable Use License, which covers internal business use and non-commercial or personal use. Check that no files with .ee in their name or directory will be deployed unless you hold a valid n8n Enterprise License. Choose the release you will run, record it alongside the edition, and confirm in the n8n queue mode documentation that the features you need are available on that edition. This step is done when a signed-off record names the edition, the license basis and the pinned version that every host will use.
Provision PostgreSQL and Redis with backups and network rules
Your platform or database team creates the PostgreSQL database that stores workflow and execution data, and the Redis instance that carries jobs from the main instance to the workers. Enable backups for PostgreSQL and run a restore test to a separate host before go-live. Allow connections to both services only from the main instance, the worker hosts and the webhook processors, and keep both off public networks. This step is done when a worker host connects to both services from its own network segment and the restore test produces a usable copy of the database.
Point the main instance at the database and queue
Configure the main instance with the PostgreSQL connection details, then set queue mode and the Redis connection using the settings named in the queue mode documentation for your release. Store these values in version-controlled configuration or a secrets store so that workers later receive identical values. Start the main instance once the settings are in place. This step is done when the main instance starts without connection errors and the expected tables are present in the PostgreSQL database.
Copy the encryption key to every worker and webhook processor
Take the encryption key from the main instance and set the identical value on every worker and webhook processor before any of them start for the first time. Store the key in your secrets manager and restrict who can read it, because anyone holding it can decrypt stored credentials. Verify that each host holds the same value using your secrets tooling. This step closes with a credential check in step six: a test execution on a worker that uses a credential created on the main instance must succeed. If workers are not yet running, record the key verification and complete the credential check once they are.
Start the main instance and confirm the editor
Start the main instance and open the editor through its internal address. Create a simple test workflow with a manual trigger and a harmless node, save it, and then run it. With no workers attached yet, the run should wait in the queue, which is expected at this stage and confirms the main instance can accept and record work. Confirm this behavior against your release. This step is done when the editor loads, the workflow saves, and the saved workflow is visible after a page reload.
Start workers and confirm they pick up test executions
Start the worker processes on their hosts, each pointing at the same database, the same Redis instance and the same encryption key. Run the test workflow again and check the execution record to confirm a worker processed it. Add a test step that reads a stored credential so that decryption on the worker is confirmed. Leave worker concurrency at the default until you have measured CPU, memory and database connection use under a representative load. This step is done when a test execution is routed to a worker, the credential decrypts there, and the worker logs show the job.
Move webhooks to the webhook processors
Start one or more webhook processor instances that share the database, the Redis instance and the encryption key. Route production webhook traffic to them through your load balancer or reverse proxy, and confirm in the queue mode documentation how the main instance and webhook processors should be configured for your release. Test with a webhook workflow while a long-running workflow occupies the workers, and time the response. This step is done when the webhook is answered during that load and the editor remains responsive for the same period.
Configure execution data retention
Set how long execution data is kept and enable pruning so the PostgreSQL database does not grow without limit. Agree the retention period with the data owner and the audit team, and confirm the pruning setting names in the configuration documentation for your release. Run a scheduled prune against a test copy of the database and check that old execution records are removed while workflows, credentials and recent executions remain. Confirm that the backup job still completes afterwards. This step is done when the pruned test database holds the expected records and the backup job succeeds on it.

What drives the effort and cost of scaling n8n workers

This table lists the factors that change how much work a queue mode scaling project takes and what a partner quote should cover. Read each row as a driver: the first column names it, the middle column explains how it adds effort, and the last column describes what your team can do to keep it contained. The main takeaway is that most effort comes from workflow design, data volume and environment count, so decisions made before scaling matter as much as the worker count itself.

Driver	How it raises effort or cost	How to keep it down
Number and weight of workflows	Each workflow needs testing, credential mapping and queue routing. Heavy workflows with many nodes or long waits occupy workers longer and make capacity planning harder.	Inventory workflows by run frequency and runtime. Split heavy workflows into sub-workflows so long steps can be sized and monitored separately.
Execution frequency and payload size	High trigger volume increases Redis traffic, PostgreSQL writes and worker load. Large payloads inflate execution data stored in the database and slow each run.	Measure executions per day and peak bursts before sizing. Trim payloads to the fields a downstream step needs, and pass file references instead of file contents where possible.
Number of workers and webhook processors	Each added worker needs the shared encryption key, consistent configuration and monitoring. Separating webhook processors adds a second tier to deploy and test.	Start with a small worker pool and add capacity based on queue length and execution time observed in your environment. Confirm the scaling approach against the current queue mode documentation.
Environments (test, staging, production)	Each environment needs its own Redis, PostgreSQL, workers and secrets, and workflows must be promoted or copied without duplicate runs.	Keep test and staging smaller, use separate credentials, and disable production triggers in non-production environments before any copy or migration.
External integrations that rate-limit	Workers can queue up or fail when a third-party API returns rate-limit responses. Retry logic and concurrency limits must be tuned per integration.	Inventory each external API's limits with its vendor. Set per-workflow concurrency and retry settings, and isolate the most limited integrations in their own workflows.
Execution data retention	Keeping every execution for long periods grows PostgreSQL storage, slows queries in the editor and increases backup and restore time.	Decide retention periods and pruning settings before go-live, and record them with the business owner who needs the history. Confirm pruning options against your n8n version.
Compliance logging and audit needs	Regulated teams often need execution history, access logs and log export. These needs add storage, log routing and sometimes a log streaming feature available only on certain n8n plans.	Define which events must be retained, for how long and where they go, before designing storage. Confirm which logging features your license edition includes.
Managed or self-managed PostgreSQL and Redis	Self-managed databases and brokers require backups, patching, failover and sizing work that a managed service may already provide. Mixed models add integration steps.	List what your platform team already runs as managed services. Ask a partner to itemize database and broker work separately so you can compare with your own team's effort.

How queue mode differs by deployment model

On a single host, the main instance, webhook processors, workers, Redis and PostgreSQL usually run as containers on one machine, defined in a Compose file or a similar container definition. They share a private container network, so internal addresses are simple, but the whole deployment shares one failure domain.

Main instance and webhook processors: separate containers started from the same n8n image, with the webhook processor container exposed through a reverse proxy.
Workers: additional containers started from the same image with the worker command, added or removed on the host as load changes.
Redis and PostgreSQL: containers on an internal network, not published to the host's external interface.
Encryption key: supplied to every n8n container from one environment file or secret store entry, with file permissions limited to the operator account.
Upgrades and rollbacks: pin the image tag, back up PostgreSQL and the n8n data volume, then recreate the containers together. A rollback means restoring the previous tag and, if the release changed the database schema, restoring the database backup.

High availability for the main instance requires multi-main setup, which is available only on Enterprise self-hosted deployments. Confirm the exact container commands, network settings and resource limits against the n8n version you run, and confirm who owns the backup restore test.

How to protect the encryption key, Redis and credential access

In queue mode, the encryption key, the Redis broker and the database credentials form one trust boundary that spans the main instance, workers and webhook processors. Each card below covers one control that keeps that boundary tight without giving up the scaling you set up for.

Distributing the encryption key to every process

n8n queue mode requires the main instance's encryption key on every worker and webhook processor, because each one must decrypt stored credentials to run workflows. Confirm that every process reads the same key value at startup, and that no process has a stale copy from before a change. Treat the key as a shared secret with the same owner, storage and access review as the database password.

Storing the key in a secrets manager

Keep the encryption key in a dedicated secrets manager or the platform's secret store rather than in container images, shared configuration files or CI variables that many people can read. Inject it at runtime into each main, worker and webhook container, and restrict read access to the service identities that run those containers. Confirm that the key never appears in logs, process listings or support bundles.

Planning encryption key rotation

Changing the encryption key is not a simple config edit, because credentials already stored in PostgreSQL are encrypted with the old value. Plan the change as a maintenance window with a database backup taken beforehand, and confirm with n8n's documentation how re-encryption is handled for your version before you attempt it. Record who approves the change and how you will roll back if a process starts with the wrong key.

What breaks when the key changes

If a worker or webhook processor starts with a different key, it cannot decrypt stored credentials, so workflows that call external services fail with credential errors while the editor may still load. Webhook-triggered workflows are the most visible symptom, because the processor accepts the request but the downstream call fails. Test a key mismatch in staging so the alerts and runbook for this failure exist before production needs them.

Redis access controls and network isolation

Redis carries execution messages between the main instance and workers, so anyone who can write to it can inject or read jobs. Require authentication on the Redis instance, bind it only to the private network segment that n8n processes use, and block it from every other subnet, including the public edge. Confirm which Redis user and credentials each n8n process uses, and avoid a shared administrative account.

PostgreSQL credentials and TLS

Create a dedicated PostgreSQL role for n8n with rights limited to its own database, and do not reuse the administrator account. Enable TLS on connections from every n8n process to the database, and verify the server certificate rather than accepting any certificate. Rotate the database password through the secrets manager and confirm that all main, worker and webhook processes pick up the new value during the same change window.

Keeping webhook processors exposed and workers private

Only webhook processors need inbound access from the internet or partner networks, because they receive trigger traffic. Main instances, workers and the Redis broker should have no public route, and workers should accept no inbound connections at all. Check this with a network scan from outside the private segment, and confirm that the editor is reached through a separate path from webhook endpoints.

Limiting who can view sensitive executions

Execution history stores input and output data for each run, so a workflow that handles personal or financial fields exposes those values to anyone who can open its executions. Decide which roles may view execution data, and set data retention so sensitive payloads are pruned on a schedule that your policy requires. Confirm how project access and roles in your n8n edition limit execution visibility before you grant access to a wider group.

How to test that queue mode works and fails safely

The first test to run on a queue mode deployment is a placement check: confirm that executions actually run on the workers and not on the main instance. In queue mode the main instance handles triggers and webhooks and hands executions to workers through Redis, and workers read and write workflow data in PostgreSQL. Run a workflow that reports its host or process identity, trigger it several times, and record which process ran each execution. If executions still appear on the main instance, the worker pool is not doing the work you are paying to scale, and no load test result will mean much until that is fixed. Confirm the worker count and concurrency settings in the environment the workers actually read, not only in the configuration file you intended to change.

Next, test the reason the split exists. Start a workflow that runs for several minutes, then send webhook requests and open the editor while it runs. Webhooks should keep responding within the latency your callers expect, and the editor should stay usable. Repeat the test with a heavier mix of workflows, because the point of the exercise is to show that heavy workflows do not slow the front end. Load tests should use representative workflow mixes: the same node types, payload sizes, external calls and execution frequency your production workflows will have. A single synthetic workflow run in a loop tells you little about queue depth under real traffic. Record the queue backlog, execution start times and webhook response times for each run.

Then test failure. Stop one worker during a batch of executions and confirm what happens to the jobs it held. Whether a job is retried, left queued or marked failed depends on the n8n release and its queue settings, so verify the exact behavior against the release in use rather than assuming it. Do the same with Redis and PostgreSQL in a test environment only, and observe what the main instance, workers and editor do while each is unavailable and after it returns. Also confirm that credentials decrypt on every worker, since the encryption key must be shared with all worker and webhook processor nodes. A worker started with a mismatched key may appear healthy while failing every credential-based step. Finally, confirm that pruned execution data does not break running executions or workflows that reference earlier execution records.

Record evidence for each test: the n8n version, the topology (number of mains, workers and webhook processors), queue and concurrency settings, the exact commands or triggers used, timestamps, execution outcomes, webhook latency figures, and screenshots or log excerpts showing which process ran each job. Keep the failure test results separate from the happy path results so the team can see what was observed under each condition. Ask your implementation partner, or your own platform team, to deliver these records in a form an auditor or change board can read. Treat the results as evidence about your deployment only. They do not replace the vendor's documentation or a fresh test after an upgrade.

What to monitor, back up and document after go-live

Queue mode splits one n8n installation into several processes that depend on Redis and PostgreSQL. The checks below cover what to watch, what to protect and what the team must be able to rebuild, so a problem in one component does not go unnoticed or become unrecoverable.

Queue depth and worker health

Track how many executions wait in the Redis queue and how many are active on each worker. A queue that keeps growing while workers stay busy usually means too few workers or too much concurrency per worker. Confirm that every worker process reports healthy, and alert when a worker stops picking up jobs even though the queue has work waiting.

Execution duration and failure rates

Record how long executions take and how often they fail, grouped by workflow. Heavy workflows that share workers can slow lighter ones, so compare durations before and after adding workers. Review failures by error type to separate credential problems, external API limits and timeouts, since each needs a different fix.

Redis memory and persistence

Watch Redis memory use, eviction behavior and whether persistence is enabled as the team intends. Redis holds queued jobs, so a restart without persistence or memory pressure can lose or delay executions. Confirm the persistence settings and maximum memory with the people who operate Redis, and document them in the runbook.

PostgreSQL connections and sizing

Each main, worker and webhook process opens its own database connections, so connection counts grow with the number of processes. Monitor active connections, slow queries and lock waits against the limits set on the database server. When connections approach the limit, check connection pooling and the number of workers before increasing database size.

Disk growth from execution data

Execution records and their stored data accumulate in PostgreSQL and can fill disks over time. Track table and volume growth and confirm that the pruning settings match the retention period the business requires. Pruning runs only as configured, so check that old executions are removed on schedule and that the database volume has headroom.

Webhook response times

Measure how quickly webhook endpoints acknowledge requests, since callers such as payment or form providers often time out. Separate webhook processors from workers where traffic is heavy so that long executions do not delay responses. Test response times under expected peak load and alert on sustained increases.

Backups of PostgreSQL and the encryption key

PostgreSQL holds workflows, credentials and execution history, so it needs regular backups with retention agreed by the business. The encryption key must be backed up separately and stored in a controlled secrets system, because stored credentials cannot be decrypted without it. Run restore tests on a scheduled basis and record the time each restore takes.

Upgrade path and version compatibility

In queue mode, all main, worker and webhook processes must run compatible n8n releases, so upgrades change every process together. n8n ships minor releases frequently, so plan upgrade testing for queue mode and confirm the current release in the release notes before scheduling. Test workflows on a staging copy that uses the same queue setup.

Runbook and architecture record

Document the process topology, the Redis and PostgreSQL configuration, where the encryption key is held, the scaling thresholds and the restore steps. Include who responds to each alert and how to add or remove a worker. An architecture record that matches the running system lets a new engineer operate the platform without relying on the original builder.

Questions teams ask before scaling n8n with queue mode

Does n8n queue mode require an Enterprise license?

Confirm this with n8n in writing before you commit, because the answer depends on the license terms and plan features that apply to your version. The Sustainable Use License covers files that do not have .ee in their name or directory. Files with .ee require a valid n8n Enterprise License. Multi-main setup, which runs several main instances for high availability, is restricted to Enterprise self-hosted deployments. Ask n8n to identify which queue mode components, if any, fall under the .ee files, and check the current pricing page for plan terms. Your license question also depends on how you use the instance, since the Sustainable Use License limits use to internal business purposes or non-commercial use.

How long does it take to scale n8n with queue mode?

Duration depends on how much of the foundation already exists and how many workflows must move to the worker pool. The main drivers are whether Redis and PostgreSQL are already hosted and monitored, how many workflows are heavy enough to need separate workers, how many credentials must be re-entered or moved to a shared secrets source, and how much load testing you need before cutover. Work on the encryption key, worker sizing and execution data retention also adds time when those decisions are not already made. Ask any provider for a timeline that lists each phase, the environments involved and the test cases that must pass before go-live.

Can an in-house team set up n8n queue mode without a partner?

An in-house team can do it if it already runs containers or virtual machines, operates Redis and PostgreSQL in production, and has someone comfortable debugging Node.js services. The harder parts are sharing the encryption key correctly across processes, tuning PostgreSQL for execution write volume, and proving that webhooks stay responsive under load. Consider who will be on call after go-live, how many people understand the design, and whether the team has time to load test and document the setup. A partner is most useful when those skills or hours are missing, or when you want the scope, test results and handover written down before the platform carries production workloads.

What must our team provide before queue mode work starts?

Your team typically provides the hosting environment for the main instance, the workers and webhook processors, a Redis service that the workers can reach, and a PostgreSQL database with backups. You also need a secrets store or a secure way to hold the shared encryption key, representative test workloads that reflect your heavy workflows, and named owners for the platform, the workflows and security decisions. Access to the cloud accounts, data centers or air-gapped network where the platform will run is required, along with a change window for cutover. Missing owners and test workloads are the most common causes of delay, because decisions and sign-off stall without them.

Is queue mode scaling work fixed-scope or open-ended?

Most DeployOpen engagements are fixed-scope, meaning the scope, deliverables and timeline are agreed in writing before work starts. For queue mode, the written scope should name the instance topology, the number of workers and webhook processors, the Redis and PostgreSQL design, the execution data pruning policy, the key handling method, the load tests and the handover documents. Changes that add workflows, environments or infrastructure should go through a written change request with an updated quote. Ask for the assumptions list in the scope, because most cost changes come from assumptions about hosting, data volume and test coverage that turn out to be wrong.

How do retainers cover changes after queue mode goes live?

DeployOpen offers ongoing support, upgrades and continuous testing as retainers, which suit teams that expect regular change after go-live. A retainer can cover reviewing worker capacity as workflow volume grows, applying n8n minor releases that ship roughly weekly, testing workflows before upgrades, rotating the shared encryption key and reviewing database growth. The main cost drivers are how often you change the platform, how many workflows and environments are in scope, and how quickly you need responses. Ask for the exact list of covered activities, response expectations and what falls outside the retainer, so that new work can be scoped separately.

What breaks when workers do not share the same encryption key?

Workers that hold a different encryption key from the main instance cannot decrypt credentials stored in PostgreSQL, so executions that use those credentials fail on that worker. The problem often appears after a key rotation, when one worker or webhook processor still runs with the old value, or when a new worker is added from a template with a stale secret. Keep the key in one secrets store, inject it into every main, worker and webhook process from that source, and restart processes in a controlled order after any change. Verify with a test workflow that uses a credential and runs on each worker type, and record the check in your change log.

How should we size PostgreSQL and set execution data pruning for queue mode?

Size PostgreSQL from the run rate of your workflows, the amount of data each execution stores and the retention period you choose, not from the number of workers alone. Each execution writes rows that accumulate over time, so the database can slow the editor and webhooks if pruning is not configured. Decide how long execution history must be kept for debugging and audit, enable pruning to that period, and monitor table size, connection counts and query latency during load tests. Test the pruning job under peak volume, confirm backups still complete and record the settings so that future upgrades do not reset them.

How DeployOpen scopes, builds and hands over n8n queue mode

DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, including n8n queue mode and worker scaling. Work runs under a written, fixed scope so the Redis broker, workers, PostgreSQL sizing and key handling are agreed before any build starts.

How we scope

Inventory current workflow volume, peak webhook traffic and long-running executions before choosing a worker count.
Confirm the license edition and whether multi-main, SSO or Git environments are needed, since these depend on the plan.
Agree in writing which hosts, Redis and PostgreSQL instances, and worker pools are in scope, and what is excluded.

How we build

Deploy the main instance, Redis broker and worker pool in your own cloud account, data center or air-gapped network.
Set one shared encryption key across the main instance, workers and webhook processors, stored in your secrets system.
Test queued executions under realistic load, then tune worker concurrency and execution data pruning against the results.

How we hand over

Provide documentation of topology, scaling settings, key rotation steps and the runbook for adding or removing workers.
Walk your platform and operations team through restart order, Redis failure behavior and how to read queue backlogs.
Confirm acceptance tests against the deliverables in the written scope before the engagement closes.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the build.
Review queue mode settings and worker capacity before each n8n minor release, since releases ship roughly weekly.
Confirm with your team which support response terms apply, as these are defined in the retainer agreement, not assumed.