Service: web, project bellima-backend. Both api.bellima.ci and fwupco34.up.railway.app return 404 with body {"status":"error","code":404,"message":"Application not found"} and headers x-railway-fallback: true, server: railway-hikari, x-railway-edge: cdg1.

Confirmed correct on our side: Deployment SUCCESS (latest id c46e6791-4a45-42e8-aec0-79d9421d3166), service Online, replica 1/1 running, no warnings/criticals. Domain status: verified true, certificate VALID, DNS CNAME PROPAGATED, targetPort 8000 (matches gunicorn's actual bind port and the PORT env var).

Connected via the dashboard Console directly into the running container: a request to http://127.0.0.1:8000/ with Host: api.bellima.ci returns HTTP 200 with the correct JSON body. So the app itself is proven healthy end to end. Region is iad (US East, numReplicas 1); the 404 response's edge PoP is cdg1 (Paris).

Already tried without effect: setting PORT=8000 explicitly, setting the custom domain's target port to 8000 explicitly (it was previously null), a full redeploy to force edge re-registration, and waiting several minutes between checks (not a transient blip, consistently 404).

I found a similar resolved thread here on Central Station titled "Railway-generated domain returns x-railway-fallback 404 - route missing" where the root cause was a stale/orphaned domain-to-service binding after the underlying service had been recreated. That may be relevant here too: this project's "web" service was deleted and rebuilt from scratch on this account earlier during setup, so the custom domain object (id e838bca7-1e0a-4aa2-a5a5-dc7d56fbba27) may still be bound to a stale internal routing reference rather than the current live deployment, even though the dashboard shows it correctly attached.

Could someone check the Hikari hostname-to-deployment mapping for this custom domain and the associated generated domain, and re-sync/rebind it to the current service if it's stale? Happy to provide any further diagnostics needed.