Hi everyone
I’m running a multi-tenant automation platform built on n8n and trying to design a solid disaster recovery (DR) strategy before scaling further.
Current architecture:Load Balancer
↓
n8n Workers
↓
PostgreSQL + Redis + Object Storage
My concerns are:
Database failure
Redis failure
Worker/node outages
Cloud region outages
Accidental data deletion
Failed deployments
I’m trying to:
Recovery Point Objective (RPO)
Recovery Time Objective (RTO)
Backup frequency
Failover strategy
I’m also considering:
Automated PostgreSQL backups
Redis persistence/replication
Multi-region object storage
Infrastructure as Code (Terraform)
Blue/green deployments
Describe the problem/error/question
What does your DR architecture look like?
Which components are the most critical to protect?
How often do you test recovery procedures?
What is the error message (if any)?
Please share your workflow
(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)
adding to @Niffzy points, the encryption key is your single point of total failure. n8n encrypts all credentials in Postgres using the N8N_ENCRYPTION_KEY. If that key is lost while your Postgres backup is intact, every credential in every tenant’s workflows becomes permanently unreadable, restoring the DB does nothing. Back this key up separately (e.g. in a secrets manager), independent of your DB backup pipeline.
Redis in queue mode is mostly disposable, but check your settings. If you’re running queue mode, Redis holds in-flight job state. As long as EXECUTIONS_DATA_SAVE_ON_ settings write to Postgres, losing Redis loses queued/in-progress jobs but not historical execution data, so Redis can usually be “Important” rather than “Highest priority” as long as you accept some in-flight executions failing.
For n8n-specific DR with your queue mode setup, the critical pieces are:
PostgreSQL: Use streaming replication with a standby replica and automate pg_dump to object storage on a cron (15-30 min interval gets you to a reasonable RPO). n8n’s execution data is the most volatile - workflows and credentials change less often.
Redis: If Redis goes down, n8n workers will fail to pick up new jobs but running executions won’t lose data (they’re checkpointed in PG). Use Redis Sentinel or Cluster for HA - single Redis is the most common failure point I see in these setups.
Workers: Run at least 2 workers behind the LB. When one goes down, the other keeps picking from the queue automatically.
For region failover: pre-warm a standby n8n instance pointed at a replica PG. RTO comes down to how fast DNS or LB can switch, not how fast the app starts.
Stanleyy’s encryption key point is the one to take most seriously. Just to add one concrete thing on top of it: back it up somewhere independent of the database, not in the same S3 bucket or the same backup job. If those end up together and someone gets access to both, every credential in your system is readable. A secrets manager like AWS Secrets Manager or Vault is the right home for it.
The thing I’d do before touching backup tooling is decide on your RPO and RTO numbers, because they change the answer completely. If a 24-hour RPO is acceptable, nightly snapshots are fine. If it isn’t, you need WAL archiving or streaming replication to get that window down to minutes, and that’s a different infrastructure conversation. Most teams skip this step and end up with backups that don’t actually meet their SLA.
On Redis specifically: in queue mode Redis is your job broker, not just a cache. n8n passes execution IDs to workers through it, so if Redis goes down, in-flight executions are dropped and workers go idle until it recovers. Sentinel or a managed Redis with automatic failover is worth adding to your DR plan separately from the database.