We checked the production environment and can confirm what you're seeing. The VereinsOrganisator service has a volume attached there, and its most recent deployment (created 2026-10-06 at 20:13 UTC) failed with the "no volume attached" message before the pre-deploy step started.

Your pre-deploy script isn't involved. Pre-deploy containers don't mount service volumes, so migrations and permission sync never touch the volume.

Redeploying again won't change the result, and you don't need to change anything in your configuration. Your current production deployment keeps running while new deployments are blocked.

Thank you for confirming the issue.

Unfortunately, this does not resolve the problem. Our production deployment is currently blocked, and three deployment attempts have failed with the same incorrect “no volume attached” error.

The existing production application remains online, but we cannot deploy new releases.

Since you’ve confirmed that the volume is attached correctly and that our pre-deploy script is not responsible, could you please escalate this issue to a human Railway infrastructure engineer?

We specifically need assistance with:

1. Investigating the internal service-volume association and deployment scheduler.
2. Resolving the inconsistency between the READY volume state and the deployment validation.
3. Restoring our ability to deploy new commits without detaching, replacing, or risking the existing persistent volume.
4. Confirming when the issue is resolved and it is safe to deploy again.

We would prefer not to detach or recreate the volume because the existing production application depends on its persistent storage.

If this requires a private support ticket or internal engineering escalation, please let us know how to proceed.

Thank you for your assistance.

You don't need to detach, recreate, or replace the volume. Our records show app-storage attached to VereinsOrganisator in production at /app/backend/storage and in a ready state, which matches what you see. There's also no separate ticket to open, this thread is the right channel.

Further redeploy attempts will hit the same check before the pre-deploy step, so they won't touch your volume or the running production deployment. Your current production deployment keeps serving in the meantime.

Thank you for confirming that our production volume is correctly attached and that no configuration changes are required.

However, our actual problem remains unresolved.

We have been unable to deploy any application updates since October 6, 2026. Our latest commit is ready, but Railway continues to reject every new deployment due to an incorrect volume validation error.

We understand that the existing production deployment remains operational. However, keeping the old version running does not resolve our inability to release updates.

Could you please escalate this issue to a human infrastructure engineer who can investigate and resolve the underlying deployment problem?

We would appreciate clear answers to the following questions:

1. Has this specific infrastructure issue been assigned to an engineer?
2. What action will Railway take to correct the inconsistent volume validation?
3. Is there an estimated timeframe for restoring deployments?
4. Can Railway resolve this internally without requiring us to detach or modify our existing production volume?

We are not requesting another redeployment attempt or general explanation of the error. We need assistance restoring the deployment functionality of our production service.

Thank you for your help.