Metal builder fails before visible Dockerfile execution
19 days ago
Project ID:
c18f6da0-e544-440d-bc48-f8e3b630ef36
Service ID:
13025bca-5cc2-4462-bdeb-2871da451dbe
Environment ID:
c5a2a810-06c2-488b-8497-809a5275fb9d
Failed deployment:
a0e69135-7949-48f4-9150-6abe264f057f
Healthy prior deployment:
025ee757-ee7d-4c59-85d9-ac260576330c
Observed Metal builder:
builder-strdom
Configured Dockerfile:
deploy/Dockerfile
We are deploying using:
railway up --no-gitignore --detach
with a committed .railwayignore.
The upload succeeds and Railway creates the deployment record.
The candidate archive is approximately 4.87 MB / 335 files and contains:
- deploy/Dockerfile
- deploy/entrypoint.sh
- deploy/requirements.txt
- deploy/vendor/DEPLOYMENT_MANIFEST.json
- deploy/vendor/estate_c/
- deploy/vendor/wheels/
- api/
- web source
The deployment then transitions to FAILED within a few seconds.
The complete build log is only:
scheduling build on Metal builder "builder-strdom"
scheduling build on Metal builder "builder-strdom"
There is:
- no Dockerfile detection output
- no FROM/COPY/RUN output
- no npm output
- no pip output
- no build error message
- no deploy/runtime log because a container is never provisioned
The same Railway service remains healthy on deployment:
025ee757-ee7d-4c59-85d9-ac260576330c
Could you inspect the internal builder diagnostics for deployment
a0e69135-7949-48f4-9150-6abe264f057f and provide the underlying failure?
If this is a Metal builder/node issue, please reroute or reassign the build.
At present the public log stream does not provide enough information to
determine whether this is an infrastructure failure, hidden Docker/build
error, or log-delivery failure.
1 Replies
Status changed to Awaiting Railway Response Railway • 19 days ago
19 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 19 days ago
18 days ago
The log pattern points to a failure before Dockerfile execution: the only builder output is the Metal scheduling line, while the same service has a known-good prior deployment. That makes the Dockerfile contents and application code unlikely to be the immediate cause.
For an isolation test, keep the source and commit unchanged, disable “Use Metal Build Environment” for this service, and redeploy the same commit with the non-Metal builder. Keep deploy/Dockerfile explicit (for example, set the service Dockerfile path to deploy/Dockerfile in the service configuration). If the same commit builds successfully off Metal, compare failed deployment a0e69135-7949-48f4-9150-6abe264f057f / builder-strdom with successful deployment 025ee757-ee7d-4c59-85d9-ac260576330c and include both in the Railway support request; that is strong evidence of a Metal scheduling, node, or log-attachment issue. If it fails off Metal too, then investigate the root directory, Dockerfile path, and uploaded context.
Because the public log ends before Dockerfile detection, the underlying internal exception can only be confirmed from Railway’s builder diagnostics.