a month ago
I tried creating and mounting n8n primary to a persistant volume using the railway agent, but something must've not been done correctly.
I asked it repeatedly to troubleshoot, but it kept failing over 10 times.
So I asked it to revert to an older version so I can just access my workflows, but it fails to do even that! I'm in a position where I can't access n8n OR revert to an older version!
Has anyone else dealt with the railway agent irreversibly messing up a deployment before? I just want a way to be able to revert to a previous deployment at this point and access my current workflows, they were NOT backed up yet.
When manually trying to redeploy an image from a week back, I am running into npm errors that weren't there before.
Attached both logs and the agent conversation history.
What is the next step forward from here and how do I ensure workflows are not lost? Let me know if anything else is needed.
(Apologies for the messy logs, the system wasn't accepting docx file format)
Attachments
1 Replies
a month ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • about 1 month ago
a month ago
If your workflows were stored on the original n8n instance and weren't backed up, the most important thing right now is:
Do not keep redeploying or letting the AI agent make more changes until you know where the data actually lives.
The workflows are almost never stored in the Docker image itself. They're typically in one of these places:
A persistent volume (/home/node/.n8n)
A PostgreSQL database
SQLite (database.sqlite) inside .n8n
An external database (Postgres, MySQL, etc.)
The fact that reverting an older image still fails with npm errors suggests the deployment problem may be separate from the workflow data.