Description:

I'm experiencing a persistent issue with volume attachment on my Railway service. The volume shows as successfully created and mounted in the service configuration, but the mount path does not actually exist in the running container.

Details:

Service ID: a73c149a-a423-4916-9abc-e0bfcf4c400f

Project ID: 549f442f-846b-4aca-aaed-2fc553bb8c69

Mount path configured: /data

Volume configured in service: Yes, appears in config as mounted

What happens: When I run ls /data in the container, the directory does not exist

Steps I've already taken:

Created the volume and attached it to the service — no mount

Verified the code writes to /data/prompt_log.json — path doesn't exist

Deleted the volume entirely and created a fresh one — same result

Redeployed the service 4+ times with the new volume attached — still no /data directory

Confirmed the app's code is correct and pointed at /data — the issue is not on our side

Expected behavior:

The volume should mount at /data and persist files across redeploys. Files written to that path should survive subsequent deployments.

Actual behavior:

/data never appears in the container. No errors are shown in the deployment logs. The service config shows the volume as mounted, but it's not actually attached to the running instance.

Ticket severity: Medium-High — this is blocking persistent data storage. The app itself is otherwise functional, but user-generated content (prompts, saved teachings) is being wiped on every deploy.

Additional context:

This is not a code issue — the app's storage logic is correct. The same behavior occurred with two separate volumes and multiple deployments. The Railway agent I spoke with confirmed this appears to be a platform-side issue with volume attachment.

Happy to provide any additional logs or details needed. Please let me know what steps to take next, or if this needs to be escalated.

Thank you.