seriously...this is getting ridiculous

Metal build is very unstable with my codebase (Turborepo monorepo).

Is there some way to LOCK my service so that it NEVER uses Metal build environment until it can actually successfully build it?

The build failures on Metal are happening because your services are still using Nixpacks, which was deprecated a long time ago and has limited support on Metal. You'll need to migrate your services to Railpack to build reliably on Metal.

Thanks for the clarification. I will make that adjustment if I continue to see the issue. Much appreciated.

No problem, and sorry for the rocky start!

i made those updates. Things are looking to be working fine. thanks again.

There still some inconsistencies. I have FOUR services all connected to the same codebase/repo/environment and i still had one of them stuck/hanging on build while the others all completed fine.

Also, weirdly, the one that got hung was somehow reverted back to Nixpacks (event though im using a toml file to set it specifcially to Railpack and all the proper start and build commands) and its the same toml file being used on the other 3 services that are deploying fine.

What is going on ?

here's some screenshots of what im seeing.

Now im paranoid - is what im seeing in the railway dashboard UI current or cached (with regards to whether its using Nixpacks or Railpack/my .toml file?

its not acting consistently across the 4 services that all use the same .toml file and are linked to the same codebase/branch/env.

1 out of 4 is using Nixpacks now and its hanging. The others are using the .toml file properly (using Railpack) and they are deploying fine.

this is very confusing. its like it just randomly doesn't listen to the .toml file?? WHY?

It shows Railpack right now, so my guess would be that, since the build wasn't finished, the build pipeline didn't update the UI at the time the screenshot was taken.

There's definitely something going wrong with how toml files are being handled and how the services are being deployed.

I haven't changed anything since the last deployment (where I kept having to redeploy and force it to use Railpack instead of Nixpacks via the Railway UI).

Now It keeps redoing the same problem I saw before.

Three out of the four services are obeying the toml file but one out of four goes outside of it and starts going back to Nixpacks and doesn't explicitly show that it is using the toml file in the UI like the other services that use the same toml file. (the start command and build command doesnt properly populate in the UI).

is there some limit to how many services can reference the same toml file or something??

should i create ONE toml file per service instead of having 4 share the same one????? seems odd to have to do that.

Please provide a link to the service that keeps switching back to Nixpacks.

WHILE it is building, should I be concerned about what the UI is showing in the settings, or no?? (is it just a UI glitch).

Because the api-worker-trial service was just showing the Nixpacks, then i cancelled it and changed it to Railpack, and the build command,etc were not displaying correctly, but i let it run, and it seems to have succeeded.

NOW, after success, i see the settings UI, and it DOES show Railpacks, and the custom build/start commands are populated (as per the toml file).

im still very confused.

my point is - if i run a deployment, and the toml file hasn't changed since the last commit, these weird issues of one of our four services using NixPacks and NOT displaying the toml file related settings in the Service settings UI is driving me nuts.

service: api-worker-trial (this time), but last time it was api-worker-paid.

Please provide a link to the service that keeps switching back to Nixpacks.