Railway's build system puts your application files in an /app folder at the root of the container. If your application writes data to ./uploads, you should set the mount path to /app/uploads (or /app/editorial). Depending on how you write/read files in your app, you should set the mount path of your volume accordingly.

You can read more about this here: https://docs.railway.com/volumes#relative-paths.

You can change the volume mount path by clicking on the volume under your service, then settings.

Hi Railway Support,

I’m experiencing what appears to be a volume-instance/backing-storage mapping mismatch in production.

Project: dr-uzair-janjua-railway

Environment: production

Service: web

Volume: web-volume

Volume ID: e665554f-d7f6-45ba-b203-1cf5c1d2a860

Configured mount path: /uploads

The existing volume data is still accessible through Railway’s Volume Files API/CLI.

For example:

railway volume files \

--volume e665554f-d7f6-45ba-b203-1cf5c1d2a860 \

list /editorial/2026/08

returns the expected existing files, including:

dental-implant-cost-uk-hero-55987852.png

However, the running production container sees a different filesystem state at the configured mount point:

/uploads/lost+found

The expected "/uploads/editorial/..." tree is not present.

We also verified from inside the running Node application that:

RAILWAY_VOLUME_MOUNT_PATH=/uploads

rootExists: true

editorialExists: false

exists: false

The service has already been restarted and redeployed, with no change.

This suggests that the production "web" service's volume instance is mounted correctly at "/uploads", but is attached to a different or empty backing filesystem than the one being accessed by Railway's Volume Files API for volume ID:

e665554f-d7f6-45ba-b203-1cf5c1d2a860

Could you please verify the internal volume-instance → physical/backing-storage mapping for:

project: dr-uzair-janjua-railway

environment: production

service: web

volume: web-volume

and reconnect/remap the production service to the existing backing storage that contains the files currently visible through "railway volume files"?

Please preserve the existing storage and data.

Please do not:

• delete the volume
• • wipe/reset the volume
• • recreate or replace it with a new empty volume
• • restore over the existing data

The existing files are still accessible through Railway's volume file interface, so data recovery is not the issue. The goal is for the runtime mount at "/uploads" to expose the exact same filesystem currently visible through the Volume Files API.

If useful, I can also provide the production deployment ID and "/proc/self/mountinfo", "df -T /uploads", and "stat /uploads" output from the running container.

Thank you.