Home / Blog / Business Applications and Automation / How to Back Up and Restore n8n Workflows and Credentials
n8n is the kind of tool that quietly becomes load-bearing. One week it sends a few notifications; a few months later it runs your order confirmations, your CRM sync, and your invoicing reminders. If the server fails, or an upgrade goes wrong, rebuilding those workflows from memory is slow and error-prone. A backup routine is the difference between a bad afternoon and a lost week.
The complication is that n8n does not store everything in one place. Workflows, credentials, execution history, and the encryption key that protects your credentials each live in different places, and each backup method covers a different subset. This guide explains what to back up, how to do it, and how to prove a restore works before you actually need one.
Before choosing a method, understand the four pieces:
N8N_ENCRYPTION_KEY). Without the original key, encrypted credentials cannot be decrypted. There is no reset mechanism and no support ticket that can recover them. Losing this key means re-entering every credential by hand, including redoing every OAuth consent flow.A workflow export alone is not a backup. It is a useful starting point, but it will not restore your credentials, your history, or your users.
For a single workflow, the simplest route is the editor itself. Open the workflow, use the menu in the top-right corner, and choose Download. n8n saves a JSON file containing the complete workflow: every node, its parameters, the connections between nodes, and references to the credentials it uses.
What it does not contain is the credential secrets themselves. The JSON carries credential names and IDs, not the API keys. If you import that file into a fresh instance, the workflow will appear complete but will fail at runtime until you re-link each credential. That is expected behaviour, not a bug — but it catches many people out during a migration.
Use editor exports for single workflows, not as your only backup.
For a full set of workflows and credentials, the command-line interface is the right tool. The CLI can export everything at once, which is what you want for scheduled backups and migrations.
Export all workflows:
n8n export:workflow --all --output=workflows.json
Export all credentials (still encrypted with your key):
n8n export:credentials --all --output=credentials.json
For a cleaner backup layout, use the --backup flag, which exports each workflow and credential as a separate, readable JSON file in the directory you specify:
n8n export:workflow --backup --output=backups/workflows/
n8n export:credentials --backup --output=backups/credentials/
Keep workflows and credentials in separate directories. Mixing them in one folder can cause problems during import.
If you run n8n in Docker, run these commands inside the container, for example with docker exec, and copy the output files out to the host. The exact container name and paths depend on your own Docker Compose setup, so check your configuration before running the commands.
--decrypted option — use it with careThe CLI also offers a --decrypted flag, which exports credentials in plain text:
n8n export:credentials --all --decrypted --output=credentials-decrypted.json
This is useful when you are migrating to an instance with a different encryption key, because the plain-text values can be imported under the new key. It is also dangerous: the resulting file contains every API key and password in readable form. Treat it like a password vault export. Transfer it over an encrypted channel, store it encrypted, delete it as soon as the migration is done, and never commit it to a Git repository. In most routine backups, prefer the encrypted export plus a safely stored copy of the encryption key.
CLI exports cover workflows and credentials, but they do not include execution history, users, or settings. For a complete restore, back up the underlying data as well.
.n8n folder (which holds the SQLite database and the config file containing the encryption key). Copying the database while n8n is writing to it can produce an inconsistent backup, so the stop-then-copy order matters.pg_dump on a schedule, and back up the .n8n folder or at least the encryption key separately. Make sure the database dump and the key backup are taken at roughly the same time, so a restore is consistent.For Docker: stop the container, archive the data volume, restart, and copy the archive off the server. A backup that lives only on the machine that fails is not a backup.
The single most common n8n restore failure is a missing or mismatched encryption key. n8n generates a key automatically on first launch and stores it in ~/.n8n/config (in Docker, /home/node/.n8n/config). If that file is lost — for example because a container was recreated without a persistent volume — n8n generates a new key, and every previously encrypted credential becomes unreadable.
The fix is to set the key explicitly as an environment variable, N8N_ENCRYPTION_KEY, before you add credentials, and to store that value in a password manager or secrets store, separate from the workflow backups. Generate it with a command such as:
openssl rand -hex 32
Do not change the key casually on a running instance. If the configured key disagrees with the one in the settings file, n8n will refuse to start rather than silently corrupt data. The supported way to move to a new key is to export credentials with --decrypted, change the key, and re-import them.
Restoring is the reverse of exporting, but the order matters:
N8N_ENCRYPTION_KEY to the source value before first launch.bash
n8n import:credentials --input=credentials.json
n8n import:workflow --input=workflows.json--separate and point --input at the directory.If you restore to a new server, update WEBHOOK_URL and your DNS, since webhooks will have a new public URL. Our companion article on n8n webhooks, queues, and execution retention explains how webhook delivery interacts with queue mode and retention.
A backup nobody runs is worthless. Pick a cadence that matches how fast your workflows change:
Version-control the workflow JSON files if your team is comfortable with Git: separate files (via --backup) make diffs readable, and you can see exactly what changed in a workflow and when. Keep credentials out of Git entirely.
n8n runs best on a server you control, with a persistent volume for its data folder, a PostgreSQL database for production use, and enough memory for your workload. If you are setting up or moving an n8n instance, a VPS hosting plan gives you the persistent storage, the ability to run Docker and PostgreSQL, and the control to set environment variables such as N8N_ENCRYPTION_KEY properly. [TO BE CONFIRMED: whether Offshore Hosting VPS plans include managed n8n setup or backups — confirm before publishing any such claim.]
--backup for readable, versionable exports, and --decrypted only for migrations, with strict handling.Email on your own domain looks professional and stays yours when you change providers. This guide explains what business email hosting involves, how it differs from free webmail, and the DNS and deliverability pieces that make it work.
Latency figures are widely quoted and widely misunderstood. This guide explains what ping measures, which hop actually matters, and the limits of what a VPS can do.
Webhooks, queue mode, and execution retention decide whether n8n stays fast or slowly fills its database. This guide explains each one and the settings that matter.