Since about 11:14 UTC on 2026-10-01, every build of our service that lands on builder-uwqkzv crashes about 9 seconds into next build. The same code builds fine on a different builder.

Error (identical on every failed build):

Creating an optimized production build ...

[55:0x425b0000] 8982 ms: Scavenge (interleaved) 1310.5 (1347.9) -> 1310.5 (1347.9) MB ... allocation failure;

FATAL ERROR: invalid table size Allocation failed - JavaScript heap out of memory

5: v8::internal::HashTable<v8::internal::NumberDictionary, ...>::Shrink

9: v8::internal::JSObject::AddDataElement

12: v8::internal::Runtime_CreateDataProperty

Next.js build worker exited with code: null and signal: SIGABRT

This is not an ordinary out-of-memory: the heap is only ~1.3 GB when it dies. V8 is overflowing a single object's integer-keyed dictionary.

Which builder each build ran on (environment "dev", service "@teiken/internal"):

03f334af builder-uwqkzv OK (08:32 UTC)

8f634f85 builder-uwqkzv OK (09:28 UTC)

5aad6c0c builder-uwqkzv CRASH (11:14 UTC)

937770ba builder-uwqkzv CRASH

0f968cc0 builder-uwqkzv CRASH

ce953877 builder-uwqkzv CRASH

ef411d37 builder-uwqkzv CRASH (built with NO_CACHE=1, so not a stale build cache)

0a34aab7 builder-ychywe OK (17:58 UTC, already contains every commit from the first failure)

2d81878d builder-uwqkzv CRASH (19:06 UTC)

What we ruled out:

• Our code: the failing commits build cleanly on local macOS and on linux/amd64 in Docker, with the same Node 22.23.2, Next.js 15.5.27 and pnpm 10.10.0.
• Build cache: still crashes with NO_CACHE=1.
• Builder image: the same railpack-v0.40.1 / mise-2026.9.15 on both the passing and failing builds.

Could you check builder-uwqkzv, or move this service's builds off it? Every build of this service has landed on it except one, so a retry doesn't help.