Persistent volume mounted in settings but not visible inside running container (fs.existsSync returns false)
pacificstudiopilates
HOBBYOP

18 days ago

I have a persistent volume (backend-storage-EmwY) configured with mount path

/app/backend/storage on the service "pacific-studio-pilates". The volume

settings show it as applied/attached, and the support AI assistant confirms

the directory exists with subfolders. However, my own Node.js code, running

inside the actual live container at startup, checks fs.existsSync('/app/backend/storage')

and fs.existsSync('/data') and both return false on every deploy and restart.

This means the SQLite database never persists — it resets to a fresh/empty

state on every deploy, since the app writes to a path that doesn't actually

exist as a mounted volume inside the running container.

Steps already tried:

  • Deleted old/leftover volumes and recreated a single volume with the correct

    mount path

  • Applied pending settings changes explicitly (saw "staged changes" UI issue

    multiple times)

  • Restarted the service and triggered manual redeploys

  • Verified the mount path string has no typos/whitespace

  • Verified via console.log at app startup (not via __dirname-derived paths,

    but hardcoded absolute paths) that the directory does not exist

Can you check on the infrastructure side whether this volume is actually

attached to the container that's currently running, vs. just showing as

attached in the dashboard?

GitHub repo: https://github.com/pacificstudiopilates/pacific-studio-pilates

My service "pacific-studio-pilates" can only be deployed in these regions:

Virginia, California, Singapore, or Amsterdam (these are the only options

in Settings > Scale > Regions & Replicas). The service is currently set to

US West (California, USA).

However, every time I create a persistent volume for this service, it gets

automatically assigned to "US West (Oregon, USA)" — a region that isn't

even available as an option for the service itself. I tried deleting and

recreating the volume multiple times, and it always defaults to Oregon.

Since the volume's region doesn't match the service's region, the volume

never actually mounts inside the running container, even though the

dashboard shows it as "attached". This matches the original issue I

reported: fs.existsSync() on the configured mount path returns false at

runtime, even right after a fresh deploy.

Is there a way to force the volume to be created in the same region as the

service (California), or is this a known bug with volume region assignment

for this account/project?

Solved$10 Bounty

Pinned Solution

pacificstudiopilates
HOBBYOP

18 days ago

My service "pacific-studio-pilates" can only be deployed in these regions:

Virginia, California, Singapore, or Amsterdam (these are the only options

in Settings > Scale > Regions & Replicas). The service is currently set to

US West (California, USA).

However, every time I create a persistent volume for this service, it gets

automatically assigned to "US West (Oregon, USA)" — a region that isn't

even available as an option for the service itself. I tried deleting and

recreating the volume multiple times, and it always defaults to Oregon.

Since the volume's region doesn't match the service's region, the volume

never actually mounts inside the running container, even though the

dashboard shows it as "attached". This matches the original issue I

reported: fs.existsSync() on the configured mount path returns false at

runtime, even right after a fresh deploy.

Is there a way to force the volume to be created in the same region as the

service (California), or is this a known bug with volume region assignment

for this account/project?

1 Replies

Railway
BOT

18 days ago

This thread has been opened as a bounty so the community can help solve it.

Status changed to Open Railway 18 days ago


pacificstudiopilates
HOBBYOP

18 days ago

My service "pacific-studio-pilates" can only be deployed in these regions:

Virginia, California, Singapore, or Amsterdam (these are the only options

in Settings > Scale > Regions & Replicas). The service is currently set to

US West (California, USA).

However, every time I create a persistent volume for this service, it gets

automatically assigned to "US West (Oregon, USA)" — a region that isn't

even available as an option for the service itself. I tried deleting and

recreating the volume multiple times, and it always defaults to Oregon.

Since the volume's region doesn't match the service's region, the volume

never actually mounts inside the running container, even though the

dashboard shows it as "attached". This matches the original issue I

reported: fs.existsSync() on the configured mount path returns false at

runtime, even right after a fresh deploy.

Is there a way to force the volume to be created in the same region as the

service (California), or is this a known bug with volume region assignment

for this account/project?


Status changed to Solved brody 12 days ago


Welcome!

Sign in to your Railway account to join the conversation.

Loading...