Hi Railway team,

I'm seeing what appears to be a per-app inbound bandwidth cap on my service,

but your Specs & Limits docs say inbound network bandwidth is unlimited. Hoping

you can clarify whether there's an undocumented limit or whether something in

my setup is the cause.

Service details:

- Project: pylos-app

- Service: pylos-app-production.up.railway.app

- Region: US West (California)

- Plan: Pro, 32 vCPU / 32 GB RAM

- Stack: FastAPI + gunicorn (-w 1) + uvicorn

What I'm seeing:

Chunked uploads from a browser (1 Gbps symmetric fiber, 38ms RTT to my service)

cap around 14-15 Mbps total throughput. This holds whether I send chunks

sequentially OR in parallel (3 concurrent connections). Each individual chunk

upload takes ~13s sequential or ~42s when 3 are in flight — the math works out

to roughly the same total bandwidth either way.

Comparison test: uploading the same 600 MB file directly to my Bunny.net storage

zone (skipping my Railway service) completes in ~1 minute over the same client

connection. So my pipe is genuinely fast and Bunny's ingress is fast — only the

path through Railway is slow.

Things I've ruled out:

- Client upload bandwidth (verified ~1 Gbps via fast.com upload test)

- Distance/latency (38ms RTT)

- gunicorn worker contention (-w 1 means single-process serial chunk handling

is expected; I tested both sequential and parallel chunk uploads with similar

total throughput)

- HTTP/1.1 vs HTTP/2 (haven't isolated)

Questions:

1. Is there a per-app, per-IP, or per-connection inbound bandwidth limit on

the Pro plan that isn't documented?

2. Is there anything tunable on my service that would raise that limit?

3. If it's a hard platform limit, do higher plans raise it?

4. Any diagnostic info you'd like (X-Railway-Request-Id from a slow request,

container metrics, etc.)?

Happy to provide request IDs, deploy logs, or anything else useful.

Thanks,

Luke

luke@getpylos.com