Your latest deployment is currently up and serving, with the /data volume mounted to it and the app listening on its port, so the 502 should be cleared on your end now. Can you confirm app.aw-structural.com and your .up.railway.app URL are loading for you again?

A volume can only be attached to one deployment at a time, so when a deploy overlaps with the previous one the new container can be left unable to mount /data until the old one fully releases it, which lines up with what you saw. We're going to have the team take a closer look at the release timing on this service so a redeploy hands the volume over cleanly. If it 502s again, redeploying once more is the fastest way to force a clean single-container state in the meantime.

Confirmed — both app.aw-structural.com and the .up.railway.app URL are

loading again. Thank you.

One note for the team: today it did NOT self-clear by redeploying. I

redeployed the known-good build several times over ~2.5 hours and it stayed

stuck on "Creating containers" until the volume was released on your end — so

the handoff timing on this service does seem to need the fix you mentioned.

I have a pending deploy (a tested logo/branding change) I'd like to push.

Could you let me know once the release-timing fix is in place so the next

deploy hands the volume over cleanly? Happy to wait to avoid another stuck

state.

Thanks for confirming, and for the detail about redeploying not clearing it - that's helpful context for us. We don't have a timeline to share on the handoff improvement yet, but your service is running cleanly right now, so you're safe to push your branding deploy. If it gets stuck on "Creating containers" again, reach out and we can release the volume much faster this time.