2 months ago
We are seeing a recurring issue on Railway where the persistent volume mount for our production service does not remain attached across deployments.
Service:
- saffas_ae_connect
Required persistent volume:
- saffas-data
- mount path: /app/data
Expected behavior:
- the service-level volume mount should persist across deployments
Observed behavior:
- the volume mount is attached
- a deployment succeeds
- on a later deployment, the mount is no longer present in the service config
- the new deployment crashes at startup because the mounted path is missing
- the previous deployment remains active as fallback while the new one crashes
Startup failure message:
- Missing mounted prisma directory at /app/data/prisma
This is intentional fail-fast behavior in our app to prevent fallback to ephemeral SQLite storage.
Impact:
- production deployment instability
- new deployments fail to start
- persistent application data is at risk if the app were to start without the mounted volume
Please investigate why the service volume mount is not persisting reliably in the service configuration across deployments.
1 Replies
2 months ago
This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.
Status changed to Open Railway • 2 months ago
Status changed to Awaiting Railway Response Railway • 2 months ago
a month ago
The /app/data mount path is the right shape for this app. Railway's volume docs specifically call out that Nixpacks apps live under /app, so if the app writes to ./data, the volume mount should be /app/data: https://docs.railway.com/develop/volumes
A few things I would separate here:
-
Volumes are mounted only at runtime, not during build or pre-deploy. If the Prisma directory check runs in a pre-deploy command, it will fail even when the volume is configured correctly. Railway documents that caveat on the same volumes page.
-
At runtime, Railway should inject RAILWAY_VOLUME_MOUNT_PATH. I would log that variable at startup and compare it to /app/data, then also log
ls -ld /app/data /app/data/prismabefore the app exits. That proves whether the container actually received the mount or whether only the service config UI is stale. -
Check whether anything in CI or local automation is touching volumes. The Railway CLI has volume attach/detach/update operations, including changing the mount path: https://docs.railway.com/cli/volume. A deploy command should not normally remove the service's volume attachment, but an automation/API step could.
If the volume is visibly attached to saffas_ae_connect in the Production environment, no pre-deploy check is involved, and the attachment later disappears from the service config without a CLI/API detach/update, then this is not an app-level SQLite/Prisma issue. Railway staff likely needs to inspect the volume instance / service-volume attachment history for that production environment. I would include the successful deployment ID, failed deployment ID, volume ID/name, environment, and the timestamp when the mount disappeared.