How to Back Up and Restore n8n: Workflows, Credentials, and the One Key You Cannot Lose

If you self-host n8n, your automation platform is only as durable as your last good backup. A proper n8n backup covers three things: the database that stores your workflows and execution data, the encryption key that protects your credentials, and, optionally, exported JSON copies of the workflows themselves. Miss any one of these, and a server failure can turn into days of rebuilding integrations by hand. Miss the encryption key, and no amount of database restores will bring your credentials back.

This guide walks through exactly what to back up, the commands to do it, how to restore n8n workflows and credentials onto a fresh server, and how to prove your backups actually work before you ever need them.

What an n8n Backup Actually Needs to Include

n8n stores almost everything in its database. By default that is a SQLite file inside the /home/node/.n8n directory of the container. If you followed a production docker compose setup, you are more likely running Postgres, in which case the database lives in your Postgres service instead.

Here is the full inventory of what matters:

1. The database. Workflows, credentials (encrypted), execution history, tags, user accounts, and settings all live here. This is the core of any n8n backup.
2. The encryption key (N8N_ENCRYPTION_KEY). Every credential you save in n8n is AES-encrypted with this key. If you did not set it yourself as an environment variable, n8n auto-generated one and wrote it into the config file inside the .n8n directory. More on why this is the single most important item below.
3. Exported workflow and credential JSON (optional but recommended). These give you portable, human-readable copies you can version in git, diff between environments, or import selectively.

Binary files, custom nodes, and community node installations can usually be reinstalled from configuration, but if you have customized heavily, note those down too.

The Encryption Key: The One Thing You Cannot Recreate

This deserves its own section because it is the most common way people permanently lose data with n8n.

Credentials in n8n are never stored in plain text. They are AES-encrypted using N8N_ENCRYPTION_KEY. When you restore a database onto a new instance, n8n needs the exact same key to decrypt those credentials. A restored database without the matching key means every stored credential is unrecoverable. Your workflows will import fine, your execution history will be intact, and every single API connection will be dead.

There are two scenarios:

• You set the key explicitly. If your compose file or environment sets N8N_ENCRYPTION_KEY, copy that value into your password manager right now. Treat it like a root password.
• You never set it. n8n generated a key on first startup and saved it in the config file inside /home/node/.n8n. Backing up the data directory captures it, but you should still extract the value and store it separately, because a backup that only exists on the same disk as the original is not much of a backup.

Write the key down somewhere that survives the server. Everything else in this guide is recoverable through effort. The key is not.

Backing Up the Data Directory (SQLite and Config)

If you run n8n with the default SQLite database in a Docker named volume, the simplest complete backup is an archive of that volume. Pause writes first: stop the container, or at minimum make sure no heavy workflow executions are mid-flight, so you do not snapshot a database in an inconsistent state.

docker stop n8n
docker run --rm -v n8n_data:/data -v $(pwd):/backup alpine tar czf /backup/n8n-data.tgz /data
docker start n8n

This produces n8n-data.tgz in your current directory, containing the SQLite database, the config file with the auto-generated encryption key, and everything else n8n keeps in its home directory. For most small and mid-size installs, this single archive plus a separately stored copy of the encryption key is a complete n8n backup.

Backing Up Postgres

If your instance uses Postgres, back up the database with pg_dump instead of archiving files. From the host, run it inside the Postgres container:

docker exec -t postgres pg_dump -U n8n n8n > n8n.sql

Adjust the container name, user, and database name to match your setup. The generic form is:

pg_dump -U <user> <db> > n8n.sql

pg_dump takes a consistent snapshot, so you do not need to stop n8n for this. You should still archive the n8n data directory occasionally, because the config file (and possibly your encryption key) lives there, not in Postgres.

Exporting Workflows and Credentials as JSON

The n8n CLI can export everything to JSON. Run these inside the n8n container:

docker exec -it n8n n8n export:workflow --all --output=/backup/workflows.json
docker exec -it n8n n8n export:credentials --all --output=/backup/credentials.json

Then copy the files out with docker cp, or mount a host directory at /backup so they land on the host directly.

Two important notes:

• The credentials export is encrypted by default, using the same N8N_ENCRYPTION_KEY. That means the JSON file is safe-ish at rest, but also that importing it on another instance requires the matching key, exactly like a database restore.
• A --decrypted flag exists for export:credentials. It writes your API keys and passwords in plain text. Only use it when you have a specific reason, store the output somewhere strongly protected, and delete it as soon as you are done. Treat a decrypted export like a file full of live passwords, because that is what it is.

Workflow JSON exports are great candidates for a private git repository. You get history, diffs, and an extra recovery path that is independent of your database backups.

How to Restore n8n on a Fresh Server

A restore is where preparation pays off. The sequence matters, so follow it in order.

Step 1: Provision a fresh n8n instance. Spin up n8n the same way you originally deployed it. If you need a refresher, see our guide on how to self-host n8n.

Step 2: Set the same encryption key before first real use. In your compose file or environment, set N8N_ENCRYPTION_KEY to the exact value from the original instance. Do this before importing anything.

Step 3: Restore the data. For a SQLite volume backup, stop the new container and unpack the archive into the volume:

docker stop n8n
docker run --rm -v n8n_data:/data -v $(pwd):/backup alpine sh -c "cd / && tar xzf /backup/n8n-data.tgz"
docker start n8n

For Postgres, load the dump into the new database:

cat n8n.sql | docker exec -i postgres psql -U n8n -d n8n

If you are restoring from JSON exports instead, use the import counterparts:

docker exec -it n8n n8n import:workflow --input=/backup/workflows.json
docker exec -it n8n n8n import:credentials --input=/backup/credentials.json

Step 4: Verify with a real credentialed workflow. Open the UI, pick a workflow that uses a stored credential (a Slack message, a Google Sheets append, anything that talks to an external API), and run it. If it executes successfully, your credentials decrypted correctly and the restore is genuinely complete. If credentials fail to decrypt, the key does not match; stop and find the correct key before doing anything else.

Automate It, and Test It

An untested backup is not a backup. It is a hope. Two habits turn the commands above into an actual disaster recovery plan.

Automate with cron on the host. Wrap your backup commands in a small script and schedule it:

0 3 * * * /opt/scripts/n8n-backup.sh

Inside the script: dump the database (or archive the volume), timestamp the file, and push it off the server to object storage such as S3, Backblaze B2, or similar. A backup sitting on the same disk as the data it protects will die in the same disk failure. Retain multiple generations, at least a week of dailies, so a corrupted backup or a mistake you only notice days later is still recoverable.

Run a restore drill. Once a quarter, restore your latest backup to a throwaway container, set the key, and run a credentialed workflow. Fifteen minutes of drill converts "we think we have backups" into "we know our recovery works, and it takes N minutes."

If you would rather not own this responsibility at all, Hosto managed n8n includes daily automated backups on dedicated VMs, starting from $9/mo billed annually, so the schedule, the off-server copies, and the retention are handled for you.

FAQ

Where does n8n store its data by default?

In the /home/node/.n8n directory inside the container, which includes the SQLite database and the config file. In Docker deployments this is normally mapped to a named volume such as n8n_data. If you configured Postgres, workflow and credential data lives in the Postgres database instead, but the config file remains in the .n8n directory.

I restored my database but all my credentials are broken. What happened?

Your new instance is running with a different N8N_ENCRYPTION_KEY than the one that encrypted the credentials. The workflows restore fine because they are not encrypted, but credential decryption fails. Find the original key (check the old environment configuration or the config file inside the old .n8n directory), set it on the new instance, and restart. If the original key is truly gone, the stored credentials cannot be recovered and must be re-entered by hand.

Do I need to stop n8n to take a backup?

For SQLite volume archives, yes, stopping the container (or at least pausing writes) is the safe approach, since copying a live SQLite file risks an inconsistent snapshot. For Postgres, pg_dump produces a consistent snapshot on its own, so n8n can keep running.

How often should I back up n8n?

Daily is a sensible baseline for most teams, scheduled via cron during low-traffic hours, with copies shipped off the server and several generations retained. If you edit workflows heavily, add an export of workflow JSON to git as part of your change process. Managed options like Hosto handle daily backups automatically if you prefer not to maintain the pipeline yourself.