Backing up n8n workflows and credentials properly

You have spent hours building n8n workflows that move leads between CRM and email, process Stripe webhooks, and post Slack alerts every time a deal closes. Losing that logic because you did not back up the encryption key is the kind of pain you only feel once. An n8n instance without a credential backup is effectively a black box, you still have the nodes, but the API keys, database usernames, and OAuth tokens are gone. This guide walks through what you actually need to save, how to automate it, and, most importantly, how to prove the restore works before you need it.

• Key takeaways
• Export workflows via the n8n CLI with n8n export:workflow --all; never rely on copying the database alone.
• Credentials are encrypted with a key stored in N8N_ENCRYPTION_KEY. Without it, a full database dump is useless for restoring credentials.
• Test the restore on a separate VPS or Docker container before you trust it.
• Automate the full backup, workflows, credentials, database, encryption key, with a single cron job.

备份n8n要同时保存加密密钥、数据库和凭据，并演练恢复。

Backing up n8n means keeping the encryption key, the database and the credentials, then testing a restore.

Prerequisites

• An n8n instance running on a Linux VPS (Ubuntu 24.04 or Debian 12 recommended).
• Root or sudo access to the server.
• n8n installed via npm, Docker, or the official deployment script.
• Access to the environment file (.env) or Docker Compose file where N8N_ENCRYPTION_KEY is set.

Why the encryption key is the single point of failure

n8n encrypts every credential, API tokens, database passwords, OAuth secrets, before storing them. The encryption is AES-256-GCM, and the key is the N8N_ENCRYPTION_KEY environment variable. If you lose that key, the credential records in the database are mathematically unrecoverable. You can still restore workflow logic from a database dump, but every credential node will be red.

I once migrated an n8n instance to a new VPS, dumped the SQLite file, copied it over, and saw all credential fields blank. The .env file had been regenerated during the Docker Compose redeploy, so the encryption key was different. Lesson learned: the encryption key is the crown jewel of an n8n backup. Store it in a password manager, a separate encrypted file, or a vault, do not let it live only inside the running container.

Backing up workflows with the n8n CLI

n8n ships with a built-in n8n command-line interface that can export all workflows to JSON files. This is the cleanest method because it gives you readable, version-control-friendly files rather than raw database rows.

# Export all workflows to a folder
mkdir -p ~/n8n-backups/workflows
cd ~/n8n-backups/workflows
n8n export:workflow --all --output=.

Each workflow becomes a JSON file named by its ID. The export includes the complete node graph, connections, and any plain-text settings. Credential references appear as IDs that point to database records, not the secrets themselves, that is why you also need to back up the credential database and encryption key.

Verify:

ls ~/n8n-backups/workflows | head -5
cat .json | jq '.name'

If jq is not installed, run apt install jq -y. The command should print the workflow name for each file.

Backing up credentials

Credentials are trickier. The CLI exports them, but the output is still encrypted with the same N8N_ENCRYPTION_KEY. Exporting them is still useful, you have a portable copy that can be re-imported into a new instance as long as you also carry over the encryption key.

mkdir -p ~/n8n-backups/credentials
n8n export:credentials --all --output=~/n8n-backups/credentials/

Verify:

ls ~/n8n-backups/credentials | wc -l

Compare the count against the number of credential entries in the n8n UI settings page. If the numbers match, the export is complete.

Database dump: SQLite vs PostgreSQL

n8n supports both SQLite (default) and PostgreSQL. The backup approach differs by database type.

SQLite

If you run n8n with the default SQLite backend, the database is a single file, typically ~/.n8n/database.sqlite (npm install) or inside the Docker volume at /root/.n8n/database.sqlite (rootless Docker). You can copy it directly, but the safest method is to first stop n8n or use the SQLite command-line tool to create a consistent snapshot.

# Locate the database file
find / -name "database.sqlite" -type f 2>/dev/null

# Create a backup with sqlite3
sqlite3 /path/to/database.sqlite ".backup ~/n8n-backups/database.sqlite.bak"

This avoids corruption if the file is in use. The .backup command locks the database briefly, much cleaner than a raw cp.

PostgreSQL

For production deployments with PostgreSQL, use pg_dump. n8n stores everything in a single database (default n8n).

pg_dump -h localhost -U n8n_user -Fc n8n > ~/n8n-backups/n8n_db.dump

The -Fc flag produces a compressed custom format that is faster to restore and smaller on disk.

Verify the dump:

pg_restore --list ~/n8n-backups/n8n_db.dump | head -10

You should see a list of tables and sequences. Empty output means the dump likely failed.

Saving the encryption key and environment file

Back up the entire .env file or at minimum the N8N_ENCRYPTION_KEY value. Keep it outside the same location where you store the database dumps, if your backup server is compromised, you do not want the key sitting next to the encrypted data.

# Save the encryption key separately
grep N8N_ENCRYPTION_KEY /path/to/.env > ~/n8n-backups/encryption_key.env

# Set restrictive permissions
chmod 600 ~/n8n-backups/encryption_key.env

Store this file in a password manager or encrypted cloud storage. I keep a copy in Bitwarden and another on a separate encrypted USB drive. Do not rely on the same VPS that hosts n8n for long-term storage of the key, if the disk fails, both the instance and its rescue key disappear together.

Test the restore before you need it

A backup that has never been restored is not a backup, it is a wish. Spin up a second VPS or a local Docker container to simulate disaster recovery.

Restore workflows from CLI export

n8n import:workflow --input=/path/to/backup/workflows/

Restore credentials

n8n import:credentials --input=/path/to/backup/credentials/

Restore SQLite database (full restore)

# Stop n8n, replace the database file, restart
systemctl stop n8n
cp ~/n8n-backups/database.sqlite.bak ~/.n8n/database.sqlite
systemctl start n8n

Restore PostgreSQL database

pg_restore -h localhost -U n8n_user -d n8n --clean --create ~/n8n-backups/n8n_db.dump

Verify the restore:

• Log into the n8n UI and check that all workflows appear in the dashboard.
• Open a workflow that uses credentials, if the credential nodes show green checkmarks, the encryption key matched. Red indicators mean the key is wrong or missing.
• Run a test execution on a non-destructive workflow (for example, one that sends a debug message to a test Slack channel).

Automate with a cron job

Manual backups get skipped. Set up a cron job to run the full backup suite daily.

0 2 * * * /usr/local/bin/n8n-backup.sh

Here is a sample script that bundles everything. Adjust paths to match your setup.

#!/bin/bash
BACKUP_DIR="/var/backups/n8n"
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
DB_TYPE="sqlite"  # or "postgres"

mkdir -p $BACKUP_DIR/$TIMESTAMP

# Export workflows and credentials
cd $BACKUP_DIR/$TIMESTAMP
n8n export:workflow --all --output=.
n8n export:credentials --all --output=.

# Database dump
if [ "$DB_TYPE" == "sqlite" ]; then
    sqlite3 ~/.n8n/database.sqlite ".backup $BACKUP_DIR/$TIMESTAMP/database.sqlite.bak"
else
    pg_dump -h localhost -U n8n_user -Fc n8n > $BACKUP_DIR/$TIMESTAMP/n8n_db.dump
fi

# Save encryption key
grep N8N_ENCRYPTION_KEY ~/.n8n/.env > $BACKUP_DIR/$TIMESTAMP/encryption_key.env
chmod 600 $BACKUP_DIR/$TIMESTAMP/encryption_key.env

# Remove backups older than 30 days
find $BACKUP_DIR -type d -mtime +30 -exec rm -rf {} \;

Make it executable with chmod +x /usr/local/bin/n8n-backup.sh. Test it once manually before relying on the cron schedule. If you run n8n inside Docker, run the n8n CLI commands from within the container (docker exec -t n8n n8n export:workflow --all), and mount the backup directory as a volume so the exports land on the host.

FAQ

Related articles

• Self-hosting n8n for workflow automation on a VPS
• Running n8n 24/7 without Docker knowledge
• n8n on a dedicated IP, why webhook reliability depends on it

If you are running n8n in production, you might want a VPS with n8n preinstalled on NVMe storage with a dedicated Vietnam IPv4, so your webhooks and API calls stay within domestic infrastructure for lower latency.