Your sftpgo-railway service still exists in your project and is currently in a sleeping state. Your current billing cycle also shows active disk/volume charges ($1.85), which indicates volume storage is still being used. Per our documentation, downgrading plans does not automatically delete or detach volumes. If a volume had been deleted, you would have received an email with a restoration link (volumes have a 48-hour restoration window before permanent deletion). You may want to check the Backups tab on your service to see if any backups are available, and verify that SFTPGo is correctly reading from the volume mount path when the service wakes up.

Hello,

Since the volume storage charges are still active, this suggests that the volume may still exist, which is reassuring.

However, when SFTPGo starts, all users/files/data appear missing, as if it is using a fresh empty database or storage location.

Could you please help me verify:

the current mount path of the attached volume,

whether the original volume is still correctly attached to the service,

and whether the data is still physically present inside the volume?

It seems possible that SFTPGo is no longer reading from the correct mounted directory after the downgrade or redeployment.

Thank you for your help.

You can ssh into your service to verify the existence of your data.

1. Install and set up railway cli.

2. Right click on your service, then Copy SSH Command.

3. Paste the command you copied in the terminal, and ssh into your service.

This should help you verify whether your files still exist on the attached volume or not.

Thanks for the help. I SSH’d into the SFTPGo service and checked the mounted volume.

The volume is mounted correctly on /var/lib/sftpgo, but it’s almost empty — only SSH host keys and lost+found are present.

I also checked /srv/sftpgo/data, and it’s empty too. My uploaded MP3 files are missing.

SFTPGo is configured with PostgreSQL as the data provider, but the actual MP3 files don’t seem to exist anywhere on the mounted volume anymore.

This makes me think either:

• a new empty volume got attached,
• or the original volume containing the files is no longer attached.

Is there any way to check if an older volume still exists internally or was detached from the service?

You can use railway volume list . See the docs as well you might find something helpful: https://docs.railway.com/cli/volume

What worries me is that I did not manually change anything in the production environment. I wasn’t even connected to production before discovering the issue.

The only notable event was the downgrade from Pro to Hobby. After that, the MP3 files were gone.

I checked:

• the mounted volume,
• the filesystem,
• /srv/sftpgo/data,
• and railway volume list.

The currently attached volume is almost empty (0MB used), which does not match the previous amount of uploaded MP3 data.

That’s why I’m wondering if something may have happened automatically at the infrastructure/platform level rather than from a manual action on my side.

Is there any way to inspect:

• historical deployments,
• previous volume attachments,
• automatic migrations/recreations,
• or internal events related to the volume after the downgrade?