Your builds are being rejected because next@14.2.15 in your package-lock.json matches 2 known HIGH-severity advisories (CVE-2025-55184 and CVE-2025-67779). This scan runs before the build driver, which is why the only visible line in the dashboard is "scheduling build on Metal builder" and switching builders changes nothing. Run npm install next@^14.2.35 locally, commit the updated package-lock.json, and push. Regarding the delete-service API timeouts, we don't have an explanation from the data available here, but the build issue is the priority to resolve first.

Thanks — the security-advisory diagnosis was correct. I upgraded next to 14.2.35 (which contains the complete fix for both CVE-2025-55184 and CVE-2025-67779), committed the updated package-lock.json, and pushed. The build now completes successfully for the first time (deployment 77062f44-274f-436c-91c6-5cb687ff5d42), so that part is resolved.

However, a new problem has appeared at the deploy/runtime stage: after the build succeeds, the deploy logs show only "Mounting volume..." and "Starting Container" and then nothing further — no stdout at all from the container's start command, even though I set the start command to sh -c "set -x; ...; echo ...; ..." which should print immediately regardless of anything else. The public domain returns HTTP 502 "Application failed to respond", and the HTTP logs show "connection dial timeout" trying to reach the container. Most tellingly, CPU_USAGE and MEMORY_USAGE_GB for this service were flat at 0 for the entire hour surrounding both deployment attempts (77062f44-274f-436c-91c6-5cb687ff5d42 and a redeploy 6e1e1dcd-159d-46d1-8261-abcefeab6c48) — meaning the container is never actually allocated any resources despite Railway logging "Starting Container".

This looks like a platform-side failure to actually launch the container after a successful build on this service (still on the Metal builder "builder-egpkfb"), separate from the earlier build-scheduling issue. Could someone check why this specific service/deployment isn't actually starting a running instance despite being marked SUCCESS?

One more data point: I also tried restarting the service (no rebuild) to see if it would recover — this time it got stuck even earlier, at "Mounting volume", and never reached "Starting Container" at all.

I then tried detaching the volume (it's empty — no deployment has ever successfully written to it, so there was no data at risk) via the delete-volume API, just to isolate whether the volume mount itself is the failure point. That call timed out after 180 seconds with no effect — the volume is still attached, unchanged, exactly as before.

This is now the third distinct mutation on this project (delete-service x2 earlier, and now delete-volume) that times out without completing, on top of the container never actually starting after a successful build. All signs point to this specific project/service being stuck in a bad state on Railway's backend (still tied to the Metal builder "builder-egpkfb"), rather than anything in our app, Dockerfile, or config.

Have you tried just starting the application itself instead of running other commands along with it?

looking! I just tested exactly that — set the start command to a bare npm run start with nothing else (no symlink, no migrate, no seed) and redeployed. Same result: deploy logs show only "Mounting volume..." and "Starting Container", HTTP 502 on the public domain, and CPU_USAGE/MEMORY_USAGE_GB flat at 0 for the service the entire time. So it's not our start command — the container isn't being scheduled/launched at all after those two log lines appear, regardless of what it's told to run. I've restored the real start command (with the migrate/seed steps we need) since the simplified version didn't change anything.

Closing the loop with the full resolution, in case it helps someone else.

Your read was right, and so was the community reply above: the original service's volume mount was stuck. Confirmation: I created a second service in the same project, same repo, no volume attached — it built and served traffic immediately. I then attached a brand-new volume to that new service, and it also mounted and served fine. So the app/image/start command were never the problem; it was specifically the original service+volume pairing that was wedged (matching the "one deployment can hold a volume mount at a time" behavior from the volumes docs). That's also almost certainly why delete-volume and delete-service both hung for 180s with no effect on the old service — same stuck record. I've left that original service alone rather than keep fighting it.

Separately: the very first build failures (before any of this) turned out to be a real, distinct issue — Railway's pre-build dependency security-advisory scan was correctly flagging 2 known CVEs in the Next.js version we were pinned to. get-deployment-diagnosis surfaced it plainly once I knew to look: "Your dependencies matched 2 known security advisories." Bumping to next@14.2.35 (the version Next.js's own advisory names as containing the fix) cleared that instantly. Worth checking that field early — it would have saved a lot of time chasing the wrong theory.

One more gotcha for anyone hitting a deployment that reports SUCCESS but 502s forever with zero deploy-log output after "Starting Container": if your start command chains multiple shell commands with && and you set it via the API/dashboard, it needs an explicit sh -c "..." wrapper. Without it, the app silently never starts (no logs at all, container stays up but nothing binds the port) even though Railway reports the deployment as successful. Wrapping it in sh -c fixed it for us, reproducibly across several redeploys.

Thanks again for digging into this — the volume theory was exactly right.