Your workspace is currently in an INACTIVE state, which is why the edge proxy returns 502 on every request even though your app is running correctly inside the container. The app itself is not the problem. You can check and resolve your subscription status at your workspace billing page, which should restore traffic routing to your services.

I've added a payment method to my account (card on file now) and redeployed the service, but I'm still getting 502 "Application failed to respond" on every request. The suggested fix (adding a payment method to resolve the inactive workspace) didn't resolve the issue.

Your workspace is still in an INACTIVE state. Adding a payment method verified your card (the $1 hold was released), but it did not start a subscription. To activate the Hobby plan, you need to subscribe from your workspace billing page, which will create the subscription and restore traffic to your services.

I've now subscribed to the Hobby plan (confirmed active in Billing — payment of $5.00 went through successfully on July 20, 2026), but the public domain is still returning 502 "Application failed to respond" on every request. Both suggested fixes (adding a payment method, then subscribing to Hobby) have not resolved the issue. Could a human take a look at this? Happy to provide any logs, deployment IDs, or screenshots needed.

Make sure you bind the address to 0.0.0.0 and set the public networking port same as your app listening to

As the docs said, uvicorn need additional configuration to listen on 0.0.0.0

You can try add uvicorn main:app --host 0.0.0.0 --port $PORT to your start command

Thanks for taking a look! To clarify, host binding isn't the issue here — the app was originally on 0.0.0.0 and that also returned 502. I later switched it to double colon (dual-stack, which covers 0.0.0.0 behavior too) per Railway's own docs on IPv6 edge routing, and it made no difference either way. The target port has also been correctly set to match the app's listening port throughout (confirmed via the Networking settings, same as the screenshot above).

The actual diagnosis, from Railway's own automated assistant earlier in this thread, was that my workspace was in an INACTIVE state, which was blocking all edge traffic regardless of app config. I added a payment method and then subscribed to the Hobby plan (confirmed active, $5 charged successfully on July 20). But the public domain is still returning 502 "Application failed to respond" on every request, even though the container itself is confirmed healthy (verified via curl from inside the container through the Railway Console, returning 200).

So the sequence of suggested fixes (host binding, payment method, Hobby subscription) has all been tried and none resolved it. Could someone from the Railway team take a direct look at the account/workspace routing state? Happy to share deployment IDs or any logs needed.

Did you try redeploy after upgrading to Hobby plan? if its still didnt work, maybe try deploy a simple Hello World app to check if its an application issue or workspace issue

Did both of your suggestions, and this narrows it down a lot:

1.Explicit redeploy after the Hobby upgrade: no change, still 502 on every request.

2.Deployed a plain Node "Hello World" template as a second service in the same project/workspace (node-hello-world-production-fe4f.up.railway.app) — it returns 200 immediately, no issues at all.

So the workspace itself is clearly not blocked anymore. The problem is isolated to this one service specifically. I compared every setting side by side with the working Hello World service in the same project:

Scale: both at the same resource allocation (8 vCPU / 8 GB, the plan max)

Edge: Under Attack Mode off, CDN Caching off, same as Hello World

Deploy: no custom start command, Teardown off, no cron schedule, empty Healthcheck Path, Serverless off, Restart Policy "On Failure" (10 retries) — all defaults, identical category of settings as Hello World

Config-as-code: no railway.json/railway.toml in the repo at all

Networking: target port matches the app's actual listening port (confirmed via container-internal curl returning 200)

The only real difference is the app itself: Python/FastAPI + Uvicorn in a Dockerfile, with a Playwright/Chromium-based background job (APScheduler) versus Hello World's plain Node process. Deploy logs consistently show the app starting cleanly ("Uvicorn running on http://[::]:8000", "Application startup complete"), and a curl from inside the container via the Railway Console returns 200 with the correct body every time. But the public domain still 502s on every external request, every time, regardless of load.

Given everything on my side checks out identically to a working service, could someone look at this from the edge/proxy side specifically for this service ID? Happy to share the service ID, deployment IDs, or anything else needed.

Your log show Uvicorn running on http://[::]:8000 so your app is still listening to IPv6, do you have hostname set explicitly in your code or environment variables? if so, you need to change it to 0.0.0.0 so your app will be accessible through to public url, do you have start command set like i suggest before?

Since you said that you dont have start command set, try add uvicorn main:app --host 0.0.0.0 on your start command to change the hostname

Following up on this thread: I subscribed to the Hobby plan specifically because your own assistant told me the workspace was in an INACTIVE state and that subscribing would restore traffic to my services. I went ahead and paid the five dollar charge on July 20 on that basis.

The 502 never actually resolved. I spent significant additional time afterward working through community suggestions (redeploying, testing host bindings, deploying a Hello World service to isolate the problem) and even recreated the service from scratch, all while already on the paid plan. None of it fixed the underlying issue, and at this point I've moved the workload to a different host entirely.

Since the paid upgrade was suggested as the fix and didn't deliver what was promised, could you refund the five dollar Hobby charge from July 20? Happy to provide the invoice or transaction ID if needed.

You can Request Refund your last transaction on your billing page

Just want to double check, does the start command didn't work?