We don't publish host public keys, SHA-256 fingerprints, a known_hosts entry, an SSHFP record, or a host CA for ssh.railway.com, and none are planned. That means there is no official list to pin against.

Several hosts serve the endpoint, and each one has its own key. Those hosts change regularly without notice, so the fingerprint can differ from one connection to the next, and more than one key can be valid at the same time. We don't guarantee that any host key stays the same for any period.

We also don't have a recommended rotation or known_hosts update procedure. How you handle host key trust for this endpoint is your decision.

Thanks. I still need confirmation from a Railway support engineer. We cannot use TOFU or StrictHostKeyChecking=accept-new for production financial database maintenance. Does Railway provide any supported way to authenticate the specific ssh.railway.com endpoint before first connection—for example an SSH host CA, signed host certificates, an authenticated API returning per-target host keys, or documented fingerprints? If not, what is Railway’s supported method for running a one-off PostgreSQL migration inside the project’s private network with TLS verify-full, without exposing database credentials or weakening TLS verification? No account-specific investigation is needed; please answer as product/security guidance.

We don't offer any of those for ssh.railway.com: no SSH host CA, no signed host certificates, no API that returns host keys, and no published fingerprints. The endpoint is served by multiple hosts, each with its own key, and those keys change without notice. That means there is no supported way to authenticate it before the first connection.

For a one-off migration that runs inside your project's private network without SSH, the documented option is a pre-deploy command on a service in that project. It runs between build and deploy, inside your private network, with access to that service's variables, so database credentials can stay as service variables instead of being handled on a local machine. The command must exit 0 on success. A non-zero exit stops the deployment, and a failed command is not retried. It runs in a separate container with no volumes mounted, and the migration tooling has to be installed in the application image.

Your migration tool's TLS settings, including verify-full, are whatever you configure in that command.

By contrast, railway run executes the command on your local machine with the service's variables injected, so it does not run inside the private network.