Project: Groowfy OS

Project ID: 5ec64787-2e97-48c4-9d8c-25a36e9652b0

Environment: production (c2fd1417-988b-42cb-84b7-dc020f958c7e)

Affected service: groowfy-backend (fb02c151-738c-4555-89b1-bbd791c64c6a)

Other service in project: groowfy-frontend (0a15602e-d1b4-47da-aafb-bc536ce1104f)

Problem

Every public request to groowfy-backend — both its custom domain and its Railway-generated domain — returns the static HTML bundle that belongs to groowfy-frontend, instead of reaching the backend's own Node/Fastify app. The response is byte-identical to what groowfy-frontend serves (same Content-Length, same ETag), and comes back with Server: railway-hikari, which we understand is your static-asset edge, not our backend's own HTTP server.

Example (right now):

curl -i https://groowfy-backend-production.up.railway.app/integrations

returns 200 OK, Content-Type: text/html, etag: "78639cef7e38bc98fc6bab609837ae4c30bca6fa", and an HTML document — the exact same document served by:

curl -i https://groowfy-frontend-production.up.railway.app/

groowfy-backend is a Fastify API and has no route that returns HTML, and no static file named like that ETag, so this response cannot be coming from our own app.

What we've already ruled out / tried

Not a code regression: railway logs --service groowfy-backend shows the container booting the real app (Accepting connections at http://localhost:3333, matching backend/Dockerfile's EXPOSE 3333 / CMD ["node","dist/server.js"]) and logging real request/response lines for the exact requests we send.

Not a port misconfiguration: confirmed the service's public network target port is 3333, matching what the app listens on.

Redeploy: triggered a full fresh redeploy of groowfy-backend (deployment 21a994c2-c055-4d77-a1ba-be5f95b99801, created 2026-07-17T22:22:10Z, status SUCCESS). New container, same behavior.

Cache purge: ran purgeServiceCache (scope ALL) against both groowfy-backend and groowfy-frontend via the public GraphQL API. No change.

Custom domain: removed the custom domain api.os.groowfy.com.br from groowfy-backend entirely. The Railway-generated domain (groowfy-backend-production.up.railway.app) still serves groowfy-frontend's content, so this isn't a custom-domain-specific routing issue — it affects the service's public networking as a whole.

Timeline

The two services (groowfy-backend, groowfy-frontend) have been deployed and working correctly together for weeks.

Best estimate is this started around deployment 00ecb518-cc35-4b49-9fdf-4f1002c257dd (created 2026-07-17T19:45:32Z) on groowfy-backend, which shipped new integrations (Canva MCP, Pluggy OpenFinance, WordPress) — nothing in that change touches networking, Dockerfile, or ports.

It has now persisted across two further deployments of groowfy-backend (898bd61b... at 20:44:04Z, 21a994c2... at 22:22:10Z — both status SUCCESS), so it does not look like a per-deployment issue, it looks like something stuck at the edge/routing layer for this service.

Impact

groowfy-backend is completely unreachable from the public internet right now — every request gets groowfy-frontend's static bundle instead of a real API response. This is a production outage for us.

Ask

Could you check the edge/routing configuration for groowfy-backend (service ID fb02c151-738c-4555-89b1-bbd791c64c6a) in project 5ec64787-2e97-48c4-9d8c-25a36e9652b0, environment production (c2fd1417-988b-42cb-84b7-dc020f958c7e)? It appears to be pointing at groowfy-frontend's (0a15602e-d1b4-47da-aafb-bc536ce1104f) static output instead of its own container. Happy to provide any deployment IDs, request IDs, or additional logs you need