Your n8n service had no volume attached, so the SQLite database lived on ephemeral container storage, which is discarded on every redeploy and cannot be recovered. Going forward, attach a volume to persist /home/node/.n8n across redeploys, and enable volume backups so you can self-restore if needed.

My service was not manually redeployed. Railway removed the service after my trial ended, which caused the container filesystem containing /home/node/.n8n/database.sqlite to disappear, for when i purchased a subscription.

Is there any possibility the previous container filesystem, snapshot, or deployment layer from the old deployment (2648d44c, Jun 16) is still available internally for recovery?

I understand the data was stored on ephemeral storage, but I want to confirm whether Railway retains any recovery window after automatic service changes.

The data was never written to persistent storage, so there is nothing on our side to restore, regardless of what triggered the container lifecycle change. To prevent this going forward, attach a volume to persist /home/node/.n8n and enable volume backups on the service.

The Railway bot is right here, once a deployment was removed its ephemeral storage can no longer be recovered

Thanks for confirming. Just to clarify, there is no snapshot, filesystem layer, cache, or temporary recovery window available for removed containers even shortly after removal? I want to make sure before considering the data permanently lost.

Yep, that's right.

There's no snapshot or temporary recover window, ephemeral storage is deleted immediately when the container terminates.

Confirmed - there is no snapshot, filesystem layer, cache, or temporary recovery window for ephemeral container storage. Once a container is removed, that storage is gone. Your service had no volume attached, so the SQLite database was never written to persistent storage. Sorry about that.