I see now that disabling the metal build environment resolves this, but leaving this open in case anyone has insight into the root cause affecting metal builders.

how to do that ?

I has the same issue

@momadacoding -- select your service in the canvas, select "settings" scroll down to the "build" section, and un-toggle "use metal build environment".

Note that I saw a weird issue this morning where this was unexpectedly re-enabled (without any action on my part) and I had to disable it again to get builds to work again.

I would recommend looking into why your application fails to build on Metal (perhaps you are still using the deprecated Nixpacks builder?). We are rolling out the Metal builder to all users and will soon remove the option to switch it off.

@brody, I'm using Railpack with npm run build as a custom build command. Can you provide any more insight here? I have to disable metal daily at this point, with no insight from the system on why builds are failing.

Editing to confirm that metal builds reenable themselves multiple times per day after being disabled each time. I only learn about it silently when the build fails, which doesn't even produce a crash notification. What is going on here?

Looks like you are missing a Dockerfile at the correct location.

I'm using Railpack. I've never needed a Dockerfile prior, and in fact your docs state that this is an explicit goal of Railpack: "The philosophy behind Railpack is to abstract away the need to manage Dockerfiles entirely" (your docs, see screenshot). My impression is also that railpack.json is entirely optional.

Can you clarify?

i have same problem

Hey there! Can I get any information/links to a deployment on this? Would love to dive in.

Recent failed deployment ID from one of my services: d4d72f6b-3c5d-4709-852b-818a2e4f7959

Let me know what else I can provide that would be helpful here. Again, I know that I can fix this by re-disabling metal every time I need to deploy, but that feels like a bandaid for two issues: (1) Railpack builds, on metal or otherwise, should not require a Dockerfile, IIRC, and (2) why won't the toggle for "Use metal build environment" just stay off once disabled? Even if you are planning to deprecate non-metal builds soon, this behavior feels surprising/unclear.

Aaand it looks like the ability to disable metal has been removed. I will begrudgingly add redundant Dockerfiles to my services to unblock myself, but I would really love to see a fix here.

Okay, I think that I've resolved this. I deploy all of my services from a monorepo, and the monorepo root had a railway.json which specified a Dockerfile. I was under the impression that services deployed from subdirectories would not be affected by this root-level configuration, but clearly I was wrong.

Glad you found it. That's the expected behavior - the config-as-code file does not follow the root directory setting, so a railway.json at the repo root applies to all services regardless of their configured root directory. You can either remove the Dockerfile reference from the root config or set a per-service config file path in each service's settings (e.g. /frontend/railway.json).