Workflows lost after docker restart

Describe the problem/error/question

Hi everyone,

I’m facing an issue where every time I restart my n8n Docker container, the instance reverts to a state from about 2–3 weeks ago. Recent workflow changes disappear, but some settings (like SSO and Git integration) remain.

Setup

  • n8n running in Docker

  • Persistent volume mounted at:
    /home/n8n/n8n-compose/n8n-data:/home/node/.n8n

  • SQLite database (database.sqlite) is used

  • N8N_LOG_LEVEL=debug enabled

  • No errors or warnings about the database in logs

What I’ve confirmed

  • The volume mount is correct

  • Permissions are correct

  • Logs show SQLite loads fine and persists executions

  • No Git Version Control sync logs (no pull/push/import)

  • After a restart, the database.sqlite timestamp goes back to an older date

The problem

Even though the volume is mounted correctly, n8n seems to load an old version of the SQLite database on every restart. Workflow updates made recently are lost.

My question

Under what circumstances could n8n fall back to an older SQLite state without logging any errors?
Is there any mechanism where n8n overwrites the current DB on startup (even without Version Control sync logs)?

Thanks for any insights!

Information on your n8n setup

  • n8n version: 1.113.3
  • Database (default: SQLite): default
  • n8n EXECUTIONS_PROCESS setting (default: own, main): default
  • Running n8n via (Docker, npm, n8n cloud, desktop app): Docker
  • Operating system: Ubuntu 22.04

Hello,

Have you checked your host time to see if it is in the correct time zone? Also, what exactly do you do when you restart? Which commands do you execute? Do you perform an image update?

It is very possible for n8n to load an older SQLite file even if everything looks correct. Here are a few checks you can run that might help you debug the issue.

1. Check whether Docker has created more than one volume related to n8n.
This is one of the most common causes of a rollback to an old state.

docker volume ls

If you see more than one n8n-related volume, each one could contain a different SQLite file.

2. Inspect each volume to find out where it actually lives on the host.

docker volume inspect <volume_name>

Look for the "Mountpoint" value and check which directory contains the most recent database.sqlite timestamp.

3. Check which SQLite file the running container is truly using.

docker exec -it <n8n-container-name> sh -c "ls -lah /home/node/.n8n"

Verify the timestamp on database.sqlite. If it does not match the file in your expected host directory, you have located the mismatch. If you know how to fix it, go for it. If you need help, please let me know.

There are a number of other reasons this is happening, so if this does not help you get to the bottom of the issue, you might want to share the sanitized docker-compose file and docker inspect output here. I hope this helps. -Bill

same thing happened with me last night exactly with same n8n version, I lost my three days work, but I realise it late, before that I created a new workflow and saved it so timestamp of the database.sqlite is today’s date 19th nov. Later when I wanted to copy something from yesterday’ work, found that it was not there at all. Now database.sqlite at host and in docker both are showing same timestamp but not able to find the way how to revert it 18th nov history.

I suspect the cause was one of this.

  1. I redeployed some images not n8n image, in EasyPannel.
  2. That time one of my n8n workflow was opened in browser, when I tried to save it. It gave an error like ‘You don’t have permission to save this workflow‘ kind of error, it was strange , I ignored it and closed the browser forcefully.

Your support would be appreciated.