21 days ago
We are experiencing intermittent Railway SSH connectivity to a deployed service with a persistent volume.
Environment:
- Railway CLI: 5.30.1
- Service is online and available over HTTPS
- Persistent volume is mounted at /app/data
- Registered SSH key is available and accepted
Observed behaviour:
-
Some railway ssh commands connect successfully and return expected output, such as:
/app
-
Other attempts using the same project, service, environment, identity file and network time out with:
ssh: connect to host ssh.railway.com port 22: Connection timed out
-
Test-NetConnection to ssh.railway.com on port 22 has returned:
TcpTestSucceeded: True
-
The issue also occurs when attempting to reconnect to a named Railway SSH session.
This intermittent behaviour prevents us from safely completing read-only verification of the mounted persistent volume. We have stopped all production administration rather than risk an incomplete operation.
Could Railway please confirm:
- whether there is a known SSH routing or deployment-instance issue;
- whether we should explicitly target a deployment instance;
- whether another supported method can run read-only commands against the exact running service and mounted volume;
- whether any additional diagnostics would help identify why some SSH connections succeed while subsequent attempts time out.
The affected project, service, environment and deployment identifiers can be provided privately to Railway staff.
No credentials, tokens, database contents, email data or private keys are included in this public thread.
1 Replies
21 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 21 days ago
20 days ago
This is actually expected behavior with how Railway routes SSH connections, though I get why it's frustrating when it's inconsistent.
The core issue - Railway runs SSH through a load balancer, so each connection attempt can land on a different deployment instance. When it works, you happened to hit an active one. When it times out, you're likely hitting an instance that's mid-cycle or has already been replaced. The TCP test succeeding but SSH still timing out is a classic sign of this - the port is reachable, but the specific backend it routes you to isn't responding.
A few things that might help:
Target a specific deployment instance directly Instead of a plain railway ssh, try:
railway ssh --deployment
You can grab the deployment ID from your Railway dashboard under the Deployments tab. This skips the load balancer routing and pins you to one specific instance, which is way more reliable for what you're doing.
For read-only volume verification specifically If all you need is to inspect files in /app/data, honestly the cleanest way is to temporarily add a small route to your service that reads and returns directory contents, use it, then remove it. Avoids SSH entirely and works every time regardless of instance state.
Named session reconnects The named session issue is the same root cause - if the instance that session was on gets rotated out, reconnecting will fail. There's no persistent session affinity across deploys right now.
If you want to dig deeper, share the deployment ID with Railway support team privately - they can check whether there's a specific routing anomaly on your service.