Since the build fails immediately after scheduling build on Metal builder and never reaches clone/Docker execution, the Dockerfile syntax alone is not enough to diagnose this.

Railway has had several failures with this exact signature, and they fall into two main buckets:

a Metal builder/node failure before the build actually starts;

an early Railway validation/source error that is shown in Deployment → Details but not in the build log.

First, open the failed deployment and check Details carefully for errors such as:

repository not found / not authorized;

unsupported Dockerfile directive;

source/root-directory resolution error;

infrastructure/build initialization error.

If Details contains no actionable error and the only build log remains the single scheduling build on Metal builder ... line, then this is consistent with a Metal-builder initialization failure.

In that case, try:

cancel the failed deployment and redeploy the source;

if it fails identically, temporarily disable Metal Builder for the service and redeploy;

if the non-Metal build succeeds with the same source/Dockerfile, that isolates the issue to the Metal builder path and Railway should inspect the assigned builder for service 943f30db-eeaf-4c81-a39b-8417d7624277.

Railway staff have previously recommended disabling Metal Builder as a workaround when builds die at the scheduling stage with no output.

I would not rewrite the Dockerfile yet unless Deployment → Details exposes a concrete Dockerfile/configuration error.