19 days ago
Service client-dash. I have a Dockerfile at repo root and a railway.json with {"build":{"builder":"DOCKERFILE","dockerfilePath":"Dockerfile"}}. I removed nixpacks.toml. But the Settings → Build → Builder field reverts to "Railpack (Default)" immediately after every deploy, and build logs show it loading a cached railpack-plan.json and reusing an old image instead of building from the Dockerfile. How do I force this service to use the Dockerfile builder and run a clean (no-cache) build? Is the UI builder field overriding railway.json, or is something caching the Railpack plan?
2 Replies
19 days ago
The dashboard builder field showing "Railpack (Default)" is expected. Config as code overrides the dashboard at deploy time but does not update the dashboard itself, so the UI always reflects the service-level setting, not the railway.json override. Your railway.json with "builder": "DOCKERFILE" will take effect each deploy regardless of what the UI shows. To force a no-cache build, add the environment variable NO_CACHE=1 to the service, trigger a new deploy, and confirm the build logs show "Using detected Dockerfile!".
Status changed to Awaiting User Response Railway • 19 days ago
19 days ago
I did exactly what you said: railway.json is {"build":{"builder":"DOCKERFILE","dockerfilePath":"Dockerfile"}}, committed and pushed to main, and I added NO_CACHE=1. I triggered a fresh deploy. The build log confirms caching is disabled ("🚂 Caching Disabled") — so it's a clean rebuild — but it still shows using build driver nixpacks-v1.41.0 and builds the Nixpacks plan, not "Using detected Dockerfile!". The Dockerfile is at repo root (the log even loads it for the secrets warnings), but the builder never switches to Dockerfile. Why is the railway.json DOCKERFILE override not taking effect on this service?
Status changed to Awaiting Railway Response Railway • 19 days ago
Status changed to Solved ricklocalloom • 19 days ago