How n8n high availability works and why it is harder than it looks
Automations and AI agents now stop business processes when n8n is down, and webhooks fail silently when it is. High availability is possible on the Enterprise edition through multi-main, which runs several main instances. The Community edition does not include multi-main, so it needs a different recovery design, and that design should be settled before the platform carries production work. Many teams only find this gap during their first outage, when an inbound webhook from a payment or onboarding system has already been lost. The decision for an architect is which edition and which recovery design match the business cost of an outage.
Uptime depends on several components, not on one server. The main instance handles triggers and webhooks. In queue mode, workers run the executions that the main instance passes through Redis, and PostgreSQL holds the workflow data that workers read and write. Webhook processors can be separated so that incoming requests are handled apart from the editor. The encryption key must be shared with every worker and webhook processor so they can access credentials stored in the database. A load balancer sits in front of the entry points. Each of these components is a point where a single failure can stop work.
The editor is the wrong health signal. If the editor loads, it does not prove that executions are running. Redis going down can stop the hand-off from the main instance to workers, so runs queue or fail while the interface looks normal. A worker or webhook processor that does not hold the correct encryption key cannot read credentials, so its executions fail on the first step that needs a secret. PostgreSQL trouble affects both workflow data and execution records. A lost main instance stops triggers unless a second main instance is active. Your monitoring should check each component and confirm that a test workflow completes end to end.
Before you commit to a design, confirm several points with n8n and in your own environment. Check whether multi-main is included in the Enterprise license you would buy and how the license applies to the files your deployment uses. Ask for current guidance on Redis and PostgreSQL redundancy for your chosen topology, since the supported patterns are not something this page can state in detail. Plan how the encryption key is stored, rotated and distributed to every node. Finally, schedule failover tests across upgrades, because n8n ships minor releases roughly weekly and a configuration that works today can change under a newer version.
Which n8n components need redundancy
A highly available n8n deployment is only as available as its weakest component, and in queue mode that spans several separate pieces. The cards below cover what stops when each one fails and what to confirm in your own environment. Options for the main instance depend on your edition, so check the license terms before designing around multi-main.
Main instance
The main instance serves the editor and API, and in queue mode it also receives triggers and webhooks and passes executions to the workers through Redis. If it stops, schedule triggers do not fire and inbound events are not accepted, while work already queued waits for it to return. Multi-main, which runs several main instances, is limited to Enterprise self-hosted deployments. Confirm your edition, how the instance is restarted, and where its configuration and state are kept.
Webhook processors and load balancer
Webhook processors are separate n8n instances that accept inbound webhook calls, so heavy webhook traffic does not compete with the editor. If one fails, callers receive errors for requests it was handling, and the load balancer in front of the processors must stop sending it traffic. Confirm that at least two processors run, that health checks remove failed nodes from rotation, and that the load balancer itself has no single point of failure.
Worker pool
Workers take queued executions from Redis, run the workflow steps, and write results to PostgreSQL. When one worker fails, the executions it was running are interrupted, while the remaining workers keep draining the queue. Confirm how many workers your peak load needs, how an interrupted execution is retried or reported, and that a process manager or orchestrator restarts failed workers automatically.
Redis execution broker
Redis carries executions between the main instance and the workers. If it becomes unavailable, new executions cannot be queued and workers stop receiving work, which halts the pipeline even when every n8n process is healthy. Confirm whether Redis runs as a replicated or managed service with automatic failover, how its persistence is configured, and who responds when a failover occurs.
PostgreSQL database
PostgreSQL holds workflow definitions, encrypted credentials, and execution history for every n8n process. Without it, no process can read workflows or record results, which makes it the dependency that most often needs a formal failover design. Confirm whether you use a managed high availability service or a replicated cluster, how backups and point-in-time recovery are tested, and how execution data pruning keeps the database within your recovery targets.
Encryption key
The encryption key decrypts the credentials stored in PostgreSQL. In queue mode, every worker and webhook processor must hold the same key, so a mismatch causes credential failures on some nodes only. A lost key makes stored credentials unrecoverable even when a full database backup exists. Confirm that the key sits in a secrets manager with its own backup, that every node receives it through the same process, and that rotation has been rehearsed.
Which n8n high availability design fits your team
This table compares three ways to run n8n with different levels of uptime protection: a single main on Community, queue mode with separate webhook processors, and multi-main on Enterprise. Read each row across to see when a design fits, what it costs to operate, and what to confirm with n8n before committing. The main takeaway is that multi-main is the only option in this comparison that n8n restricts to Enterprise self-hosted deployments, so license scope should be settled before architecture.
| Decision point | Single main on Community | Queue mode with webhook processors | Multi-main on Enterprise |
|---|---|---|---|
| When it fits | Internal workflows where a short outage and a manual restore are acceptable | Webhook-heavy or long-running workloads that need isolated processing, with recovery still handled by the operator | Business-critical triggers and webhooks that must keep running when one main instance fails |
| Licensing | Free self-hosted Community edition, subject to the Sustainable Use License | Queue mode is part of the self-hosted platform, but confirm with n8n which features your license scope covers | Requires a valid n8n Enterprise License because multi-main is restricted to Enterprise self-hosted deployments |
| Failover behavior | No automatic failover; recovery depends on restoring the database, encryption key and instance | Main instance remains a single point for triggers and webhooks; workers and webhook processors can be replaced | Several main instances provide high availability; confirm the exact failover timing and behavior with n8n |
| Operator time | Backup testing, restore drills, and manual restart after failure | Redis and PostgreSQL monitoring, worker scaling, shared encryption key handling across nodes | Coordinating multiple main instances, Redis and PostgreSQL redundancy, and upgrade sequencing across all nodes |
| Shared encryption key | One key held by one instance, backed up securely | Main key must be shared with all worker and webhook processor nodes to access stored credentials | Confirm with n8n how the key is distributed and rotated across every main instance |
| Data stores to protect | PostgreSQL database and encryption key backup and restore | PostgreSQL and Redis, both needing backup and recovery planning | PostgreSQL and Redis redundancy, with each component's failure mode documented |
| Confirm with n8n before choosing | Support scope for Community deployments and recovery expectations | Supported configuration for your version, queue sizing guidance, and any license limits | Enterprise license terms, supported multi-main topology, and required infrastructure |
Building n8n high availability in the right order
This sequence builds redundancy from the data layer upward, so each layer is verified before the next depends on it. It ends with a load-balanced entry point and health checks that remove failed nodes from service. Each step closes with a check you can run and record.
Confirm edition and license before design
Your team or the partner confirms which n8n edition you run and whether the license covers the features the design needs. Multi-main setup is restricted to Enterprise self-hosted deployments, so a Community design can only provide queue-based workers and webhook processors, not multiple main instances. Confirm that any .ee files in your deployed version are covered by a valid Enterprise license. The step is complete when the edition, license key status and the feature list are written into the design record and signed off by whoever owns licensing.
Place PostgreSQL and Redis on redundant infrastructure
Platform engineering provisions PostgreSQL and Redis with redundancy suited to your hosting environment, because every main, worker and webhook processor depends on both. PostgreSQL holds workflow and execution data, and Redis carries executions between the main instance and workers. Confirm the failover method your database and cache platforms support, and document who is responsible for promoting a replica or restoring service. The check is a controlled failover test: stop the active database or cache node, confirm n8n nodes reconnect, and confirm a test workflow runs end to end afterward.
Share the encryption key across all nodes
In queue mode, the encryption key from the main instance must be present on every worker and webhook processor so they can decrypt credentials stored in the database. The engineer who manages secrets sets the same key value in each node's configuration through your secrets store, and nothing is copied between hosts by hand. Keep the key outside the repository and limit who can read it. The check is a credential test: run a workflow that uses a stored credential on a main, a worker and a webhook processor, and confirm each one authenticates successfully against the same credential.
Deploy separate webhook processors and workers
Engineers deploy webhook processors to receive inbound traffic and workers to run executions, each as its own service that can be scaled and restarted independently. Both connect to the same PostgreSQL database and Redis broker set up earlier. Set worker concurrency according to the hosts you provision and the workloads you expect, and record that choice in the design. The check is a restart test: start a long batch of queued executions, stop one worker mid-run, and confirm that a restarted or remaining worker picks up the queued jobs without losing them.
Configure multiple main instances on Enterprise
On an Enterprise license, engineers run several main instances against the same database and Redis broker, following the multi-main configuration in the n8n queue mode documentation. Each main serves the editor and handles triggers and webhooks, so its configuration must match the others on encryption key, database and broker settings. Confirm with the vendor documentation how scheduled triggers are coordinated between mains in your version before relying on them. The check is a cross-node test: log into each main, open the same workflow, and confirm that a change saved on one is visible on the others and that a scheduled trigger fires only once.
Put a load balancer in front of the mains
Network engineers place a load balancer in front of the main instances and webhook processors, with a single public hostname for the editor and a separate one for inbound webhooks. TLS is terminated at the balancer or at each node according to your security standard, and the public webhook address configured in n8n must match the address external systems call. Confirm how sessions behave across mains for editor logins. The check is an end-to-end test: send a webhook request through the public hostname several times, confirm each request is handled, and confirm the editor stays logged in when traffic moves between mains.
Add health checks and failover verification
Engineers configure health checks at the load balancer and in your orchestration or monitoring tool so that a main, worker or webhook processor that stops responding is removed from rotation. Define what counts as healthy, such as the service answering its health endpoint and connecting to PostgreSQL and Redis, and alert the on-call team when a node is removed. The final check is a failure drill: stop one main and one webhook processor in turn, confirm the balancer routes traffic to the remaining nodes, confirm alerts fire, and confirm that the nodes return to service after restart. Record the results as the acceptance evidence for the design.
What drives n8n high availability effort and cost
This table lists the factors that most change how much work an n8n high availability design takes and what a fixed-scope quote should cover. Read each row as a question to answer before scoping, since the answers decide whether a single main with backups is enough or whether multi-main and separate webhook processors are needed. Most of the effort sits in the edition decision, the Redis and PostgreSQL hosting model and the evidence the compliance team expects.
| Driver | Effect on effort | What to ask for in a fixed-scope quote |
|---|---|---|
| Number of environments | Each environment (production, staging, test) needs its own main, workers, Redis, database and encryption key handling, so effort grows with every copy kept highly available. | Which environments get high availability, which get a reduced topology, and how promotion between them is tested. |
| Execution volume and webhook traffic | Higher trigger and webhook volume pushes work into separate webhook processors and worker pools, which adds components to size, load test and monitor. | Expected peak webhook rate and execution pattern, load test scope, and the sizing assumptions behind the worker and webhook counts. |
| Database and Redis hosting model | Managed services shift patching and failover to the provider but still need connection, backup and failover testing; self-managed clusters add operational work for the client team or the partner. | Who operates PostgreSQL and Redis, the failover design for each, backup and restore tests, and which responsibilities stay with the client. |
| Number of integrations and credentials | More integrations and credentials mean more shared encryption key handling, more credential access checks and more workflows to verify after a failover test. | Count of credentials and workflows in scope, how credentials are migrated, and the test cases that prove workflows resume correctly. |
| Need for multi-main on Enterprise | Multi-main is restricted to Enterprise self-hosted deployments, so it needs a valid Enterprise license and a different design from Community failover; this is often the largest single cost decision. | Confirmation of the edition and license in writing, the number of main instances proposed, and the license cost is quoted separately by n8n. |
| Compliance evidence requirements | Assessors may expect documented failover design, test records, access reviews and change records, which adds documentation and repeated test runs. | The evidence list the assessor needs, the test frequency, and whether evidence packs are delivered in the handover. DeployOpen prepares evidence but does not issue audit reports. |
| In-house skills | Teams already running Redis, PostgreSQL and Node.js services need less onboarding; teams new to queue mode need training and more partner time during build and handover. | Skill assessment of the internal team, the knowledge transfer sessions included, and the runbooks delivered at handover. |
How the n8n high availability design changes by deployment model
A single-node Community deployment runs one main process with its own database on one host. It is the simplest topology and has the fewest components to fail over. Multi-main setup is restricted to Enterprise self-hosted deployments, so a Community design has no built-in second main instance to take over. Recovery depends on how quickly the team can rebuild the host and restore the database and the encryption key.
- Automatic failover: none is provided by the design itself. When the host or main process stops, triggers, schedules and webhooks stop with it.
- Manual recovery: rebuild the host, install the same n8n version, restore PostgreSQL and the encryption key, then start the instance and test key workflows.
- Single points of failure: the host, the database, the storage that holds the encryption key and the reverse proxy in front of the instance.
- Key backups: store the encryption key separately from database backups, because stored credentials cannot be decrypted without it.
Illustrative example: a team that restores a database backup without its matching key will have workflows that run but credentials that fail. Confirm with n8n which health check and restart behaviors apply to Community, and agree a recovery window with the business before you choose this model.
In queue mode, the main instance handles triggers and webhooks and passes executions through Redis to a pool of workers, which read and write workflow data in PostgreSQL. Running separate webhook processors keeps inbound traffic from competing with worker load. The design still has one main instance, so trigger handling and scheduling remain a single point of failure even though the workers can be replaced.
- Automatic behavior: pending executions wait in Redis for another worker to pick them up. Confirm how executions already running on a failed worker are retried or marked as failed.
- Manual recovery: if the main instance fails, triggers and scheduling stop until it is restarted or restored from backup.
- Shared encryption key: every worker and webhook processor must hold the same key as the main instance, so a key change becomes a coordinated, planned operation.
- Redis and PostgreSQL: each is a dependency that needs its own redundancy plan. This mode does not replace either service with a redundant cluster.
Illustrative example: if the team scales workers during a busy period, each new worker needs the same key and the same database and Redis settings before it joins the queue. Confirm with n8n how queue mode behaves during a main restart, and test a worker loss and a main restart in a staging environment before go-live.
Enterprise self-hosted deployments can run several main instances for high availability. The instances sit behind a load balancer and share the same PostgreSQL database, and queue mode is used when you add workers. Multi-main requires a valid n8n Enterprise License, and files with .ee in their name or directory are covered by that license, not by the Sustainable Use License. Licensing is therefore part of the architecture, not only a purchasing step.
- Automatic behavior: confirm which instance takes over trigger and scheduling duties when one main fails, and how quickly that handover completes in your setup.
- Manual steps: license activation, consistent configuration across main instances, and sequenced upgrades so that instances never run mixed versions for longer than n8n documents.
- Shared dependencies: PostgreSQL and Redis still need their own redundancy. Multiple mains do not remove the database as a single point of failure.
- Load balancer health checks: define which endpoints mark an instance as unhealthy and confirm they match n8n's documented health endpoints.
Illustrative example: if one main stops during a scheduled upgrade, the remaining instances must carry triggers without duplicate runs. Ask n8n to confirm how duplicate scheduled executions are prevented, and run a controlled failover test with production-like workflows before you rely on it.
The topology choices above still apply on Kubernetes or in an air-gapped network, but the platform changes who performs failover and how software reaches the cluster. Kubernetes can restart or reschedule containers, while an air-gapped network removes the internet path that many update, license and integration steps assume. No Kubernetes deployment details or air-gapped procedures for n8n are covered here, so each one needs confirmation with n8n before design work starts.
- Kubernetes restarts: confirm whether n8n documents a supported manifest or chart, how it handles main and worker replicas, and whether the database and Redis are expected to run inside or outside the cluster.
- Air-gapped images and packages: plan how container images, npm dependencies and n8n release packages are mirrored into the closed network and how each mirror is verified.
- License validation: confirm how Enterprise licenses are validated when the instance cannot reach external services.
- External reach: webhooks and callbacks from outside the network need a defined path, and inbound failover must be tested through that path.
Close the design by confirming each item in writing with n8n and in your own environment, including your cluster version, storage class and network policy, before you assign failover responsibilities to a platform team.
What failover looks like on the n8n Community edition
On the Community edition, failover is a restore, not a second main instance taking over. The multi-main setup, which runs several main instances for high availability, is restricted to Enterprise self-hosted deployments and is not available on Community or n8n Cloud. Your recovery plan therefore rests on three things: a current backup of the PostgreSQL database that holds workflows and execution data, a copy of the encryption key stored outside the failed host, and infrastructure that can be rebuilt quickly. Each of these must be tested. A backup nobody has restored is an assumption, and a missing encryption key leaves restored credentials unreadable.
The recovery sequence should be written as numbered steps, with one named owner per step. Start by confirming what failed and whether the database is intact. Provision a replacement host running the same n8n version recorded in the last backup, because restoring into a different version adds a variable during an incident. Restore the PostgreSQL database, then restore the encryption key from your secrets store and the environment configuration, including the database connection and public URL settings. Start the main instance, then check that you can log in to the editor and that a test credential decrypts. Only after those checks pass should you move the DNS record or load balancer target and reactivate workflows. Record when each step finishes so the post-incident review works from facts.
Expect three gaps. First, executions that were running when the host failed may be lost or left incomplete, so the team needs to know which workflows write to external systems and how to check their last completed step. Second, webhooks sent during the outage will fail unless something upstream holds them. Whether the sender retries, and for how long, is set by that sending system, so the runbook must record each sender's retry policy. Third, scheduled triggers that were due during the outage may not fire when the instance returns. Confirm how your installed version treats missed schedules in a test environment before an incident forces the question.
Design the response to these gaps before go-live. Sort workflows into three groups: those that can be safely re-run, those that need a manual check of the external system, and those that can wait until normal operation resumes. For webhook senders, pull delivery logs from the sending platform after recovery and replay only the events the workflow can process twice without harm. That requires the workflow to be idempotent or to check whether an event was already processed. Assign a named person to make these calls during an incident, and rehearse the full runbook against a copy of production data so the restore time and the gaps are visible before they cost you money or customers.
Confirm queue mode availability on your edition before you commit to a design. Queue mode, which separates the main instance from worker processes that run executions through Redis, is described in n8n's queue mode documentation, and that documentation also states the multi-main restriction. Ask n8n, or check the license terms that apply to your edition, whether queue mode and its Redis and worker components are available to you. If they are not, your failover plan stays a restore plan, and the staffing and budget discussion should reflect that. If they are, the runbook must also cover Redis and each worker, and the team must test their recovery order alongside the main instance.
How to protect the encryption key and access paths in a high availability setup
In a high availability n8n setup, the encryption key, the Redis and PostgreSQL backends and the public entry points are shared by every node, so a weakness in one place affects all of them. The cards below cover the controls that keep the cluster consistent and reachable only by the people and services that should reach it.
Share one encryption key across all nodes
Every main, worker and webhook processor must hold the same encryption key, because credentials are stored encrypted in PostgreSQL and each node decrypts them when it runs a workflow. Check that every node's configuration carries an identical key, and that a node started with a different or missing key fails cleanly instead of running with broken credentials. Confirm this check during every node addition.
Store and rotate the key under a controlled process
The key is the single secret that unlocks all stored credentials, so it should live in a secrets manager or a restricted deployment store, not in plain environment files shared by the team. Rotation is not a simple swap in high availability, because existing encrypted credentials must be re-encrypted or migrated before old nodes stop. Ask your vendor or the n8n documentation for the supported rotation procedure before you plan a change window.
Restrict Redis to internal networks
Redis carries execution jobs between the main instance and the worker pool, so anyone who can write to it can inject or read work. Bind Redis to private addresses, allow connections only from n8n main, worker and webhook nodes, and require authentication. Verify with a scan from outside the cluster network that the port is not reachable.
Restrict PostgreSQL to internal networks
PostgreSQL holds workflow definitions, execution history and the encrypted credential store, so it is the most sensitive component in the cluster. Allow connections only from the n8n nodes and any approved administration host, use per-service database accounts with the least privileges needed, and keep replicas on private networks. Confirm that failover to a standby does not open a new public path.
Terminate TLS at the load balancer
The editor, the API and webhook traffic reach the cluster through a load balancer that is shared across several main and webhook nodes. Terminate TLS there with certificates you manage, forward traffic to nodes over private addresses, and set the forwarded protocol and host headers so n8n generates correct callback URLs. Check the certificate renewal process, because an expired certificate takes down every entry point at once.
Limit who can reach webhook endpoints
Webhook processors accept requests from the internet by design, so they are the widest part of the attack surface. Expose only the webhook path on the public listener, keep the editor and API on a separate internal or access-controlled route, and apply rate limits and source filtering where your providers support it. Review which workflows use authentication on their webhook triggers.
Keep audit records of configuration changes
In a cluster, a changed setting on one node can cause inconsistent behavior that is hard to trace. Record who changed the environment variables, deployment definitions, load balancer rules and database access grants, and keep those records outside the n8n instances they describe. Ask whether the audit trail covers the Enterprise features you use, since audit log availability depends on your license and edition.
How to prove n8n failover works before go-live
Before go-live, the test plan should show that n8n survives each failure in the environment you will run, with your hostnames, load balancer, database and Redis. Stop one main instance, then one webhook processor, then one worker, one at a time, and let the system settle between each stop. After each stop, send a test request to the public webhook endpoint and confirm that it reaches a node that is still running and produces an execution record. Use a small test workflow that writes a known marker to PostgreSQL so the result can be checked in the database and in the editor. Testing one component at a time makes it possible to trace any failure to a single cause.
Queued work needs its own test. Start several executions that take long enough to still be running when you stop a worker, then confirm that each one either completes on another worker or ends in a state that your alerting reports. Count the results against what you started, because a lost or duplicated execution is a failure even when the editor looks healthy. Next, restart the Redis service and then the PostgreSQL primary or failover target. Confirm that n8n reconnects without a manual restart and that queued jobs continue. Ask your Redis and PostgreSQL operators how promotion works in your setup, and write down the expected behavior before the test starts.
Credentials are the step most often skipped. Every main, webhook processor and worker must hold the same encryption key, so run a workflow that uses a stored credential on each node type and confirm that it decrypts. A wrong key often appears only when a particular node picks up work, so force each node to execute a credentialed step rather than relying on normal traffic. Multi-main operation is limited to Enterprise self-hosted deployments, so the main-failover steps depend on your edition and topology. Confirm with your vendor or license terms which of these steps your edition and topology support before you schedule the tests.
A test fails if any webhook receives no response or a response from a stopped node, if an execution is lost or duplicated, if a credential returns an error on any node, or if recovery needs steps beyond your documented runbook. Record each test with the date, the component stopped, the times it stopped and recovered as observed, request and execution identifiers, the outcome, and the name of the person who observed it. Store logs and screenshots with the record. Re-run any failed test after the fix, and make the handover sign-off list the steps tested, the steps not supported by your edition or topology, and the reason for each exclusion.
What to monitor, back up and document after go-live
After go-live, the cluster is only as reliable as the evidence behind it. These cards cover what to watch, what to back up and what to write down so an on-call engineer can act without the original builders. Each item needs a named owner in the runbook and a check that your own monitoring stack confirms.
Node health checks
Check every main, webhook processor and worker node separately, because a healthy main instance can hide a stalled worker pool. Confirm which health endpoints your n8n version exposes and what each one returns, then point your load balancer and monitoring at them. Map each alert to a runbook entry with a named owner, so the on-call engineer knows who decides on failover and who restarts a node. Confirm these checks with your own monitoring stack before go-live.
Queue depth and backlog
In queue mode, executions wait in Redis until a worker picks them up. Track the number of waiting jobs, the age of the oldest job and the rate at which workers finish them. A rising backlog with idle workers usually points to a connection or key problem, while a rising backlog with busy workers usually points to capacity. Agree thresholds with the owners of time-sensitive workflows, and confirm how your monitoring stack reads queue metrics from Redis.
Redis, PostgreSQL and disk use
Both services are shared dependencies. If Redis stops, queued executions stall, and if PostgreSQL stops, workers cannot read the workflow data they need. Monitor reachability and failover state for each, and watch disk use on the database volume and the Redis persistence volume, since execution data grows over time. Confirm alert thresholds, execution data retention settings and failover behavior with the team that operates these services.
PostgreSQL backups and restore drills
PostgreSQL holds workflows, execution history and stored credential records, so it is the first system to restore. Document the backup schedule, retention period, backup location and who can start a restore. A backup that has never been restored is unproven, so schedule restore drills in a separate environment and record how long the restore took and whether workflows ran correctly afterward. Confirm backup tooling and point-in-time options with your database platform or DBA team.
Encryption key custody
Credentials in n8n's database are encrypted with the main instance's encryption key, and every worker and webhook processor must hold the same key to read them. Losing the key means stored credentials cannot be decrypted, even with a good database backup. Document where the key is stored, who can read it, how it reaches new nodes and how a change would be handled. Confirm the storage method against your secrets management policy and keep a controlled copy in a location the restore runbook names.
Upgrade testing across all nodes
n8n ships minor releases roughly weekly and occasionally publishes breaking major versions, so every node in the cluster should run the same version after each change. Test the upgrade on a staging copy with the same queue mode topology, the same number of workers and a representative set of workflows before touching production. Record the rollout order for main, webhook processor and worker nodes, along with the rollback step, including a database restore if a migration cannot be reversed. Read the release notes for each target version before scheduling.
How much does n8n high availability cost and who needs to be involved
Is multi-main high availability available on the n8n Community edition?
No. n8n's multi-main setup, which runs several main instances for high availability, is restricted to Enterprise self-hosted deployments and is not available in the Community edition or n8n Cloud. A Community deployment therefore cannot follow the multi-main pattern, so the plan has to start from that limit. The alternative is to build redundancy around a single main instance: keep the main instance easy to rebuild through infrastructure automation, run workers and webhook processors as separate pools that can be replaced or scaled, place PostgreSQL and Redis on services with their own replication, and back up the database and the encryption key so the main instance can be restored on standby hardware. Confirm with n8n's current license terms and documentation which queue mode features your edition includes, and agree in writing what recovery time your team can accept.
What drives the cost of n8n high availability?
The main cost drivers are the license, infrastructure, data services, testing and operator time. The license is the most variable line for Enterprise designs, because n8n lists Enterprise at custom pricing for self-hosted or cloud, so ask for a quote tied to your deployment. As a reference point, n8n's pricing page lists its Business plan at 667 euros per month billed annually, self-hosted only, and that plan includes SSO but not multi-main. Infrastructure covers main instances, the worker pool, webhook processors, the load balancer, PostgreSQL and Redis, and it recurs every month. Build-time testing and failover drills are one-time costs that repeat after major changes. Operator time covers patching, upgrades and on-call. Costs rise with worker count, execution history in PostgreSQL and the number of availability zones, and they fall when you reuse managed services your team already runs.
How long does n8n high availability work usually take?
The duration depends on scope more than on the n8n version. A design limited to queue mode with separate webhook processors, one PostgreSQL database and one Redis instance is a smaller job than a multi-main Enterprise build that also covers load balancing, managed database failover, monitoring and tested failover drills. Other drivers include the number of environments (staging and production at minimum), whether your team already operates Redis and PostgreSQL clusters, how many workflows must be verified after a failover, and how quickly security and network approvals arrive. DeployOpen does not publish a standard timeline. A written scope sets the phases, deliverables and dates, and the quote should show which phases depend on your approvals or access. Ask for the timeline per phase so you can see where waiting time sits.
What does our team have to provide for n8n high availability work?
Expect to provide access, environments, named owners and change windows before the build starts. Access means cloud or data center accounts, Kubernetes or virtual machine access, DNS and certificate control, a secrets store, and read access to identity systems if SSO is in scope. Environments should include at least a non-production copy close enough to production to test a failover. Name an owner for infrastructure, one for PostgreSQL and Redis, one for identity, and one business approver for workflows that touch payments, customer data or regulated records. Change windows matter because moving the main instance, rotating the encryption key or cutting over the database usually needs a planned maintenance period. Agree who approves changes and how quickly, and write those commitments into the scope so delays are visible.
Can an in-house platform team build n8n high availability alone?
Often yes, if the team already runs the underlying pieces and has time to own the design. The work spans n8n configuration, queue mode and worker setup, PostgreSQL and Redis operation, load balancing, TLS, backups, monitoring and failover testing. Check for these skills: container or virtual machine operations in your environment, PostgreSQL backup and restore, Redis replication or an equivalent managed service, reverse proxy and health check configuration, and secure handling of the shared encryption key. Also check capacity. The build needs time to test workflows end to end, including a failover drill, and that is often where gaps appear. Teams with gaps can close them through training, or bring in a partner for the missing skill or for an independent review of the design, scoped separately.
What should a fixed-scope quote for n8n high availability include?
A fixed-scope quote should state the edition and license assumption, the target architecture and every component in scope. Ask for the n8n edition and whether multi-main is in scope, since that requires an Enterprise license. Also ask for the list of hosts, services, the PostgreSQL and Redis deployment model, the load balancer, and the number of environments. The quote should name the failover tests, their pass criteria, the handover package (runbooks, dashboards and alert rules), the client responsibilities and approval points, and the assumptions about access and change windows. Ask which costs are one-time and which recur, such as infrastructure, license renewals and post-go-live support, and what happens if scope changes. DeployOpen plans and implements inside the client's own infrastructure and agrees fixed scopes in writing before work starts, so the quote should follow directly from that written scope.
Does the Sustainable Use License allow running n8n for our own business?
Yes, for your own internal business purposes. The Sustainable Use License permits use or modification for internal business purposes and for non-commercial or personal use, but distribution is allowed only free of charge and for non-commercial purposes. This matters for high availability because a design that serves customers outside your organization, or that you offer to third parties as a service, needs a legal review before the build is fixed. Files with .ee in their name or directory are not covered by the Sustainable Use License and require a valid n8n Enterprise License, so a multi-main or other Enterprise build must be checked against those paths. DeployOpen does not give legal advice on license terms, so ask your counsel to confirm how your intended use fits the license text.
How DeployOpen scopes, builds and hands over n8n high availability
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For n8n high availability, that means agreeing the topology and edition first, then building and testing it in your environment before handover. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Confirm the n8n edition first, since multi-main requires a self-hosted Enterprise license
- Map which components need redundancy: main instances, webhook processors, workers, Redis and PostgreSQL
- Written scope states the uptime design, the failover tests and what the Community edition option will not include
How we build
- Stand up the main, webhook and worker processes behind a load balancer with health checks
- Share the encryption key with every worker and webhook processor so credentials decrypt on each node
- Test failover by stopping each node in turn and recording whether executions resume
How we hand over
- Runbook covering node restart order, Redis and PostgreSQL recovery, and key rotation steps
- Documented test results showing which failures keep workflows running and which stop them
- Walkthrough with your operations team covering alerts, backups and escalation paths
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after go-live
- Retest the cluster after each n8n minor release before rolling changes to production
- Ask n8n which support terms, including any SLA, apply to your edition and plan
