N8n keeps restarting after docker-compose down

Hey community!

I was interacting with N8N, and, after making some changes to a workflow, I kept getting a “Lost connection” on the Editor UI. Upon closer inspection,I discovered N8n docker service kept restarting, and the following error kept occurring:

N8n was running fine, and I updated to the latest version before I accidentally ran the command docker-compose down,to see if I could fix the restart Issues, which I was afraid I had
deleted everything. To my surprise, the database files are intact(sqlite) and I can see my workflows and work there in a brief window of time before the server goes out again.

How can I proceed? is there anyway I can fix the error, or maybe somehow I can recover my data from the sqlite DB?

I searched on the forums however I couldn’t find anything like this

Hey @Bruno_Tome!

May I know which version were you using earlier? You can use the CLI commands to export your workflows: CLI commands for n8n | Docs

I was on version [email protected]

I see that I can export my commands over the cli, however, since this n8n instance was running on docker, how can I retrieve this information? won’t it be saved on the container itself?
The database.sqlite file is on my host, is there anyway I can retrieve the contents from there?
What about the credentials?

As a side note, I updated the n8n instance and everything was working fine until i tried to save my workflows.
The workflow got saved and got activated, however ended up causing the problems I reported in this thread.

Yes, for that you might have to SSH in the server. Can you try deactivating the workflow? You can find the command to that on the same documentation page.

I think the issue is because of the changes that were introduced in the recent version. We added the functionality to add tags to workflows. Seems to me that your SQLite db didn’t get updated. The migration might have failed.

So, I tried doing that by waiting for the window of opportunity in the docker container, and the cli said I was successful .
however, the docker container kept restarting


(ignore the npx n8n haha)
As you can see in the image, I was basically spamming the docker exec command to make the command go through and was successful in doing so, but the image is still restarting
I have ssh connection to the host, and I already got the data backups from the sqlite files. Is there a way I can use these upon activation to try to retrieve my data ? or should I try a rollback to the image I was before?
BTW, I used the tagging feature in this workflow…

That is the error handler not handling an error correctly. I found this issue a couple of days ago and it’s being investigated by @ivov

In the workflow which nodes are you using?

In the workflow I was using the airtable , woocommerce trigger node, function and the function items nodes.
Was doing an automation to retrieve woocommerce orders upon the trigger, proccessing the data and appending it to airtable.
The function Item node was being used to add some static data to the items on the array and the function itself was a proper “”“ETL”"""
Any questions you guys might have you can ask me.
The OS was the LINUX AMI 2 from Amazon, which is cent-os based if i’m not mistaken
I was running n8n on the docker-compose.yml from the tutorial, and to update the container i used the docker pull command
Here are some logs which might help you guys:


this is where i updated the container :point_up_2:


these are the logs that traefik was throwing out, after the pull :point_up_2:


these are the logs that n8n was throwing :point_up_2:

If you guys have any suggestion I might try to retrieve the workflows that I Had from the docker container or otherwise, I would be really gratefull

For the exporting using the CLI, since the container restarts so quickly, I don’t think or know how I would be able to run the command on it, or where I could store the backups (maybe on the DATA_FOLDER volume?)

You can set the n8n version specifically to 0.123.1 it should then work fine again (considering that it apparently worked fine before).

To do that replace n8nio/n8n with n8nio/n8n:0.123.1 in the docker-compose file and then restart.

Fix got released with [email protected]

2 Likes

Great @jan ! I made some backups for the database and will try to update the container to the release and see if it works.

Thanks @RicardoE105 and @harshil1712 for the help trying to solve the issue!

Just updated N8n and seems that it worked!! Thanks guys for the awesome response and solve time and for all the support you guys gave :relaxed:

Next time will make sure to have everuthing backed up before trying to update hahaha

1 Like

Glad to hear that it worked.

Yes normally a backup should not be needed before an update, just rolling back to the previous version should be enough. Anyway creating a backup is still best practice before every updated and so never wrong.

Have fun!

1 Like