an hour ago
Project/service: 10th-cosmos-website
Environment: staging ONLY
We need to preserve existing application data before making infrastructure changes. The staging service currently has no persistent volume, and the /private and /shared-storage directories may contain important application records and uploads.
-
Please independently confirm the official ED25519 SSH host-key fingerprint for ssh.railway.com. Our client observed SHA256:+S1xg92FrnHz6pY3bpkmh1OGtWQGNANXilPzlxA7B1g, which we have NOT accepted or trusted.
-
For
railway service files download, does the CLI use SSH/SFTP or a separate authenticated transport? Does downloading interrupt, restart, or redeploy the running service? -
Can this command capture a consistent snapshot while the application is running? Does it preserve timestamps, permissions, and other metadata? Does Railway provide checksums or a recommended way to verify data integrity?
-
What is the safest supported procedure to back up both directories before attaching a volume or redeploying, without losing existing records, uploads, payment information, or queues?
We have paused SSH access, data export, and infrastructure changes until the fingerprint and transfer behavior are confirmed. Please advise on a safe, non-destructive backup procedure.
1 Replies
an hour ago
We can't confirm or deny any specific host-key fingerprint for ssh.railway.com. The endpoint is served by multiple hosts, each with its own key, and those keys change at any time without notice, so we don't publish a fingerprint list or known_hosts entry. How you handle host-key trust is your decision.
Railway SSH supports SFTP, so standard scp and sftp clients work against ssh.railway.com with an SSH key registered on your account, using the service's domain as the username, and scp -r copies a whole directory. The railway service files download command and the dashboard Console tab's Files panel are other ways to pull files. All of these read files from the running container as it is at that moment; reading files is not a restart or redeploy.
None of these take a point-in-time snapshot, so files written during the copy can be captured mid-change, and we don't provide checksums for transfers. Volume backups are snapshots, but only cover data on a volume.
Because the service has no volume, /private and /shared-storage live on the container's ephemeral filesystem, which is replaced by the next deployment, including the one that attaches a volume. The safe order is to copy both directories off the running container first, then attach the volume and redeploy, then restore the data onto the volume. For a consistent copy, pause writes in your app before copying, and compare checksums you generate yourself (for example sha256sum via railway ssh) against your local copy.
Status changed to Awaiting User Response Railway • about 1 hour ago