Hi Railway community/team,

I’m investigating a historical frontend deployment issue on a Railway-hosted Next.js application.

The deployment itself built successfully and returned HTTP 200, but browser acceptance showed the new frontend markup rendered with a stylesheet equivalent to the previous production globals.css.

We rolled back immediately and production is currently healthy.

We have since reproduced the visual failure locally by intentionally combining the redesigned pages with the legacy stylesheet. This generates the same CSS filename fingerprint seen during the failed production deployment.

However, we have not been able to reproduce the failure on Railway sandbox:

clean redesigned build → correct CSS

same-service old → new transition → correct CSS

transition with inherited Next/Turbopack cache → correct CSS

explicit no-cache build → correct CSS

The failed production build logs also show the source-copy and npm run build steps actually executing rather than simply being marked cached.

The remaining question is whether Railway retains historical build-context/cache/artifact evidence that could show what stylesheet bytes were actually present immediately before next build.

Specifically, can Railway staff recover or inspect for a historical deployment:

the original build/source archive,

the hash/content of app/globals.css inside /app before compilation,

BuildKit/source-copy cache metadata,

Next/Turbopack cache/artifact metadata,

or evidence of a source/build-context/artifact mismatch?

We are trying to distinguish between a historical build-cache transition issue and a build-context/artifact mismatch.

Please do not redeploy or modify production. I can provide the exact Project ID, Service ID, Deployment ID, CSS hashes and full diagnostic report privately to a Railway team member if needed.

Thanks.