Editorial basis: This n8n backup and restore guide summarizes official n8n self-hosting documentation. It has not been used to restore a live production installation. Validate the procedure for your deployment and version before relying on it.
A reliable n8n backup and restore plan must protect more than workflow definitions. A self-hosted instance may depend on a database, encrypted credentials, a persistent encryption key, execution records, external binary files and environment configuration. Exporting workflow JSON files is useful, but it is not by itself a complete disaster-recovery backup.
Understand the layers of an n8n deployment
Before choosing a backup tool, document where the n8n instance stores its database, encryption key, configuration, workflows and binary data. A small Docker installation may keep important application state in a persistent mounted volume. A larger deployment may use an external PostgreSQL database and additional storage services.
The correct backup procedure depends on your architecture. Copying a container image is not the same as backing up its persistent state, and backing up a database alone may omit external binary files or configuration needed for a functioning restore.
Workflow exports versus full instance backups
Workflow JSON exports capture definitions and are useful for migration, version control or selective recovery. They do not guarantee restoration of all credential secrets, users, project permissions, execution history or instance configuration. Be careful when sharing exported JSON: it may contain node settings, endpoints and sensitive operational details even if encrypted credential values are not embedded.
For selective migration, see the n8n Workflow JSON Import and Export guide. For disaster recovery, plan to restore the supporting state as well.
Preserve the encryption key
n8n encrypts credentials using an encryption key associated with the instance. If a new installation does not have access to the correct key for the restored data, existing encrypted credentials may be unreadable. Identify how the key is managed in your deployment, back it up securely and restrict access to a small set of authorized administrators.
Do not paste the encryption key into a chat, public ticket, repository or article screenshot. Store it in an approved secret-management or secure backup process separate from ordinary workflow exports.
Plan database-consistent backups
Determine whether the n8n database is SQLite or PostgreSQL and use a backup method appropriate to that engine. For PostgreSQL, use a documented database backup and restore procedure with the correct permissions and recovery scope. For SQLite, ensure the captured state is consistent rather than copying files at an unsafe moment while writes are in progress.
Test database recovery into an isolated environment, not directly on the production instance. Keep enough information to recreate database connectivity and configuration without exposing passwords in ordinary documentation.
Include binary data and storage volumes
Some workflows handle PDFs, images and other binary attachments. Depending on your n8n deployment and settings, binary data may be stored in a filesystem or another supported location. If that data is required for recovery, the backup scope must include it. Inspect the active storage configuration rather than assuming all files live inside the main database.
Document volume mounts, object-storage locations and retention policies. Restoring the database while forgetting required binary storage can leave a workflow with missing files or broken execution references.
Create a backup checklist
- Inventory the n8n version, deployment type, database engine and persistent volume locations.
- Identify the encryption key and store a protected recovery copy according to the organization’s secrets policy.
- Back up the database using its supported consistency procedure.
- Back up any required persistent files, binary-data storage and configuration managed outside the database.
- Export workflows for additional selective-recovery options, checking them for sensitive settings before sharing.
- Protect backups with encryption, access controls and a retention schedule.
- Record a restore procedure, the recovery owner and the last successful restore-test date.
Do not call a backup “verified” merely because a scheduled archive command exited successfully. Restore it and test representative workflows in an isolated environment.
Worked example: Docker Compose recovery plan
Imagine an n8n instance run with Docker Compose and persistent storage. Document the Compose file, the environment-variable sources, persistent mounted paths and database configuration. Create a backup of the supported application state and preserve the encryption key securely. Then deploy a separate test stack at a non-public address and restore the state into it.
Check that expected workflows exist, encrypted credentials can be read and harmless test executions succeed. Never accidentally activate scheduled jobs or live webhooks in the recovery environment: they could send real messages or double-process external orders. The n8n Docker Compose Setup guide discusses persistent storage and reverse-proxy architecture.
Version compatibility and migrations
Do not assume that a backup from one n8n version can be restored into any other version. Review the official upgrade and migration notes, database schema expectations and supported rollback procedures. Where necessary, restore into a version-compatible environment before upgrading in controlled stages.
Keep copies of installation configuration and version metadata alongside the backup inventory. A successful database import can still produce broken workflows if required community nodes or credentials are missing.
Recovery point and recovery time objectives
Decide how much data loss is acceptable and how quickly service needs to return. These correspond to recovery point and recovery time objectives. An internal hobby workflow may tolerate a day of lost state, while a production order-processing workflow may need much more frequent backups and a tested standby plan.
Backup frequency should reflect actual business impact and data change rate, not simply a generic “once per week” recommendation. Record the expected restoration dependencies and the staff member responsible.
Security and offsite storage
Store at least one protected backup independently of the live server or account where appropriate. Otherwise, a server compromise can destroy both the primary data and its only backup. Restrict backup access, rotate storage credentials and monitor failed jobs. A backup may contain encrypted customer credentials and operational data that still require careful handling.
Do not expose administrative backups via a publicly accessible WordPress upload directory or web path. Verify storage permissions and object-store visibility before enabling automated uploads.
Common restore problems
- Credentials cannot decrypt: verify the correct n8n encryption key.
- Workflows missing: confirm the database and account/project state that was restored.
- Binary files missing: inspect the filesystem or external binary store backup.
- Old database incompatible: review n8n and database version requirements.
- Duplicate external actions: disable triggers during isolated restoration tests.
- Backup file corrupt: test archive integrity and perform a full restore drill.
Frequently asked questions
Is exporting workflow JSON enough for disaster recovery?
No. It is valuable for selective workflow recovery but may not include credentials, user permissions, database state and required binary data.
Why is the encryption key important?
Restored encrypted credentials depend on access to the correct key. Preserve it securely as part of the recovery plan.
How do I verify a backup works?
Restore into an isolated environment, inspect expected state and run harmless representative tests without triggering production side effects.
Official references
- Official n8n Docker hosting documentation
- n8n Docker Compose setup
- n8n Docker Compose Setup Guide
- Import and Export n8n Workflow JSON
Documentation checked October 2026. Test backup and restore against the actual environment and installed n8n version before relying on this procedure.