9 hours ago
unning self-hosted n8n on Railway. My service's image source was set to docker.n8n.io/n8nio/n8n with no version tag (so it was tracking "latest"). A redeploy today pulled a newer image and bumped the running version from 2.36.8 → 2.38.7. After that redeploy, n8n came up as if it were a fresh install — prompted me to create a new owner account, and the logs show:
Building workflow dependency index...
Finished building workflow dependency index. Processed 0 draft workflows, 0 published workflows.
...
Recorded version change: (none) -> 2.38.7
The attached volume (5GB, mounted at /home/node/.n8n) is still attached to the service with no changes to size or mount path — but n8n is behaving as though there's no database at all.
What I've tried:
Confirmed the volume is still attached at the correct path, unchanged.
No backups/snapshots available on my current plan.
Rolled the image back to a pinned tag matching the pre-incident version (n8nio/n8n:2.36.8) and redeployed. Same result — still "Processed 0 draft workflows, 0 published workflows", still "Recorded version change: (none) -> 2.36.8". This rules out a simple version-compatibility issue, since the exact previously-working version shows the same empty state.
Has anyone run into this? Specifically wondering:
Whether an unpinned "latest" tag redeploy can somehow cause n8n to write to a different path/file within the same mounted volume, leaving old data physically present but unreferenced.
Whether a Railway-side change (e.g., how UIDs are assigned to containers — I have RAILWAY_RUN_UID set as an env var) could cause a permission mismatch that makes n8n silently fall back to a fresh database rather than erroring out.
Any way to get filesystem-level access to a Railway volume to check what's actually in there, short of Railway support.
Happy to share deployment IDs or further logs. This service had several active production workflows before this happened, so any pointers toward recovery would be hugely appreciated.
3 Replies
9 hours ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • about 9 hours ago
9 hours ago
You can inspect the volume by going to the Console tab if your n8n service.
8 hours ago
Update — found something more specific
Since my last message, I did more testing directly via the Console tab, and I think I've isolated this to something in the volume persistence itself rather than my original configuration.
What I fixed already: I found n8n was running as root with HOME=/root, writing its database to /root/.n8n — outside the mounted volume entirely. I set N8N_USER_FOLDER=/home/node so n8n would write to the actual volume mount (/home/node/.n8n).
What I tested after that fix:
Confirmed via console that database.sqlite (1.5MB, with active -wal/-shm files) existed directly at /home/node/.n8n/database.sqlite — the correct, volume-backed path.
Created a test workflow through the UI to confirm it saved.
Triggered a graceful restart via the dashboard (not a full redeploy) — logs show a clean shutdown:
Received SIGTERM. Shutting down...
Stopping n8n...
Initializing n8n process...
On restart, n8n logged "Processed 0 draft workflows, 0 published workflows" — the test workflow, and the entire database, was gone again.
I repeated this cycle twice with the same result each time. The volume mount path is confirmed correct (/home/node/.n8n, matching RAILWAY_VOLUME_MOUNT_PATH), the shutdown is graceful, and the file demonstrably exists with real content immediately before each restart — yet it doesn't survive the restart.
This rules out (from my side): app-level path misconfiguration, ungraceful/crash shutdown, and n8n version (tested on both 2.36.8 and 2.38.7 with identical results).
What I'm hoping someone can check: whether volume eaeb0c8a-783b-4118-aa60-ea82d86cf156 (n8n-data, 5GB, sfo region) is actually being correctly reattached to the same underlying storage on each restart/redeploy, or whether something in the mount/unmount cycle for this specific volume is resetting it. Deployment IDs from today's testing, in case they're useful: 453f8556-0d5b-4ab0-ba98-35ecabc30d99, bbd8b4ed-df16-4d85-86ad-8d329c494932, 74a5b017-ead5-4857-8246-9073a5bbbd0c, 2bca0cfb-271c-46a5-b0a0-eec6754559c4.
Given the difficulty pinning this down, I'm planning to move n8n off SQLite entirely and onto an external Postgres database, which should sidestep this specific issue — but I'd still appreciate any insight into what's actually happening at the volume layer, in case it affects other services too.
7 hours ago
Hey — your updates already hit the n8n-on-Railway footgun. A restart wipe after you fixed the path is persistence/UID/mount, not “latest broke SQLite schema.”
Official n8n guide (https://docs.railway.com/guides/n8n): image n8nio/n8n (pin a tag in production); volume mount /home/node/.n8n; optional Postgres via DB_TYPE=postgresdb. Volume attached ≠ n8n reading it unless the data dir is that mount.
Root + HOME=/root writes SQLite under /root/.n8n (ephemeral unless that’s the mount). Pointing at /home/node/.n8n matches the guide. Seeing database.sqlite there, then 0 workflows after a graceful restart, is more than “wrong directory.”
Volumes (https://docs.railway.com/volumes/reference): persist across deploys/restarts; mounted at runtime; mounted as root; RAILWAY_RUN_UID=0 is the documented non-root permission workaround; one volume per service.
Please check in your project (https://docs.railway.com/cli/volume):
railway volume files list /home/node/.n8n
Before and after a restart:
- RAILWAY_VOLUME_MOUNT_PATH is /home/node/.n8n
- Does database.sqlite keep the same size/mtime, or get replaced by a tiny new file?
- Any second copy under /root/.n8n?
- UID vs file ownership (RAILWAY_RUN_UID unset vs 0)
- Only one active deploy owning the volume
If the file vanishes across a simple restart, that’s a volume/reattach issue for support with the IDs you already posted. If the file stays but n8n still says Processed 0, it’s app/config (N8N_USER_FOLDER, DB mode, or missing encryption/config beside the sqlite file).
Docs-backed mitigation: pin tags, mount /home/node/.n8n, align UID, and use Postgres for production. Download the 1.5MB database.sqlite with railway volume files download before more experiments.
Share whether that file survives restart in the CLI listing (sizes/timestamps only — no secrets) and we can split volume loss vs wrong open path.