a month ago
Subject: Custom domains + generated Railway subdomains both return "Application not found" despite healthy deployments and valid certs
Project steward (id 3e355bf8-01a6-4f61-99f4-dc5b1bbbaa8b), environment production (id ef09d35d-00de-45e4-8cd0-56ad5772eb3b). Two services — steward-api (id bddd36cc-bd87-45ce-b0f3-1ac744be67d3) and steward-web (id 731751a7-51f5-4bf3-adf2-67f1dee3088c) — both show SUCCESS deployments, are not stopped, and their own logs confirm the app started and is listening on the expected port. Despite that, every domain pointed at them returns Railway's own {"status":"error","code":404,"message":"Application not found"} edge response — not from our application.
The custom domains service.steward.now and www.steward.now were stuck at certificateStatus: VALIDATING_OWNERSHIP for 18+ hours (since 2026-07-07 evening) despite correctly PROPAGATED DNS (CNAMEs to x9u4lqfn.up.railway.app and 8qbhitay.up.railway.app respectively). I called the customDomainIssueCertificate GraphQL mutation on both today, and both transitioned to certificateStatus: VALID (confirmed via the API and via a direct TLS handshake — the served certificate's CN now correctly matches each hostname). However, HTTP requests to both domains still return the 404 "Application not found" edge error.
Critically, the underlying Railway-generated subdomains themselves (https://x9u4lqfn.up.railway.app and https://8qbhitay.up.railway.app) also return this same 404 when hit directly — not just our custom domains. That rules out DNS/cert propagation as the remaining cause and suggests the routing/domain-binding between these generated targets and the running service instances isn't established, separately from the certificate issue. Could you check why edge routing isn't reaching these two service instances despite successful, running deployments?
Pinned Solution
a month ago
You need to add a TXT record for _railway-verify.www.steward.now. If you are using the API to add your custom domain, you can find it in verificationToken under status.
5 Replies
a month ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • about 1 month ago
a month ago
What port is your app listening on and what port are you domains pointing to? Sometimes the app logs will say "Listening on ......" so worth checking that and making sure the domain port lines up. I'm fairly certain this would propagate as a 502 but worth double checking
a month ago
steward-api listens on port 18010 (confirmed in logs: "VPO listening on :18010", and PORT=18010 is set).
steward-web listens on port 13000 (confirmed in logs: "Network: http://...:13000", and PORT=13000 is set).
I also checked our domain configuration via the API — for all four custom domains (steward.now, www.steward.now, service.steward.now, api.steward.now), targetPort comes back as null. That looks like it could be the actual routing gap: nothing is telling the edge which port on the service to forward to. Could you confirm whether targetPort: null is expected to auto-resolve to the app's detected port, or whether we need to explicitly set it to 18010 / 13000 respectively?
a month ago
You need to add a TXT record for _railway-verify.www.steward.now. If you are using the API to add your custom domain, you can find it in verificationToken under status.
a month ago
Ahhh. Didn't do that. I'll report back here when done.
a month ago
That was it. Apparently, I should Read The Friendly Manual ... or have Claude Code do it better. Thank you!!!
Status changed to Open brody • about 1 month ago
Status changed to Solved brody • about 1 month ago