This is an example

I removed the caching, re-deploy and it stills complains about that line

Hey there <:salute:1137099685417451530>

I believe this is why it's failing https://github.com/gustavovalverde/zentity/blob/feat/web3-fhevm-integration/apps/web/Dockerfile#L81

Railway only supports --mount=type=cache

The error message could be better, but I think that's the problem.

Oh, I previously had issues with bind mounts, I did not realize that there was also an issue with secrets. So it's basically that the only supported ones are cache (and only with the specific Railway format).

If you enable the Metal Build, it shows a better message:

dockerfile invalid: flag '--mount=type=secret,id=better_auth_secret,required=true' is missing a type=cache argument (other mount types are not supported) at Line 56

That's correct

Thank you @CrisOG!!

Glad to help <:salute:1137099685417451530>

!s

Sorry I closed this too early. Let me know if this works!

My remaining question is if Railway supports build time secrets for Dockerfiles

Yes it does

That specific approach to mount the secret is to avoid the secret being part of the build history, and thus avoiding someone using docker inspect and being able to view it afterwards. So maybe my remaining option is just having a Dockerfile.railway specifically to deploy to Railway; if I'm understanding correctly

We only support environment variables at build time via ARG

Then using secrets through an environment variable is only supported in an unsecure way; considering the --mount=type=secret is not supported.

I understand the concern, and you would be right about it being insecure, but only if you hosted your image on a service like ghcr or Dockerhub, but we are building your image on our build machines and storing it in our private registry that only our machines that run your workloads have access to.

Yes, I do understand that. That's I stated that the workaround for Railway seems to be using an additional Dockerfile (Dockerfile.railway); considering that this image will also be published in other registries.

Yep that would be the best approach.

Perfect. Thank you both!

No problem! anything else I can help with?

All good.