a month ago
Builds fail at the post-compile / page-data step with NO error output. The build reaches "✓ Compiled successfully", runs runAfterProductionCompile, prints "Skipping validation of types", then immediately:
"Build Failed: build daemon returned an error < failed to solve: process '/bin/bash -ol pipefail -c npm run build' did not complete successfully: exit code: 1 >"
No error line is ever printed — the failure is swallowed.
Evidence it's not our code:
- Our
mainbranch builds and deploys SUCCESSFULLY on this same service. - A test branch differing from main by ONE server-side lib file (not imported by any prerendered page) fails at this step.
- Reproduces under BOTH Turbopack and webpack.
- RUST_BACKTRACE=full printed no panic/trace.
- NO_CACHE=1 made no difference.
- Some builds died before
npm run buildeven ran, with the nix-env step taking 1m23s vs ~38s normal.
Stack: Next.js 16.2.4, Node 24, nixpacks v1.41.0, Prisma 5.22. Service dlc-backoffice, US East, Pro plan.
Questions:
- Known build-farm / Metal builder issue today (us-east), or nixpacks v1.41.0 swallowing post-compile errors?
- How do we surface the real error from the post-compile phase? It's not in the build logs.
- Can the build run with more memory / on a different builder to rule out resource/infra cause?
Latest failed deployment: f5f5754c. Compare against our ACTIVE successful main deployment for reference.
2 Replies
a month ago
This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.
Status changed to Open Railway • about 1 month ago
a month ago
i would try: Settings -> Build -> Builder, switch nixpacks to railpack, redeploy your failing branch. Most likely to both fix it and surface a real error (cleaner BuildKit output).
If you stay on nixpacks: use NIXPACKS_NO_CACHE=1 specifically (not NO_CACHE=1) to clear a possibly-corrupted cached build plan.
Your questions:
Check status.railway.app
Surface the error via the Railpack switch, or have staff pull raw builder logs for f5f5754c.
Worth asking staff to compare f5f5754c vs your last good main deploy, but try Railpack first.
If Railpack also fails on that branch, that's the useful result: it isolates the problem to that one lib's deps, not the builder.
a month ago
Solved it — turned out the Next.js static-gen step was spinning up too many workers and OOM-ing the build, which masked the real error. Capping it with experimental.cpus: 1 + workerThreads: false in next.config.ts fixed it. Appreciate the steer toward surfacing the actual error rather than chasing the generic failure. Thanks!
Status changed to Solved digilabscore • about 1 month ago