7 months ago
I'm experiencing a persistent issue where Railway continues to use Nixpacks despite having:
1. A Dockerfile in the repository root
2. railway.toml with explicit configuration:
[build]
builder = "DOCKERFILE"
dockerfilePath = "Dockerfile"
3. Environment variable RAILWAY_DOCKERFILE_PATH=./Dockerfile set via Railway CLI
4. Multiple git pushes with these configurations
Build logs consistently show:
==============
Using Nixpacks
==============
Even though the logs also show [internal] load build definition from Dockerfile, Railway is actually building with Nixpacks (I can see it running nix-env, Nixpacks stages, etc.).
What I've Tried:
- Removing railway.toml to use UI settings (didn't work)
- Adding railway.toml back with explicit builder = "DOCKERFILE" (didn't work)
- Setting RAILWAY_DOCKERFILE_PATH environment variable (didn't work)
- Multiple code pushes to trigger fresh builds (didn't work)
Question:
Is there a Railway build cache that locks in the builder decision? How can I force Railway to actually use my Dockerfile instead of Nixpacks? Is there a way to completely reset the build cache or service configuration?
2 Replies
7 months ago
Hey there! We've found the following might help you get unblocked faster:
- 🧵 Canvas Deployment Issue on Railway + Node.js 22
- 🧵 Railway using cached Dockerfile despite .dockerignore
- 🧵 Using pyproject.toml or multistage Dockerfile
If you find the answer from one of these, please let us know by solving the thread!
7 months ago
Hey, Railway should automatically detect your Dockerfile and list it as such if there is one. Since you mentioned that you have already tried to set it manually, I would suggest you to provide a MRE or your repository so that I can take a look and debug it. You may also want to deploy another service using the same repository to see if you can reliably reproduce this behavior.