A build that hangs silently right after the copy step and before your build command's output ever appears — with no error text at all — usually points to one of these, roughly in likelihood order:

bun run build is interactive or waiting on stdin. Some build tooling (certain bundlers, or a postinstall/prebuild script chained into build) can prompt for input (e.g. a first-run telemetry opt-in, a missing env var it's waiting to be typed, a CLI update prompt) in a way that just hangs forever in a non-TTY CI environment instead of erroring. Worth checking your package.json "build" script and everything it calls for any tool that might prompt on first run (Vite, some codegen tools, and a few React Router/Remix plugins are known to do this).

Out-of-memory kill with no propagated error. If the build process gets OOM-killed by the container, you sometimes get exactly this signature — silence, then a generic "failed to build" with no build-tool error, because the process was killed before it could flush/report anything. React Router/Vite production builds can spike memory on larger apps. Worth checking if this is a large app and, if you can, temporarily testing on a Railway plan/service with more build memory, or building locally with time bun run build and watching memory to see if it's plausible.

A build step doing a network call that's hanging, not failing — e.g. a font/asset fetch, a CDN check, an analytics/telemetry ping some tool does on build — that has no timeout and just sits open until Railway's own build timeout (~20 min matches typical platform build timeouts) kills the whole thing from outside, which is why your tooling never gets to print an error.

The fastest way to actually see what's stuck: run bun run build locally (or in a plain Docker container matching Railway's environment) and watch it live rather than relying on Railway's captured logs — if it hangs identically locally, you'll see exactly where and can Ctrl+C to get a stack/backtrace of what it was doing. If it does not hang locally, that's useful too — it'd point at something Railway-environment-specific (no network egress to something your build needs, a missing env var only present locally, or the OOM-kill scenario above).

Since Railway's own automatic Diagnosis also failed to explain it, this may need Railway to check whether deployment 93ebc8c7 actually built the full 20 minutes or was silently killed early (OOM or otherwise) — that's something only their build-infra logs would show.

Thanks for the detailed analysis.

One important detail: bun run build / the React Router production build has already completed successfully in the original development environment for this same application. The Railway deployment is where it hangs, after the copy step, until the ~20-minute timeout.

Given that, would you recommend checking Railway build memory/OOM first, or an environment-specific network/variable issue?

Is there a specific Railway setting, build command, or diagnostic change you would recommend trying first to distinguish between these causes without changing the application code?

I’d prefer to make one controlled change at a time.