Deployments build successfully and the container runs cleanly (confirmed via logs — no crashes, correct port binding), but the platform edge (railway-hikari) returns a synthetic HTTP 404 (empty/tiny body, never reaches the app) for every HTTP request, on both custom and *.up.railway.app domains. This is reproducible across 3 different services, 2 different projects, and 2 different HTTP server implementations. One sibling service in the same project (backend/Express) works normally throughout.

Affected resources:

Project: pedexpress-teste (ID: 5861a219-ed52-4778-aa84-1ba001bba544)

Environment: production (ID: a1eb438d-1eca-4692-9905-c5cfbed8868a)

Service frontend (ID: f9dbba47-c477-4990-8d86-a011389e0c7a), domain teste.pedexpress.store

Service frontend-v2 (ID: 23a79978-349e-4580-8796-73df1edbf346), domain frontend-v2-production-32e9.up.railway.app

Isolated test project pedexpress-routing-test (ID: 291389b1-47b9-458a-a49f-210d69ecd5b7), service frontend-test (ID: 5c98e24d-1d0f-4a6c-b799-78994e2aecd9), domain frontend-test-production-a714.up.railway.app

Working control for comparison: service backend in pedexpress-teste, domain api.teste.pedexpress.store — works correctly (200 OK, real JSON response) throughout all testing.

Reproduction:

curl -v https://teste.pedexpress.store/

curl -v https://frontend-v2-production-32e9.up.railway.app/

curl -v https://frontend-test-production-a714.up.railway.app/

All three return:

HTTP/1.1 404 Not Found

Server: cloudflare (custom domain) / railway-hikari (native domain)

x-hikari-trace: gru1.xxxx

x-railway-edge: gru1

with an essentially empty body (~5 bytes), while the corresponding deployment's runtime logs show the container started cleanly and is listening on the correct port (8080), with zero incoming request log lines, indicating the edge never forwards the request to the container at all.

Actions already taken (none resolved the issue):

Corrected the frontend service's Root Directory from frontend to . (monorepo root) — confirmed applied via deployment metadata (rootDirectory: "."), build then correctly installed all monorepo workspaces (484 packages) instead of just the frontend subfolder.

Multiple railway redeploy attempts after the fix — builds succeed, edge still 404.

Reconnected the GitHub source for frontend (same repo/branch) to rule out a stuck build snapshot — new snapshot hash confirmed fetched, build succeeds, edge still 404.

Restarted the frontend service — confirmed clean container restart via logs, edge still 404.

Deleted and recreated the custom domain teste.pedexpress.store — new CNAME target issued and DNS updated accordingly, edge still 404.

Created a brand-new service frontend-v2 in the same project, same repo/branch, fresh Railway-provided domain, explicit targetPort set to match the app's actual listening port (8080) — edge still 404.

Tested two different HTTP server implementations on frontend-v2 (vite preview and the serve npm package) — both confirmed running cleanly per logs, both still get edge 404.

Created an entirely new, isolated project (pedexpress-routing-test) with a single fresh service, to rule out project-level state corruption — same 404 behavior reproduced there too.

Waited 15+ minutes after fresh domain creation to rule out DNS/CDN propagation delay — no change.

What works: the backend service in the same project/environment (plain Express app) has responded correctly (200 OK) on every test throughout this entire investigation, using the same Root Directory (null/repo root), same region (ams), same port convention ($PORT → 8080), and the same edge (gru1/hikari).

Question for support: Given that the container is confirmed healthy and listening correctly, and this reproduces across multiple services and even a brand-new isolated project, this looks like a platform-side edge/routing issue rather than anything fixable from our side via CLI or dashboard. Could you investigate why the edge (hikari) is not forwarding traffic to these specific deployments? Happy to share deployment IDs on request:

frontend deploy: 5c557af3-caa1-441a-9100-09a4b6310f4e

frontend-v2 deploy: cce5176f-ad96-4ad0-b741-72aea9d36d3e

frontend-test deploy: 8570a35d-90ea-4de7-aed9-f38d378f496b