How to back up n8n workflows?

The safest and most reliable way to back up n8n workflows is to back up the entire n8n data directory (often called .n8n) or, if you're using a database, back up the database itself. These locations contain every workflow, every credential, every execution, and all n8n settings. You can also export workflows manually from the UI, but that should be treated as a secondary/one‑off method, not a real backup strategy.

 

Two Real Production‑Safe Backup Methods

 

You really have only two proper sources of truth for backups:

• File‑system backup when n8n uses the default SQLite mode.
• Database backup when using Postgres/MySQL (recommended for production).

Everything else (like manually exporting JSON from the UI) is fine for quick copies but not reliable for restoring a full n8n installation.

 

1. Backing up n8n when using SQLite (default install)

 

In this mode n8n stores everything inside a folder called .n8n. If you're running via Docker, that folder is usually mounted as a volume. This folder contains:

• database.sqlite — all workflows, credentials, tags, execution data
• config files
• binaryData folder if you store files inside executions

You simply copy this folder somewhere safe. That’s your backup.

A simple shell example:

// Backup the whole .n8n directory to a dated folder
cp -r /path/to/.n8n /backups/n8n-$(date +%F)/

To restore, you put the folder back in place and restart n8n. That’s it.

Important production note:
Make this copy while n8n is not actively writing (or stop the container briefly). SQLite is a single-file DB, and copying it during writes can corrupt backups.

 

2. Backing up n8n when using Postgres or MySQL (recommended in production)

 

In a more mature setup, the n8n application container is stateless and all workflow/credential/execution data lives entirely in the database. So the backup is simply your DB backup.

• Postgres example

// Dump the entire n8n database
pg_dump -U n8n_user -h localhost n8n_db > n8n_backup.sql

• MySQL example

// Dump MySQL/MariaDB n8n database
mysqldump -u n8n_user -p n8n_db > n8n_backup.sql

To restore, load that dump into a clean database and point your n8n instance to it.

If you have binaryData set to filesystem mode (not DB mode), also back up the folder you mapped for it.

 

3. Optional: Exporting workflows manually from the UI

 

This is okay for a one‑off copy or sharing a workflow with someone, but it is not a real backup strategy. It exports only the workflow JSON — not credentials, not tags, not execution data, not settings.

• You can click into a workflow.
• Open its menu (top-right).
• Select Download or Export.

Use this only as a convenience, not for disaster recovery.

 

4. Where people often get confused

 

• Backing up the Docker image is meaningless. All data lives outside the image.
• Environment variables (like webhook URLs, queue settings, etc.) must be backed up separately, usually in your compose file or env file.
• Credentials are stored encrypted in the DB. You don’t need to decrypt them to back them up — just back up the DB or .n8n folder.
• Restoring a workflow JSON file will not restore the credentials it needs. Only DB or .n8n restores credentials.

 

5. What a healthy production backup strategy looks like

 

• File-based n8n (SQLite): daily backup of the entire .n8n directory.
• Database n8n (Postgres/MySQL): daily DB dump + folder backup for binaryData (if used).
• Keep your docker-compose.yml or env file in git so you can recreate the environment.
• Test restoration at least once — many teams never test and discover corruption too late.

 

If you follow these steps, your n8n installation becomes fully recoverable: workflows, credentials, executions, settings, everything. That's the same approach teams use in real production deployments.