Your label-studio service has no persistent volume attached, so all data (the SQLite database, uploads, annotations) was stored on the deployment's ephemeral filesystem. Ephemeral storage is discarded when a deployment is replaced, and that data is not recoverable. Going forward, you can attach a volume to the service so that writes to disk persist across deployments, and optionally enable volume backups for an additional safety net.

Thank you for the automated response. I understand that ephemeral storage is not persistent and that recovery is not guaranteed.

However, this specific deployment was replaced only today, and the Railway deployment logs confirm that it was still serving the SQLite-backed Label Studio project, annotations, and uploaded files until approximately 01:12 KST.

I am not asking about the general ephemeral-storage policy. Could a Railway staff member please urgently verify whether the removed deployment's host filesystem, container disk, or any pre-removal snapshot/cache still exists before garbage collection? Please check specifically for removed deployment e78300a3-15b6-417b-a5a5-fe73753706d2 and confirm whether any best-effort recovery or snapshot of /label-studio/data is technically possible.

Please avoid purging any remaining storage associated with that deployment while this is being checked. I would appreciate confirmation from a human Railway engineer.

We've confirmed that the label-studio service has no persistent volume attached, so all data lived on the deployment's ephemeral filesystem. Ephemeral storage is tied to the lifecycle of each deployment and is not retained after a deployment is replaced, regardless of how recently the replacement occurred. There is no recovery path available for this data. For future protection, you can attach a volume to the service so data persists across deployments, and optionally enable volume backups.