a month ago
Build fails silently after service config change — Metal builder ignores updated rootDirectory
Problem: After updating a service's rootDirectory configuration in a monorepo setup, every deployment attempt fails at the BUILD_IMAGE stage within 7-8 seconds with zero build logs beyond "scheduling build on Metal builder". The deployments repeatedly replay the same frozen commit instead of fetching the current main HEAD.
Setup:
Monorepo: ludido-org/Ludido-Website
Service: ludicopilot
Old path: apps/ludicopilot (no longer exists in the repo, removed 11 days ago)
New path: apps/copilote (correct, updated in service config today)
Branch: main
What's been tried:
Updated service config: rootDirectory and watchPatterns now correctly point to apps/copilote ✅ (verified applied via API)
Triggered fresh deployments without specifying commitSha to force HEAD fetch ❌ (all fail identically)
Modified config params (e.g., healthcheckTimeout) to force builder refresh ❌ (no effect — builder snapshot still shows old rootDirectory)
Added NO_CACHE=1 variable (common workaround for cache issues) ❌ (no effect — same failure pattern)
Symptoms:
Service config is correct, but deployment snapshots show the old rootDirectory: "apps/ludicopilot"
All recent deployments (10+ attempts) report the same frozen commit a7354881cd533ac2221b85a54f1bc296dbce6ad3
Build logs return only: "scheduling build on Metal builder" → silence → failure (7-8 sec total)
No git operations logged, no build command output, no error details
The Metal builder appears to be using a stale snapshot or cache that ignores service config updates
Question: Has anyone encountered this? Is this a known issue with the Metal builder not respecting config updates in monorepos? Any workarounds beyond NO_CACHE=1?
2 Replies
a month ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • about 1 month ago
a month ago
IIRC, changes made via API will be staged before it get applied and need to be committed to take effect, Did you call environmentPatchCommitStaged after updating the Root Directory via API?
If everything is set correctly and it still show the old root directory, Try Deploy Latest Commit from the Command Palette (Ctrl+K)
a month ago
Summary
A service is stuck in a failed build state where the Metal builder accepts the job
but never produces any build output.
Symptoms
- Service deployment triggers successfully
- Build logs show only:
scheduling build on Metal builder "builder-[id]" - No subsequent build output (npm install, compilation, etc.)
- Build fails silently after ~7-8 seconds with no error message
- Service configuration appears correct (rootDirectory, railway.json, watchPatterns)
What's been verified
- ✅ Service config is correct: rootDirectory set to the right path
- ✅ railway.json exists in the correct location and specifies proper build/deploy commands
- ✅ No conflicting config-as-code files overriding settings
- ✅ Same repo + branch work fine on other services in the project
- ✅ Repo is properly connected with correct branch
Context
- Monorepo with multiple services
- A sibling service on the same repo, same branch deploys successfully
- This suggests the issue is not repo/branch connectivity but Metal builder assignment
What would help
Access to the specific deployment to check:
- Metal builder logs on the infrastructure side
- Whether the builder ever received/processed the snapshot
- Any infrastructure-level issues with the assigned Metal builder instance
This appears to be a Railway platform issue rather than user misconfiguration.
==
Specific deployment details for investigation
- Project ID: d227e569-afc9-4895-86f7-52aca9d22857
- Environment: production (f8337a50-89c7-4f3c-b9a4-4e6c50e4cfa2)
- Service: ludicopilot
- Recent failed deployment ID: 2bd4165e-c24c-4061-913d-7db91e7daa13
- Repository: ludido-org/Ludido-Website (main branch)
- rootDirectory: apps/copilote
- Build command: npx expo export --platform web --output-dir dist-web && npm run server:build
- Start command: npm run server:prod
Comparison (for context)
The sibling service "ludido-web" on the same repo/branch deploys successfully,
ruling out repo-level issues. Only ludicopilot encounters the Metal builder stall.