10 months ago
How can I make sure that no cached layers or images are being used when I build my Dockerfile for deployment? Does nixpacks build using a docker build command? (i.e., can I specify --no-cache specifically as part of a custom build command?)
I've already included both "NOCACHE=1" and "NIXPACKSNO_CACHE=1" (found both in online docs/responses) in my environment variables. I don't believe there are any flags or arguments that can be set in the Dockerfile itself.
----- Why am I asking?
Essentially, I'm encountering build errors in railway that I previously saw locally, likely caused by a change in my npm packages (ts project). I fixed those errors locally by deleting saved docker images and node_modules, new npm install and re-building the docker image - no more local issues.
Now encountering the same errors in railway, I'm re-tracing my steps, but realizing a lot happens on railway build that I don't quite understand. I'd like to be certain that I'm re-building the image and layers from scratch.
22 Replies
Update - Railway may be using buildkit and not nixpacks - I'm not entirely certain.
I have a Dockerfile in the project github repo and we auto-deploy to railway based on updates to the 'main' branch. I believe images are being built by Railway and used for deployment since I can see the build occuring in the Railway build logs.
10 months ago
project id please
10 months ago
what service in what environment?
10 months ago
do you mean launchschool-llm?
10 months ago
first off, you are using a dockerfile, so anything nixpacks related to is not applicable
10 months ago
for your context, that variable does exactly what you want, and i can confirm that your build was done without any layer cache

So the docker image used for deployment is always built from scratch with that "NO_CACHE = 1" variable?
10 months ago
yep!
Then I'm stumped…… any other ideas why I would be getting build errors in railway, but no longer in my own local environment?
Is it possible to access a CLI within the environment to confirm install package versions, etc?
10 months ago
yes, but in this case, no, you need something running otherwise there is nothing to ssh into
10 months ago
are you running dockerfile or dockerfile.dev locally?
Typically we run dockerfile.dev for local environments, but I ran the dockerfile locally to test - i.e., built from dockerfile and used that as part of local environment. It seemed to work.
10 months ago
delete the entire project locally, then re-pull it, and try again
FWIW, those same errors are occurring locally again, so there's no escaping the need to get to the root of them.
Thanks for your help!
10 months ago
no problem!
10 months ago
and good luck!