Your observatory-volume is still attached to the observatory service. The failed build happened before anything started, so it did not run your app or touch the volume. The volume stays as it is unless you delete it or detach it yourself.

There is no way to download the volume's files while the service has no active deployment. Our CLI file commands for volumes go through the service the volume is attached to, and that service has to have a running deployment. We don't have a supported way to export the volume's contents on their own, to attach it to a temporary recovery service for this, or to do the extraction for you.

The snapshot failed to build because of the VOLUME line in its Dockerfile. No build will succeed until that line is removed.

Thanks for confirming that the volume remains intact.

Since the original snapshot cannot build due to the unsupported VOLUME instruction, can I deploy a minimal custom recovery container to the existing observatory service using a new Dockerfile that does not contain that instruction?

My intention is to:

• Keep the existing observatory-volume attached at /data.
• Run only a harmless, long-running recovery container, without starting the Observatory application.
• Export the volume's contents and verify the recovered data.
• Stop the recovery deployment after the export.

Would this approach work with Railway's volume attachment and deployment behavior? Are there any risks of losing or resetting the existing volume when replacing the service's build source?

I want to avoid any action that could delete, recreate, or overwrite the volume.

Yes, that approach fits how volumes work. A volume keeps its data between deployments of the service it is attached to, so deploying a new image or Dockerfile to the observatory service leaves observatory-volume attached at /data and does not reformat or recreate it. The volume is only removed if you delete or detach it yourself.

Once the recovery container has an active deployment, you can pull the files off it with railway volume browse or the railway volume files commands, or with scp -r / sftp against ssh.railway.com after registering an SSH key on your account. Keep the container's command to something idle like sleep infinity so nothing writes to /data.

One thing to know: a service with a volume only runs one deployment at a time, so deploying the recovery image replaces any earlier deployment rather than running alongside it.