Railway does not generally impose a special duration limit on WebSocket connections. Railway's networking docs state that WebSockets are exempt from the normal HTTP duration/inactivity limits and can remain open indefinitely.

The important distinction is your Trial type:

Full Trial: full network access.

Limited Trial: restricted outbound network access and only a limited set of outbound ports.

So if your application opens an outbound WebSocket to an external service, first check whether your account is on the Limited Trial. If it is, the destination/port may be blocked even though ordinary HTTP/DNS works. Connecting/verifying your GitHub account or upgrading to Hobby removes that trial networking restriction.

However, the log sequence Starting Container → application starts → Stopping Container is a separate clue. A network-blocked outbound WebSocket should normally produce an application/network error; it should not by itself explain Railway intentionally stopping the entire container.

I would check these in order:

Trial status / remaining credits / expiration. Railway has previously stopped otherwise healthy containers when the Trial period/credits were exhausted.

Full Trial vs Limited Trial. If Limited, outbound networking is restricted.

Deployment logs immediately before Stopping Container. Check whether the main process actually exits. If PID 1 exits successfully, Railway will stop the container even if no error is printed.

Make sure your long-running process stays in the foreground. Do not launch the worker/WebSocket client in the background from a shell script and let the shell exit.

For example, your start command should ultimately exec the long-running process:

exec node app.js

rather than:

node app.js &

If you share the start command / Dockerfile and the few log lines immediately before Stopping Container, that will distinguish an application-process exit from a Railway trial/account shutdown.

So: yes, a Limited Trial can restrict outbound networking, but no, Railway does not generally throttle long-lived WebSockets just because you are on Trial.

I've now confirmed the exact failure pattern with more precision:

My app runs 4 background threads in one process: 3 use REST polling (to api.binance.com / fapi.binance.com), and 1 opens a persistent WebSocket (wss://fstream.binance.com/ws/!forceOrder@arr).

The 3 REST threads work perfectly — they've run continuously for hours, making requests every few minutes with real data returned every time, no interruptions.

The WebSocket thread's on_open handler fires successfully (confirmed via log: "Connected to liquidation stream"), meaning the handshake completes.

After that, it receives zero data indefinitely — no messages, no errors, and critically, no close event either (on_close never fires). It just goes silent forever, even though the same Binance server is clearly reachable (the REST threads prove that).

Meanwhile, the other 3 threads in the same process keep running and posting normally the entire time — so this isn't a container crash or the app process exiting.

This looks like the WebSocket connection is being allowed to open, but data on it is being silently dropped afterward at the network level — rather than being blocked outright (which would normally trigger on_error or on_close).

Could you confirm whether outbound WebSocket data (as opposed to just the initial connection) is restricted or filtered on the Trial plan, and whether upgrading to Hobby would resolve this specifically?