My n8n workflows disappeared
The setup screen is asking you to create an account again and everything you built is gone. Here is where it went, what can be recovered, and how to make it stop.
What you are seeing
You restarted, or the machine rebooted, or you redeployed, and n8n came back as if it had never been used. No workflows, no executions, and a first-run screen asking you to create the owner account you already created.
Why it happens
Everything was living somewhere temporary
Out of the box, n8n keeps its entire state in a single file database inside ~/.n8n. Workflows, credentials, execution history, your account: one file.
If ~/.n8n is not mapped to storage that outlives the running instance, then every restart hands n8n a clean, empty directory. It does exactly what it did the first time, which is to set itself up from nothing.
Nothing warns you at the moment of the mistake, because at that moment nothing is wrong. The setup runs fine, the workflows run fine, and the problem is invisible until the first restart, which might be weeks later.
The second version of this, which catches careful people
You had storage mapped, you later switched the database over to a proper server, and everything vanished at that moment instead.
Switching the database setting does not move your data across. It points n8n at a different, empty place. The old data is still sitting in the old file, untouched, which is good news if you have not deleted it.
How to fix it
Check whether the old storage still exists
This is worth five minutes before you accept the loss. Storage often survives the thing that was using it, and an orphaned volume with your entire n8n in it is a common outcome.
# List volumes and look for anything n8n shaped
docker volume ls
# Look inside one without starting n8n
docker run --rm -v n8n_data:/data alpine ls -la /data
# If database.sqlite is in there, copy it out before touching anything else
docker run --rm -v n8n_data:/data -v "$PWD":/backup alpine \
cp /data/database.sqlite /backup/database.sqlitePut it back and mount it properly this time
Stop n8n, mount a named volume at ~/.n8n, copy the recovered file into it, and start again. Take the encryption key with it, or you will trade this problem for the credentials one.
services:
n8n:
image: docker.n8n.io/n8nio/n8n:1.70.0
environment:
- N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
volumes:
- n8n_data:/home/node/.n8n # this line is the whole fix
volumes:
n8n_data:If you are moving to a real database, export first
Do this while the old instance still works. Export, stand the new database up, point n8n at it, then import. In that order, with the same encryption key on both sides.
# From the instance that still has your data
docker exec -it n8n n8n export:workflow --all --output=/home/node/.n8n/workflows.json
docker exec -it n8n n8n export:credentials --all --output=/home/node/.n8n/credentials.json
# Then, against the new empty database, with the SAME N8N_ENCRYPTION_KEY set
docker exec -it n8n n8n import:workflow --input=/home/node/.n8n/workflows.json
docker exec -it n8n n8n import:credentials --input=/home/node/.n8n/credentials.jsonStopping it happening again
Two things, and one of them is not optional
Mount ~/.n8n on named storage from the very first run, before you build anything you would miss.
Once it matters, move to a database server rather than the single file. The file is fine for trying things and it is a bad place for a year of work.
Export your workflows on a schedule. n8n can do this itself, on a schedule, into a repository you own. It takes ten minutes to build and it is the only backup that is genuinely yours.