Hey there! We've found the following might help you get unblocked faster:

• 🧵 runaway postgresql database volume

• 🧵 SQLite Database Not Persistent

• 🧵 Sveltekit SQLite Migrations Volume

• 🧵 how to export a sqlite db in a volume

If you find the answer from one of these, please let us know by solving the thread!

Just to make sure I understand correctly:

1. You uploaded a SQLite database into a volume

2. You're now using that volume in a service

3. You can make changes but upon redeploy the changes aren't saved and instead the original uploaded data from step 1 appears again

   Is that right?

• We did NOT upload a DB file. We expect the app to use a volume-mounted path.

• Service: te3 (production)

• Volume: te3-volume, mountPath: /data, attached to service (shown in UI)

• Env vars: DATABASE_PATH=/data/database.sqlite, UPLOAD_PATH=/data/uploads

Problem:

• Inside the running service, /data is missing even after attach.

• railway run --service te3 ls -la /data -> “No such file or directory”

• Volume page shows attached, 0MB used.

• Because /data isn’t mounted, the app falls back to the repo path (process.cwd()/database.sqlite), so after each deploy it resets to local contents.

Ask:

• Why is the attached volume (te3-volume, mount /data) not mounted inside the te3 container at runtime?

• Can you ensure the volume is actually mounted for the te3 service in production so /data exists?

Because /data isn’t mounted, the app falls back to the repo path (process.cwd()/database.sqlite)

Could you explain how this behaviour works under the hood? How do you detect whether /data is mounted or not?

railway run --service te3 ls -la /data -> “No such file or directory”

railway run runs a command locally on your machine, not in the deployment, so this behaviour is expected

prone to errors. It appears to be installed. But are these settings correct?

Is your program set to use these variables explicitly? Can you share the code?

They look correct, I'm just curious on how you're detecting whether the volume is mounted or not? From what you say when the volume isn't detected it falls back to a file in cwd but how do identify whether the volume is mounted or not? My thinking is the detection for the volume may be flawed causing the app to incorrectly assume the volume isn't mounted when in actuality it is

Sorry, it was my mistake. I saved some data as .json instead of db. Thank you for your interest.