Disaster recovery for self-hosted n8n starts by separating cattle from memory. The instance — binary, Docker image, config — rebuilds in minutes. Three things don't: workflow definitions, encrypted credentials, and the encryption key that unlocks them. Lose all three in one fire and the rebuild isn't recovery; it's starting over with experience.
What an export covers — and the paradox it hides
CLI exports produce JSON of workflow structures: perfect for version history and Git-based backup. But exports frequently carry secrets — hardcoded tokens in node parameters, auth headers, TODO jottings. The file that's your safety net becomes a live liability the moment it lands in a repository, Slack paste, or migration zip. Structure is safe to travel; secrets are not.
The two-item backup contract
Item one: automated, nightly, versioned workflow exports — with secret-scrubbing as a mandatory pipeline step, not an intention. Item two: the database plus N8N_ENCRYPTION_KEY, via your infra provider's snapshot tooling, stored somewhere the exports aren't. Two locations minimum: key and data together in one fire is the difference between "encrypted" and "gone".
The restore drill nobody runs (run it)
Quarterly, minimum: fresh n8n on staging, feed it the backup database and key, import workflows, light one real execution end-to-end. Time it — that's your true recovery time. Drills find the realistic failures: rotated keys, format drift across upgrades, OAuth callbacks pointing at the old domain.
The discipline that costs one cron line
Backup jobs die too — disks fill, tokens expire. Heartbeat-ping your export job's completion and let silence alert you, so you learn the backup died today, not during an actual restore. And before the next deploy lands in the backup stream: scrub the export through the free n8n workflow audit — secret patterns, localhost URLs, broken references — browser-only, nothing uploaded.
A backup you restored last quarter is the only backup that exists.
Top comments (0)