Hey @w1nt3r-eth,

Without a Dockerfile present, Railway uses Nixpacks to build your code from the source. You can control the behavior of Nixpacks using env vars and/or a config file: https://docs.railway.app/guides/build-configuration#nixpacks-options || https://nixpacks.com/docs/configuration/file

If you have the appetite and know-how, I would suggest switching to a Dockerfile though, as it gives you more control over the build phase and leads to faster builds as well.

Thanks @melissa! Dockerfile sounds good to me, and it looks like it does cache layers between the deploys

Ah yes, it does! But yes, Dockerfile is the way to go, and the more you can reduce your image size, the faster your deploys will be

Converted to Dockerfile, but caching is not happening.

I can see CACHED after it's processing FROM node:20, but then it didn't cache the layers where I install node_modules, even though my package.json didn't change. Link to the build

Hrm, yeah I'm seeing the same in a little test I just set up. I'm going to flag to our infra team and see if something is awry. Will keep you posted!

Thank you!

alrighty, just downloaded some wisdom from our lead engineer on the build system.

our fleet of builders scales up/down depending on build volume, so it's not abnormal to see cache misses, especially during times of high volume. basically, to get a cache hit, your build must land on the same builder as the previous build.

I think this is a great bit of info for our docs, so I've created a ticket to add it.

Beyond that, if you need to ensure fast deploys, you may consider setting up a build pipeline to build the image yourself, so you can just deploy directly from the image.

I hope this helps, let me know if you have any questions