Hello, I'm experiencing a critical issue with my n8n service and need help recovering access to existing data before it's potentially lost. PROJECT DETAILS: - Service: n8n (self-hosted) - Domain: n8n-terapeuta.up.railway.app - Project ID: 1b83b3c4-d6c6-4eff-a34f-891ecc8698eb - Volume ID: df2691de-5fdc-4b27-ad50-ec2cf5e00f61 - Environment ID: 4db08992-691a-4bd0-8214-073d96eb507c WHAT HAPPENED: 1. My n8n instance was working normally with multiple production workflows, credentials, and execution history. 2. I added an environment variable (NODE_FUNCTION_ALLOW_BUILTIN=crypto) and triggered a redeploy to allow the Node.js crypto module in Code nodes. 3. After the redeploy, the service started showing the "Set up owner account" screen — as if it were a brand new n8n installation with no existing data. 4. I checked the connected volume settings: - Mount path: /home/node/.n8n (correct) - Volume usage: 413 MB / 500 MB (data clearly still exists on the volume) - The volume is connected to the correct service 5. I removed the environment variable and redeployed again, but the issue persisted — still showing the fresh setup screen. 6. I checked deployment logs and saw hundreds of database migrations running from scratch (e.g., "Starting migration AddRestoreFieldsToWorkflowBuilderSession..." through very recent ones), which suggests the service may be reading/creating a NEW SQLite database file rather than connecting to the existing one inside the volume. 7. There is only one deployment listed (no rollback history available), so I could not test an older deployment version. 8. Unfortunately, I proceeded to complete the "Set up owner account" flow before realizing this likely indicated a fresh database, and am now in the n8n onboarding/customization screens. QUESTION / REQUEST: Could you please check the actual filesystem contents of the volume (mount path /home/node/.n8n) to confirm whether the original database.sqlite file (or equivalent) still exists there with my previous workflows, credentials, and execution history? If it does, I would appreciate guidance on how to reconnect the service to that existing database file instead of the new one that appears to have been created. I have not made any further changes to the volume (no wipe, no delete) since this started, so I believe the original data should still be physically present. This is time-sensitive as the n8n instance is running production automations. Thank you very much for your help. Best regards, Ricardo Oguido

n8n service showing fresh setup screen despite 413MB of data in connected volume

Anonymous

HOBBYOP

3 months ago

Hello,

I'm experiencing a critical issue with my n8n service and need help recovering access to existing data before it's potentially lost.

PROJECT DETAILS:

Service: n8n (self-hosted)
Domain: n8n-terapeuta.up.railway.app
Project ID: 1b83b3c4-d6c6-4eff-a34f-891ecc8698eb
Volume ID: df2691de-5fdc-4b27-ad50-ec2cf5e00f61
Environment ID: 4db08992-691a-4bd0-8214-073d96eb507c

WHAT HAPPENED:

My n8n instance was working normally with multiple production

workflows, credentials, and execution history.
I added an environment variable (NODE_FUNCTION_ALLOW_BUILTIN=crypto)

and triggered a redeploy to allow the Node.js crypto module in

Code nodes.
After the redeploy, the service started showing the "Set up

owner account" screen — as if it were a brand new n8n installation

with no existing data.
I checked the connected volume settings:
- Mount path: /home/node/.n8n (correct)
- Volume usage: 413 MB / 500 MB (data clearly still exists
  
  on the volume)
- The volume is connected to the correct service
I removed the environment variable and redeployed again, but

the issue persisted — still showing the fresh setup screen.
I checked deployment logs and saw hundreds of database migrations

running from scratch (e.g., "Starting migration

AddRestoreFieldsToWorkflowBuilderSession..." through very recent

ones), which suggests the service may be reading/creating a NEW

SQLite database file rather than connecting to the existing one

inside the volume.
There is only one deployment listed (no rollback history available),

so I could not test an older deployment version.
Unfortunately, I proceeded to complete the "Set up owner account"

flow before realizing this likely indicated a fresh database, and

am now in the n8n onboarding/customization screens.

QUESTION / REQUEST:

Could you please check the actual filesystem contents of the volume

(mount path /home/node/.n8n) to confirm whether the original

database.sqlite file (or equivalent) still exists there with my

previous workflows, credentials, and execution history?

If it does, I would appreciate guidance on how to reconnect the

service to that existing database file instead of the new one that

appears to have been created.

I have not made any further changes to the volume (no wipe, no

delete) since this started, so I believe the original data should

still be physically present.

This is time-sensitive as the n8n instance is running production

automations. Thank you very much for your help.

Best regards,

Ricardo Oguido

$10 Bounty

2 Replies

Railway

BOT

3 months ago

This thread has been opened as a bounty so the community can help solve it.

Status changed to Open Railway • 3 months ago

milo

MODERATOR

2 months ago

The best way to browse the contents of a volume is as follows:

Deploy https://railway.com/deploy/Nan7Bs (FileBrowser template).
Unmount the volume from the filebrowser service & from your service.
Mount the volume you wish to inspect to /data and connect it to the FileBrowser service
Redeploy

owenlindsay83-lang

FREETop 10% Contributor

9 days ago

The fact that the volume still contains roughly 413 MB is encouraging. I would not initialise the new owner account, wipe the volume, or make further changes until the existing n8n database has been located and copied somewhere safe. Railway now supports inspecting volume contents directly with railway volume browse /, and files can also be downloaded with railway volume files download. First confirm what is actually present on the existing volume. For a normal self-hosted n8n Docker installation using SQLite, the important persistent directory is /home/node/.n8n and the database is normally database.sqlite inside it. Also look for the n8n configuration/encryption-key material in the same persisted data because the original encryption key is needed to decrypt stored credentials. If database.sqlite containing the old data is present, the fresh setup screen strongly suggests the current n8n process is reading a different directory/database rather than the old data having disappeared. Confirm the volume is attached to the n8n service at exactly /home/node/.n8n and check whether N8N_USER_FOLDER or database-related environment variables have changed. Also check the deployment logs for the database path n8n reports at startup. Before reconnecting anything, download a copy of database.sqlite and the associated n8n configuration from the volume. Then restore the original mount/path configuration and redeploy. Adding NODE_FUNCTION_ALLOW_BUILTIN=crypto by itself should not require a new n8n database, so I would focus on the runtime data path, volume attachment and permissions rather than treating the 413 MB volume as lost. Railway also documents that volumes are mounted only at runtime and that an incorrect mount path causes the application to use non-persistent storage instead. If the old database is present but n8n still starts as new, please post the directory listing of /home/node/.n8n and the startup lines showing which database/path n8n is using, with secrets redacted.

Welcome!