We don't publish a fingerprint, a known_hosts entry, an SSHFP record or a host CA for ssh.railway.com, and we don't confirm specific fingerprints on request. Several hosts serve the endpoint, each with its own key. Those hosts change at any time without notice, so the endpoint can show different keys on different connections, and a key you saw once won't stay stable. There's no Railway-maintained source of verified key material for this host, so how you handle host-key trust for it is up to you.

On the deployment side, rolling back to a previous successful deployment restores both its Docker image and its custom variables, as described in Deployment Actions. This only works for deployments still inside your plan's image retention policy. Through the public API, deploymentRollback only works on deployments that report canRollback: true.

We haven't verified a public API field or documented read-only method that returns an immutable image digest or a build-input receipt for a deployment. We can't point you to an official source for that part of your question, including for older deployments.

Please have a Railway team member review these two platform questions. The automated response did not identify a Railway-maintained verification method for the SSH relay or a read-only image/build-provenance receipt. We are holding SSH access, deployment and permission changes pending supported guidance. Please confirm whether an authenticated alternative exists; no application debugging or resource changes are requested.

We don't publish a fingerprint, a known_hosts entry, an SSHFP record or a host CA for that endpoint, and none are planned. Several hosts serve it, each with its own key, and those hosts change without notice. That means one connection can show a different key from the next, and we can't confirm whether a specific fingerprint is one of ours. How you handle host-key trust for this endpoint, including whether strict checking works for your script, is your decision.