This is a known failure mode in Railway's Metal build environment, not your Dockerfile. The build gets scheduled onto a specific builder node (builder-cakmku), and that node itself hangs or dies before it ever gets to cloning your repo or running any build steps — which is exactly why the logs stop dead after the "scheduling build" line. It's failing at the scheduler/build-daemon layer, before your config is even touched. That's also why the same Dockerfile that succeeded at 04:40:09 UTC now fails immediately: nothing about your config changed, that specific node did.

Railway's own writeup on their bare-metal build migration is candid about this class of bug — resource contention between the build daemon and per-build workers, DNS/clock issues on individual bare-metal hosts, snapshot upload hiccups — all of which produce exactly this signature: a build that dies with zero compiler output because it never got past scheduling.

None of the fixes below touch your services, DB, variables, or domains:

Cancel the failed deployment and hit Redeploy (not Restart). Node assignment isn't sticky — a fresh deploy attempt is often routed to a different, healthy builder. This is the standard first response Railway staff give for this exact symptom, and it's worked for other users hitting a stuck builder-xxxxx node.

If it keeps failing the same way (possibly landing on the same stuck node), toggle "Metal Builder" off in that service's build settings, then redeploy. This routes the build through the legacy build path, bypassing the stuck node entirely — multiple people have confirmed this gets a deploy through in under a minute when Metal is stuck. You can flip it back on later once the node's healthy again. Worth double-checking the toggle actually held — a few people have seen it silently switch back on.

Check status.railway.com before assuming it's isolated to you. This symptom has coincided with platform-wide incidents before ("Builds and deployments are slow to progress" affecting build machines across all regions) — if that's active right now, redeploying won't reliably help until Railway clears it.

Flag the specific builder ID. The actual fix for the node itself (rather than just routing around it) only happens when Railway engineering sees the ID — post on Central Station or the Discord help channel with builder-cakmku plus your three failed deployment IDs. That's the same info staff have asked for in other threads before manually un-sticking a flagged node.

I’m seeing what appears to be the exact same Metal builder-side failure on builder-cakmku.

My Railway account is verified and on the Hobby plan, but two consecutive deployments fail before any application build step begins.

Details:

• Project ID: 2b934f37-0e16-4891-90e5-87d661f117b2
• Service ID: f76bf2e2-95a9-4149-ab1f-13a10b23a8ee
• Environment ID: 08caa446-842d-4d59-bb56-94294ee062aa
• Original failed deployment: 055e2d5f-bfb5-4cb9-926b-35ee3b201920
• Redeploy attempt: c706c99a-a60b-4a86-b304-e8655639f270
• Builder: builder-cakmku
• Railway CLI: 5.47.2
• Account: verified, Hobby plan active

Both deployments stop immediately after:

scheduling build on Metal builder "builder-cakmku"

There is no Dockerfile execution, no base image pull, no npm/package installation, and no application/compiler output at all.

I also tried exactly one redeploy without changing source code, variables, volume configuration, or service configuration, and it was assigned to the same builder-cakmku and failed with the same signature.

This appears to match the builder-side issue reported in this thread.

Could Railway please investigate builder-cakmku or route this service to a healthy builder?

I can provide any additional deployment metadata if needed.