I have already tried redeploying several times (and triggering new builds), but it repeatedly fails right after the Docker image export with the exact same infrastructure error on builder-tlhyeo. But the deployment never actually starts

The phase boundary here is useful: a valid OCI image digest means the Docker build completed. If the deployment never entered Deploy, Network, or Post-deploy, then Railway never started the container, so the application start command, healthcheck, and runtime code have not run yet.

I would capture the two log sides for the exact deployment before changing the Dockerfile again:

railway service status --service <SERVICE> --environment <ENVIRONMENT> --json

railway service logs --service <SERVICE> --environment <ENVIRONMENT> \
  --deployment 0d3dad2e-b1d0-49b2-ae7d-c08ce99ac135 --build --lines 200 --json

railway service logs --service <SERVICE> --environment <ENVIRONMENT> \
  --deployment 0d3dad2e-b1d0-49b2-ae7d-c08ce99ac135 --lines 200 --json

If the build side ends with the published digest and the deploy side is empty, that is strong evidence of a platform handoff failure between the Metal builder/image registry and the deployment scheduler. Rebuilding the same Dockerfile or changing a healthcheck will not address that boundary.

Railway's deployment reference documents the order as Building (create the deployable image) followed by Deploying (pull/start the image), and the slow-deployment guide identifies image pulling as the first Deploy-phase step:

• https://docs.railway.com/deployments/reference
• https://docs.railway.com/deployments/troubleshooting/slow-deployments

After checking https://status.railway.com, trigger one fresh source deployment now. Preserve the last working deployment until the replacement is active. If the fresh deployment again produces an image digest but no deploy logs, send Railway support this exact evidence package:

• all affected deployment IDs and exact UTC timestamps;
• builder ID builder-tlhyeo;
• image and config digests;
• service/environment ID and target region;
• the final build event plus confirmation that deploy logs are empty;
• whether a fresh deployment after the incident window still reproduces.

That gives staff the identifiers needed to trace the registry-to-scheduler handoff. If a fresh deployment succeeds, compare its builder/region and timestamp with the failed runs; that would confirm a transient infrastructure incident rather than an application change.