To distinguish a code regression from a Railway-specific build issue, compare the last successful commit and first failing commit using the same Node version, package manager and lockfile in an isolated local checkout.

Could you share the exact build command, Node/Vite versions, and the final build-log lines before the stall, with secrets removed? Also, does that same commit build locally?>

A timeout alone doesn’t establish an out-of-memory problem. Those details will help narrow down whether this involves a build plugin, dependency change or the build environment.>

AI-assisted; I haven’t reproduced your project yet.>

Build command: bun install && bun run build (where build = tsc --noEmit && vite build)

Versions in our build environment, from your own build logs:

Bun: 1.1.43

Vite: 7.3.6

Node compat: 22.6.0 (Vite's own startup warning — this is Bun's Node-compat shim version, not a separate Node install)

One real discrepancy worth you checking: our committed bun.lock pins vite@7.3.2, but your build logs show vite@7.3.6 actually running. That's not something we changed — same lockfile, same commit, across every deploy including the one that succeeded. Worth confirming whether your install step is resolving against the lockfile or against the registry fresh each time.

Final log lines before the stall, every time, byte-identical:

transforming...

node_modules/zod/v4/core/regexes.js (74:0): A comment "..." contains an annotation that Rollup cannot interpret due to the position of the comment. The comment will be removed to avoid issues.

node_modules/zod/v4/core/util.js (400:0): A comment "..." contains an annotation that Rollup cannot interpret due to the position of the comment. The comment will be removed to avoid issues.

Then nothing — no further output, no error, until your platform times it out.

Does it build locally? Yes, every time, in ~10-13 seconds, with the committed lockfile and reasonable memory headroom.

One more thing we found and already fixed on our end (pushed as c8bce73): our production build was a single ~2.8MB/799KB-gzip JS chunk with everything bundled together — Vite's own build output was flagging this. We split it into separate vendor chunks (mapbox-gl alone is ~1.8MB). That halves the size of the largest single Rollup/Terser minification pass. We can't prove that's your root cause, but if it's memory pressure on your builder host during that minify step, this should meaningfully help, and it's a legitimate improvement either way.

Thanks, that narrows it down quite a bit.

The Vite version mismatch is the first thing I’d investigate. If the committed lockfile resolves Vite 7.3.2 but Railway is actually running 7.3.6 on the same commit, I’d try making the install strictly immutable/frozen and confirm the build uses exactly the locked dependency graph.

I’d also test the same commit on Railway with minification temporarily disabled. Since the build consistently stops after transformation and local builds complete in ~10–13 seconds, that would help distinguish a dependency/install issue from a Railway resource or minifier stall.

The zod annotation warnings themselves don’t look like the root cause, since they are warnings and the build continues past module transformation locally.

If a frozen install still gives Vite 7.3.6, that would be especially interesting because it would point more strongly to the Railway/Bun build environment rather than your application code.

Ran both tests you suggested. Results below.

1. Frozen install — Vite still resolves to 7.3.6

I set the build command to bun install --frozen-lockfile && tsc --noEmit && vite build (previously it was running bun install without the flag, pulled from our Railway service's build command directly — our railway.json/nixpacks.toml in the repo turned out not to be read by Railway at all for this service, so the flag had never actually been applied before).

With --frozen-lockfile, Vite still resolves to 7.3.6, even though our bun.lock pins @template/web's vite to 7.3.2 exactly. So this isn't an unfrozen/stale install — the frozen install itself resolves to the wrong version.

I pushed it further: I noticed your builder is running Bun 1.1.43 (an old Nix-pinned version), and confirmed locally that Bun 1.1.43 can't parse our bun.lock's format at all — it throws Unknown lockfile version and silently falls back to ignoring it. That looked like a strong candidate explanation for the version drift, so I pinned Bun to a newer version via packageManager in package.json and redeployed. Railway picked it up and used Bun 1.3.0 this time (confirmed in build logs). Vite still resolved to 7.3.6 even with the newer Bun that parses our lockfile correctly.

So: the vite 7.3.2-vs-7.3.6 discrepancy is reproducible with frozen installs on two different Bun versions (1.1.43 and 1.3.0). It's not a stale-install issue and not a Bun-can't-read-our-lockfile issue — something in your build install step is resolving/hoisting vite to 7.3.6 regardless.

1. Minification disabled — build still hangs, at the same point, before minify even starts

Set vite build --minify false and redeployed. The build still hung, and critically, it hung at the exact same spot as every prior failed build: right after Vite emits two warnings about node_modules/zod/v4/core/regexes.js and util.js ("comment Rollup cannot interpret"), during the module transform phase — well before rendering/minification ever starts. So the minifier isn't the bottleneck; the build never gets that far.

Summary across all variants tested

I tried six combinations (Bun 1.1.43 / 1.3.0 × frozen / default install × minified / unminified). Every single one hangs at the identical point — immediately after those two zod warnings, zero further log output until your platform timeout kills it. Nothing I changed moved that line. That consistency across every variable you asked us to isolate points at something in the build container itself stalling during module transform on this dependency graph (we have ~2,065 modules, including mapbox-gl, AI SDK packages, etc.) — not our Vite/Bun version pinning or our minifier config.

Given that, a couple of things I'd ask on your end:

Can you confirm whether this service's build container has a memory or CPU ceiling that could cause a silent hang (rather than a visible OOM kill) during module transform under load?

Any chance you can see what's actually happening on your infra at the point builds stall — the logs on our end just stop with no error.

Happy to run anything else you want isolated — let me know what's next.

Thanks, Tim