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?
Pinned Solution
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
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
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