2 months ago
Since ~08:15 UTC on 2026-08-04, every deployment in project
678c5560-8d5a-47c0-be7b-28d051daeecb fails without producing build logs.
buildLogs returns exactly one entry — 'scheduling build on Metal builder
"builder-iljueq"' — and the deployment then goes to FAILED with
deploymentStopped: true, between 90 seconds and 3.5 minutes later. No further
build output is ever emitted, so there is nothing for us to debug.
The last successful build was fd65d1db-8155-4030-ae41-3e93917e845d
(2026-08-02 09:19 UTC), which ran ~15 minutes and produced full logs.
IDs:
Workspace 8da0083b-4b46-4776-b81a-8c0437281d73 (Pro)
Project 678c5560-8d5a-47c0-be7b-28d051daeecb (biopeppers)
Environment 92f95689-e3bb-4e69-8d55-2e8bd15d98ed (production)
Service 6282c4e0-40c5-4dc1-b39f-8fe112876bfa (backend)
Service 57359707-ddab-45e7-93d9-5b9b09fb2405 (storefront)
Failed ad5566b3-6e77-4b3f-863e-363f76a48c3d
50659391-5424-4cae-b5c9-4c41821f2ee7
4c49b98d-42a8-4e3e-948c-ff16d1b6b6f3We have ruled out:
-
Plan / billing: workspace is PRO, customer state ACTIVE, valid default
payment method, banReason null, current usage ~$1.79.
-
Plan limits: builds.concurrent 10, builds.timeout.hard 90. We run one
build at a time.
-
Repo size: 114 tracked files, 18 MB .git.
-
Lockfile:
npm ci --include=devcompletes locally in ~1s with no errors. -
Trigger method: fails identically via GitHub push, via
serviceInstanceDeployV2, and via
railway up --ci. -
Service config: we reverted rootDirectory, buildCommand, preDeployCommand
and railwayConfigFile to the exact values of the last successful
deployment. Still fails.
-
Builder: we switched from RAILPACK to a committed Dockerfile
(dockerfilePath: apps/backend/Dockerfile). It fails identically — one log
line, then FAILED. Two completely different build paths producing the same
failure rules out our build configuration.
Repo: durang/peptid (private), npm workspaces monorepo
(apps/backend = Medusa v2, apps/storefront = Next.js 16).
Question: are builders "builder-iljueq" and "builder-kzovxx" healthy, and is
there a server-side reason our builds are being stopped before they start?
Separate API issue worth flagging: serviceInstanceUpdate silently ignores
null for rootDirectory, railwayConfigFile and buildCommand — it returns true
but does not clear the field. Only "" works. This made it impossible to
restore defaults via the API while isolating this problem.
=== BTW: This looks identical to the recent "Metal builder builder-nhmelg wedged"
thread, which was resolved by reassigning the service to a different Metal
builder. Our builds are being scheduled on builder-iljueq (backend) and
builder-kzovxx (storefront).
Could you either repair those builders, re-route our services to a
different one, or disable Metal builder for this project?
1 Replies
Status changed to Awaiting Railway Response Railway • 2 months ago
2 months ago
Your builders are healthy, this isn't a builder problem. Every deploy fails at the snapshot/config step before the build starts, which is why you get the one "scheduling build" line and nothing after.
Both services have a config-as-code file path set that can't be loaded: backend's railwayConfigFile is apps/backend/railway.json, storefront's is apps/storefront/railway.json, and each fails with service config at '<path>' not found. That check runs before a builder is chosen, so it fails identically on Railpack or a Dockerfile, on any builder. Your last successful build (Aug 2) had this field empty, so setting it is what broke deploys.
Fix: clear railwayConfigFile on both services (set it to "", or clear it in the config-as-code setting). That restores your last working config.
If you want to keep config-as-code, you'll need the root directory pointed at each app folder with the path relative to it. Happy to help set that up.
Status changed to Awaiting User Response Railway • 2 months ago
2 months ago
This thread has been marked as solved automatically due to a lack of recent activity. Please re-open this thread or create a new one if you require further assistance. Thank you!
Status changed to Solved Railway • about 2 months ago