a month ago
I am experiencing a critical deployment issue in my production environment on Railway. Even after performing a full redeploy of the service, the application continues to fail with persistent volume mount errors.
The deploy logs continuously show the following errors:
ERROR (catatonit:2): failed to exec pid1: No such file or directory
and repeated volume mount attempts such as:
Mounting volume on: /var/lib/containers/railwayapp/bind-mounts/...
The service does not recover even after:
Triggering a manual redeploy
Restarting the deployment
Waiting for Railway to recreate the container
This strongly suggests that the container initialization or mounted volume state is corrupted/inconsistent on the Railway infrastructure side.
Impact:
Application instability in production
Service interruption risks
Operational impact affecting platform reliability Critical Railway Deployment Failure — Persistent Volume Mount Error After Redeploy
Attachments
4 Replies
Status changed to Open Railway • about 1 month ago
a month ago
I'm having a similar issue, I've just pushed a new update and nothing is deploying. I have a very important update I need to put in, recently paid for Railway and this happens at the worst time.
a month ago
Hey, just looked at your logs and this is definitely not on your end. The volume keeps mounting correctly but catatonit still can't find the entrypoint binary, which means Railway's bind-mount state is corrupted at the infrastructure level. Redeploying won't fix it because the bad state persists across deploys.
A few things you can do right now:
First, go to your Railway dashboard and delete the volume entirely, then redeploy without it. If your app boots clean, that confirms the volume is the culprit.
For a temporary workaround, move whatever you're storing on that volume to an external storage solution like S3, Cloudflare R2, or Supabase Storage. It's a bit of extra setup but it'll unblock you while Railway sorts this out on their end.
Also make sure you open a support ticket with Railway directly and attach these logs. Tag it as a production infrastructure issue, not a general question. They need to manually clear the corrupted volume state on their side, and that only happens if you escalate properly.
The core issue here isn't your config or your image, it's Railway's volume management failing to maintain consistent state between container recreations. You're not doing anything wrong.
dmov1403
Hey, just looked at your logs and this is definitely not on your end. The volume keeps mounting correctly but catatonit still can't find the entrypoint binary, which means Railway's bind-mount state is corrupted at the infrastructure level. Redeploying won't fix it because the bad state persists across deploys. A few things you can do right now: First, go to your Railway dashboard and delete the volume entirely, then redeploy without it. If your app boots clean, that confirms the volume is the culprit. For a temporary workaround, move whatever you're storing on that volume to an external storage solution like S3, Cloudflare R2, or Supabase Storage. It's a bit of extra setup but it'll unblock you while Railway sorts this out on their end. Also make sure you open a support ticket with Railway directly and attach these logs. Tag it as a production infrastructure issue, not a general question. They need to manually clear the corrupted volume state on their side, and that only happens if you escalate properly. The core issue here isn't your config or your image, it's Railway's volume management failing to maintain consistent state between container recreations. You're not doing anything wrong.
a month ago
Dont delete the volume or you will lose all your production data
-Download a backup: go to the Volumes tab and download your data locally just to be safe
-Clone the service: click the three dots (...) on your service and hit "Clone Service". This forces Railway to deploy your app on a completely clean physical node, breaking the corrupted bind mount loop
-Switch over: attach your volume to the new cloned service verify it boots, point your domain to it, and delete the old stuck service
a month ago
I would not delete the volume. that is the one thing here that can make a bad situation permanent.
the catatonit: failed to exec pid1 part usually points more to the image/entrypoint than to the mounted data itself. first try Redeploy source image from the command palette so Railway re-pulls/rebuilds the image instead of reusing the stale one.
if you clone the service, only attach the production volume after the cloned service boots cleanly without it. that tells you whether the failure is image/start-command or volume-related.