Most n8n backup advice stops at “export your workflows.” That gets you half a restore. The half it skips is the part that decides whether your credentials still work on the other side, and you find out which half you have on the day you actually need it.
It is also a gap in n8n’s own documentation. There is no backup page in the n8n docs - the closest thing is a --backup flag on an export command and a “back up your database first” warning on an unrelated page. So this is a thing every self-hoster has to work out, and most work out half of.
Here is the whole thing: what n8n stores, the three ways to back it up, and the one file that makes or breaks a restore.
How Do I Back Up n8n Workflows and Credentials?
Run n8n export:workflow --backup --output=backups/latest/ and n8n export:credentials --backup --output=backups/latest/ from the machine n8n runs on. Then save the encryption key out of ~/.n8n/config somewhere separate. Credential exports are encrypted by default, so without that key the credentials half of your backup restores into nothing.
That is the short version. The rest of this post is why the key matters, and which of the three backup methods you actually want.
What Does Self-Hosted n8n Actually Store?
Everything lives under ~/.n8n. n8n’s docs put it this way: “n8n saves user-specific data like the encryption key, SQLite database file, and the ID of the tunnel (if used) in the subfolder .n8n of the user who started n8n.” The database file is at ~/.n8n/database.sqlite, binary data at ~/.n8n/binaryData, and the encryption key in the settings file. Back up the folder and you have backed up n8n.
Four things live in there, and they fail differently:
| What | Where | What happens if you lose it |
|---|---|---|
| Workflows | ~/.n8n/database.sqlite | Rebuild every automation by hand |
| Credentials (encrypted) | ~/.n8n/database.sqlite | Re-enter every API key and redo every OAuth consent |
| Encryption key | ~/.n8n/config | Credentials are unreadable even though you still have them |
| Binary data | ~/.n8n/binaryData | Files from past executions are gone; workflows still run |
The row that catches people is the third one. Your credentials are not lost when you lose the key - they are right there in the database, encrypted, permanently. That is a different and worse problem than not having a backup at all, because the backup looks fine until you restore it. How the n8n encryption key works is its own post.
Method 1: The CLI Export (Portable, Selective)
n8n’s CLI writes workflows and credentials to JSON you can commit, diff and move between instances. --backup is the flag you want: the docs define it as “Sets --all --pretty --separate for backups”, which is one readable file per item in a directory. export:credentials adds --decrypted. This is the method that survives a move to a different host.
From the machine running n8n:
mkdir -p ~/n8n-backup/workflows ~/n8n-backup/credentials
# Every workflow, one pretty-printed file each (nicer in git)
n8n export:workflow --backup --output=~/n8n-backup/workflows/
# Every credential, still encrypted
n8n export:credentials --backup --output=~/n8n-backup/credentials/Restoring is close to the mirror image, with one gotcha: the import commands do not take --all, --backup or --output. They take --input, and --separate there means “read every *.json in this directory.”
n8n import:workflow --separate --input=~/n8n-backup/workflows/
n8n import:credentials --separate --input=~/n8n-backup/credentials/If you are moving between database engines rather than restoring in place, n8n 2.x added a dedicated pair for that - n8n export:entities --outputDir=./outputs and n8n import:entities --inputDir ./outputs - which the docs describe as allowing “importing of entities into a database type that differs from the exported database type”, currently SQLite and Postgres.
Two things this method does not carry: execution history, and anything you configured outside n8n itself (environment variables, the reverse proxy, WEBHOOK_URL). It is a workflow-and-credential backup, not a server backup.
This export is also what makes leaving cheap. Workflows come out as readable JSON you can diff, so if you ever evaluate n8n alternatives you have a record of what you built, even though no other tool imports n8n’s node graph directly.
The --decrypted decision
n8n export:credentials --all --decrypted --output=backups/decrypted.json writes your API keys and OAuth tokens as plaintext JSON. It makes the export portable to any n8n instance, with any encryption key. It also makes that file exactly as sensitive as every secret in it - n8n’s docs flag it in a warning box: “All sensitive information is visible in the files.”
Pick deliberately:
- Encrypted export + key stored separately - safer at rest, but the restore is only as good as your key handling.
--decryptedexport - trivially portable, and now you own a plaintext secrets file. If you do this, do not put it in git, do not leave it in/tmp, and delete it once it is imported.
There is no third option where the export is both portable and not secret-bearing. That is what encryption means.
Method 2: Copy the Whole ~/.n8n Folder (Complete, Not Portable)
Copying ~/.n8n gets you an exact clone: workflows, credentials, execution history and the encryption key together in one archive. It is the most complete backup and the least portable, because it assumes the destination runs a compatible n8n version and the same database.
tar -czf n8n-$(date +%F).tar.gz -C /home/instapod .n8nThis is the atomic option. Because config travels with database.sqlite, credentials decrypt on the other side without you doing anything - the key came along.
The trade-off is that you are now moving a SQLite database between n8n versions, and n8n runs migrations on startup. Restoring an old archive onto a much newer n8n usually works, but the reverse - a newer database on an older n8n - does not. Note the version you took it from.
If you are moving hosts rather than taking a backup, we wrote the full n8n migration walkthrough separately, including the platform-by-platform export routes.
Method 3: Let the Host Do It
Some managed hosts snapshot the n8n data directory on a schedule, which means the key and the database are captured together and restored together. On InstaPods, /home/instapod/.n8n is in the backup set, backups run every 24 hours by default, and the Build plan at $7/mo keeps 5 restore points.
Being specific about what that covers, because “backups included” is a phrase that hides a lot:
- The backed-up path is the n8n data directory, so workflows, encrypted credentials, execution history and the settings file holding the encryption key are all in the same archive.
- That path is also the whole of it. If you move n8n’s database to a PostgreSQL instance you installed on the pod yourself, the daily backup keeps succeeding and stops containing your workflows. Back that database up separately, or leave n8n on its default SQLite.
- Schedule is every 24 hours, enabled at deploy without you turning it on.
- Retention tracks the plan: 5 copies on Build ($7/mo), 10 on Grow, 15 on Scale.
- Restore is a button in the pod’s Backups tab, and you can download the archive to keep a copy off-platform.
A typical n8n instance archives at 20-60 MB, most of which is execution history.
What it does not cover: this is a hosting-layer backup, so it protects you from a lost server, a bad upgrade or a fat-fingered delete. It does not protect you from a workflow that quietly corrupted your data three weeks ago, because that will be in every one of the last 5 copies. Retention depth is not the same as detecting damage.
Which Method Should You Use?
Use two. A host-level or folder-level backup for “the server is gone,” and a CLI export in git for “I want to see what changed and roll back one workflow.” They fail in different directions, which is the point.
| Method | Restores credentials? | Portable to another host? | Execution history? | Effort |
|---|---|---|---|---|
| CLI export (encrypted) | Only with the key | Yes | No | Low, scriptable |
CLI export (--decrypted) | Yes | Yes | No | Low, secret-bearing file |
Copy ~/.n8n | Yes | Same-version only | Yes | Low |
| Managed daily backup | Yes | Via download | Yes | None |
If you self-host on a plain VPS, the honest version is: a nightly tar of ~/.n8n to object storage plus a weekly CLI export into a private repo covers you, and it is maybe twenty minutes to set up once. That is a genuinely fine answer and you do not need to pay anyone for it. What you do need is to have actually done it before the disk dies, and to have tested a restore at least once.
How Do I Test That My n8n Backup Actually Works?
Restore it somewhere that is not production. Spin up a second n8n instance, import the backup, open a credential and check it still authenticates against the real service. A backup you have never restored is a hypothesis.
The specific thing to check is credentials, not workflows. Workflows are JSON; they either import or they visibly do not. Credentials import silently and fail later, at 3am, inside a node, with an auth error that looks like the upstream service’s fault. Open one after restoring and hit Test.
What n8n Backups Do Not Cover
Two things worth saying plainly, because no backup strategy and no hosting plan fixes them.
Credential sprawl. Backing up credentials is not the same as knowing what they are. If the same API key exists in three n8n credentials, two environment variables and a colleague’s laptop, a perfect backup preserves that mess exactly. That is a key-hygiene problem inside n8n and inside your own process, and it is not something a host can solve for you.
Human approval steps. If a workflow should pause for a person before it moves money or changes a customer record, you build that into the workflow. Restoring from backup after the fact is not a control - it is cleanup.
We said the same thing on the n8n app page and it has not stopped being true.
FAQ
Where is the n8n backup folder?
There is no separate backup folder. n8n’s live data directory is ~/.n8n (/home/instapod/.n8n on an InstaPods pod), and you back it up by copying it or by exporting from it with the CLI.
Can I back up n8n from the UI? Not as a whole-instance export. You can download individual workflows from the workflow menu, which is fine for one-offs and useless as a backup strategy. Credentials cannot be exported from the UI at all - that is CLI or database only, by design.
Does n8n back itself up automatically? No, and it does not document a way to. Self-hosted n8n writes to its database and that is the extent of it. Any schedule is one you set up, or one your host runs for you.
How big is an n8n backup? Usually 20-60 MB, dominated by execution history. Pruning is on by default in current n8n, so a much larger archive is almost always unreclaimed SQLite space or binary data sitting in the database - both covered in why n8n gets slow.
Do I need to stop n8n before backing up?
For a CLI export, no. For a raw copy of database.sqlite on a busy instance, stopping n8n first avoids copying a database mid-write. On a small instance the risk is low but not zero, and SQLite’s WAL files are part of the story.
Running n8n and would rather not own the backup job? Deploy n8n on InstaPods for $7/mo - 2 vCPU, 2 GB RAM, HTTPS configured, and the n8n data directory backed up daily with 5 restore points. Or price out eight n8n hosts including the DIY VPS route first.