18 days ago
Details:
Services: production.autora, staging.autora
Root directory: apps/web
Build command: bunx @react-router/dev build
Start command: node build/server/index.js
Critical: Code unchanged, local builds work, previous deployments now fail
Build logs show successful client + SSR builds, but /app/build/server/index.js missing at runtime
Builder image: ghcr.io/railwayapp/railpack-builder:mise-2026.6.11
Request: Pin to previous Railpack version or investigate mise-2026.6.11 regression
I need the Railway support team to:
- Check if mise-2026.6.11 was released today
- Investigate if the build context or root directory handling changed
- Provide a way to pin to the previous working builder version
- Or roll back the builder image globally if this is a widespread issue
Thanks,
Tom
Pinned Solution
17 days ago
Turns out this wasn't a Railpack/Nixpacks issue after all — apologies for the misdirection earlier. The actual root cause was in our own code: our API router used Vite's import.meta.glob() with lazy (eager: false) dynamic imports to load ~150 route modules at server startup, each awaited sequentially. A subset of those dynamic imports were hanging indefinitely at runtime in this Bun-build/Node-run setup, which blocked the entire server from finishing startup — Railway's proxy understandably reported this as "Application failed to respond" since the process never finished initializing.
The fix was switching that glob to eager (eager: true), so all route modules get statically bundled at build time instead of dynamically imported at runtime. No more hanging imports, server starts cleanly every time.
7 Replies
18 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 18 days ago
18 days ago
Hey Tom! That definitely looks like a regression in the latest Railpack release, especially since it’s breaking without any code changes on your end. While the Railway team investigates the global image, you can actually pin your builder to the previous working version manually. Just add the environment variable RAILPACK_VERSION=mise-2026.6.10 (or whatever your last successful build version was) to your service settings and trigger a redeploy. That should bypass the new release and get your SSR builds back up and running right away while they look into the root directory handling bug
18 days ago
Thanks for the suggestion. I tried it but unfortunately still crashing with the same Cannot find module '/app/build/server/index.js' error.
One thing I can't confirm: my build logs in the dashboard don't show any mise- version tag in this attempt (unlike the detailed output Railway's AI agent showed me earlier, which explicitly referenced mise-2026.6.11), so I'm not 100% sure the RAILPACK_VERSION=mise-2026.6.10 variable actually took effect, or if I've got the variable name/format wrong.
Is there a way to confirm in the build log whether the pin applied? Or is there a different variable name/syntax I should be using?
For context - I've also tried Nixpacks (failed differently, defaulted to EOL Node 18) and a custom Dockerfile (build context issues), so at this point I think this needs Railway's infra team directly. Production's been down for a while now, so any help accelerating that would be hugely appreciated.
18 days ago
Railway AI agent confirmed "this env var doesn't control the builder image version" — only the Railway infra team can do this
18 days ago
Ah, damn, sorry to hear that didn't do the trick. You're actually spot on about why it didn't apply, because sometimes Railway doesn't read the Railpack version through a standard environment variable, which is why it likely ignored the tag and kept pulling the broken image
Since your production is down, skip wrestling with the Railpack config and go straight for the fastest escape hatches to get you back online:
First, since you already tried Nixpacks but it defaulted to Node 18, you can easily force it to your current version by adding the environment variable NIXPACKS_NODE_VERSION=22 (or whichever version you use). That should instantly bypass the Railpack bug and build normally
Alternatively, if you want to use that custom Dockerfile, the build context issue on Railway is almost always fixed by checking your Root Directory setting in the service settings. Since your app is in apps/web, make sure Railway is pointed there so it executes the Dockerfile from the correct folder path
18 days ago
Thanks again. I tried NIXPACKS_NODE_VERSION=22 and it did get past the EOL Node 18 issue, build completed successfully (✓ built), but still hit the exact same Cannot find module '/app/build/server/index.js' error at runtime (just running Node 22.19.0 this time).
I also ran a direct test to rule out a source-snapshot-overwrite theory - force-committed the actual built build/ directory into git so it existed before the build even ran. Still crashed identically. So whatever's wiping the build output is happening deeper in Railway's pipeline than anything we can control from config or repo structure.
Really appreciate all the troubleshooting help today.. I think this one needs to sit with Railway's team directly at this point. Will update here once I hear back from support.
tomballard92
Thanks again. I tried NIXPACKS_NODE_VERSION=22 and it did get past the EOL Node 18 issue, build completed successfully (✓ built), but still hit the exact same Cannot find module '/app/build/server/index.js' error at runtime (just running Node 22.19.0 this time). I also ran a direct test to rule out a source-snapshot-overwrite theory - force-committed the actual built build/ directory into git so it existed before the build even ran. Still crashed identically. So whatever's wiping the build output is happening deeper in Railway's pipeline than anything we can control from config or repo structure. Really appreciate all the troubleshooting help today.. I think this one needs to sit with Railway's team directly at this point. Will update here once I hear back from support.
18 days ago
Fingers crossed the support team jumps on this quickly and gets your production back up. Thanks for dropping the updates here, and best of luck!
17 days ago
Turns out this wasn't a Railpack/Nixpacks issue after all — apologies for the misdirection earlier. The actual root cause was in our own code: our API router used Vite's import.meta.glob() with lazy (eager: false) dynamic imports to load ~150 route modules at server startup, each awaited sequentially. A subset of those dynamic imports were hanging indefinitely at runtime in this Bun-build/Node-run setup, which blocked the entire server from finishing startup — Railway's proxy understandably reported this as "Application failed to respond" since the process never finished initializing.
The fix was switching that glob to eager (eager: true), so all route modules get statically bundled at build time instead of dynamically imported at runtime. No more hanging imports, server starts cleanly every time.
Status changed to Solved passos • 17 days ago