Hi Railway team,

TL;DR

Our containerized LiveKit voice agent fails on Railway because the per-container PID ceiling is set to ≈ 1 000. The agent legitimately needs around 1 000 PIDs at boot on a 32-vCPU Metal host (idle worker processes x Tokio runtime threads). We’re asking to raise pids.max to a higher value (e.g. 8 192 or unlimited, matching Render/GCP) so the workload can run without panicking.

Issue description

Our voice agent warms N = ceil(CPU Cores) subprocesses (using `multiprocessing.forkserver`) to slash cold-start latency. In turn, each subprocess then spins a Rust/Tokio multi-thread runtime (using livekit-rtc, default is 1 worker per host core), in our case (32 vCPUs), that's 32 forks x 32 threads = 1024 PIDs before the first room is handled.

Because railway caps the max PIDs to 1000 (as per this thread https://station.railway.com/questions/how-do-i-use-all-cp-us-bdad33f4, lit "No restrictions. We do limit to 1000 PIDs, but that shouldn't be an issue."), our agent crashes immediately after starting

Requested intervention

We would like to request the railway team to increase the per-container pids.max > 8000 or unlimited. Other platforms such as Render or Heroku already do this (in fact, we tested deploying our agent container there and it worked out of the box).

Alternatively, allow us to set the PID limit per deployment.

In our case, it should be safe because each Tokio thread is lightweight (stack = 2 MiB virtual, ~16 KiB RSS until busy) and also, the agent enforces its own memory/CPU guards (WorkerOptions.job_memory_limit_mb, load shedding) so it won’t oversubscribe the node. But again, other PaaS platforms already do the same, we could migrate but don't want to because we really like railway.

Raising the cap will let us keep low-latency warm pools without rewriting core LiveKit orchestration logic, and keeps Railway feature-par with other hosts.

Happy to provide any additional metrics, flamegraphs, or run a test container if that helps.

Thanks a ton!

Ramón

Edit: we are currently able to deploy a capped version of our agent because we manually set the TOKIO_WORKER_THREADS to prevent reaching the pids.max but it's a hacky solution for something that should work out of the box.