Can you share the Full Build Logs here?

Hey — your A/B already proves this: cache-on hangs at the Next.js banner; NO_CACHE=1 succeeds in ~5–7 min; removing it reproduces the hang. That matches Railway’s documented build-layer cache, not a bad next.config.js.

What Railway documents

By default Railway caches build layers. To disable that for a service, set:

NO_CACHE=1

on the service Variables and redeploy (Build Configuration → Disable build layer caching).

Docs also note cache hits are not guaranteed because the build fleet scales — cold vs warm is expected (Why isn’t my build using cache?). Your case is the other mode: a warm/stuck layer set that never progresses, which a no-cache build bypasses.

Practical recovery

1. Keep NO_CACHE=1 long enough to ship (SUCCESS on 08e867e0-…).
2. Optionally remove it later and watch one deploy. If the hang returns at the same banner line, put NO_CACHE=1 back — that variable is the documented lever; there is no separate “purge cache” control.
3. For speed + reliability long-term, docs suggest building the image in your own pipeline and deploying the image directly (same section).
4. The unrecognized-key warning in next.config.js appearing in both cache and no-cache builds is a red herring for the hang.

If it still stalls with NO_CACHE=1

Share full build logs for a hanging (cache-on) deploy vs a successful no-cache one. The IDs you listed already show the pattern.

Supported, documented fix for a stuck layer cache: NO_CACHE=1.

Your A/B test is strong enough to isolate this to Railway’s build-cache path rather than the Next.js application itself. Railway officially documents NO_CACHE=1 as the switch that disables build-layer caching, and your result is repeatable in both directions: cached builds hang at the same point, while NO_CACHE=1 builds complete in 5–7 minutes. The unrelated source change reproducing the hang after cache was re-enabled also makes a source/config regression much less likely. Railway’s Docker build documentation shows that cache mounts are service-specific, using IDs in the form s/-, which is consistent with one service retaining a bad cache while otherwise equivalent builds remain healthy. I would keep NO_CACHE=1 enabled as the production workaround for now rather than repeatedly burning 40-minute build attempts. Since Railway does not currently document a user-facing command for purging Railpack’s persistent build-layer cache for a single service, the useful next step for Railway staff is to invalidate/recreate the cache associated with service 87c7d3a3-8719-4378-9474-2a3cac7a9725. I’d also attach the full log from one cached failure and the successful NO_CACHE deployment, as requested above, so they can compare the generated build plan and cache-mount setup. If Railway resets that service cache and the next cached build succeeds, that would directly confirm the diagnosis. If it still hangs after a fresh service cache, then the next useful isolation would be the individual cache targets such as .next/cache versus node_modules/.cache rather than changing application code.