We're sorry the console has stopped working for you. Your workspace is active and the linked service's latest deployment is running.

Right now, the dashboard console and railway ssh don't work on a service that has Static Outbound IPs turned on, and the error in your screenshot is one of the errors that shows up when that's the case. Could you check whether Static Outbound IPs is enabled on this service? If it is, the workaround is to deploy a separate small service without Static Outbound IPs to use as a jumpbox.

If Static Outbound IPs is off, the problem is with the connection between your computer or network and the service. Troubleshooting your local computer or network is outside what our support covers.

Yes, static outbound ip is turned on, but since those ips are whitelisted from a 3d part service, i can't disable it, otherwise the 3d part service would reject requests from my application.

Thanks for confirming. Since your third-party service allowlists those addresses, keeping Static Outbound IPs on is the right call, because turning it off releases the assigned addresses and turning it back on does not guarantee you get the same ones.

Right now, Railway SSH and the dashboard console are not available on a service that has Static Outbound IPs enabled. The way to keep those IPs and still reach the container is to use a separate small service without Static Outbound IPs as a jumpbox. This needs some setup on your side, so it does not open a shell on the target on its own.

We aim to resolve this incompatibility in the coming weeks, but we can't give a concrete timeline yet.

Wait. It's 6 months I have static ips enabled for that service and i've alway been able to connect to the container. Is some policy changed or what?

You're right that SSH and the dashboard console worked alongside Static Outbound IPs on your service before, and we're sorry this has disrupted your workflow. Right now, though, shell access through Railway SSH and the console isn't available on any service that has Static Outbound IPs enabled.

To keep your allowlisted IPs and still get into the container, you can deploy a separate small service without Static Outbound IPs in the same project as a jumpbox. Getting a shell inside the target that way also needs an SSH server running in the target service's own image, reachable over the private network. We aim to resolve this incompatibility in the coming weeks, but we can't give a concrete timeline yet.

Could you provide some documentation that i can go through to setup the separate service that allow me to ssh to the container with static ips ?

We don't have a step-by-step guide for this setup, but here is what it involves. A jumpbox alone doesn't open a shell inside your service, so your target service needs its own SSH server, built into its image and running alongside your app. That means configuring authentication and an SSH listener that can be reached over the project's private network. You can add it through your build configuration and a new deployment, so you don't need an existing SSH session to install it, and the service keeps its Static Outbound IPs for your third-party traffic.

Next, deploy a separate small service without Static Outbound IPs in the same project and environment, with an SSH client installed. Connect to that service with Railway SSH. From there, use SSH to reach your target service at its private hostname (SERVICE_NAME.railway.internal) on the port your SSH server listens on.

The private networking docs explain how services in the same environment reach each other by internal DNS, which is the connection the jumpbox uses.