Hi Railway team,

We are seeing inconsistent builder selection on the same production service and the same Git commit.

Our service settings currently show:

Builder: Dockerfile — Automatically Detected

Dockerfile Path: Dockerfile

Service: ai-social-media

Environment: production

Git commit: 4d43ec7

The repository Dockerfile explicitly runs:

pnpm prisma generate && pnpm build

What happened

On the first deployment of commit 4d43ec7, Railway correctly used our repository Dockerfile. The complete application build succeeded, an image was produced and pushed, but the deployment later failed with:

Failed to connect before the deadline

On subsequent deployment attempts of the exact same commit, Railway unexpectedly used a Railpack/mise build path instead of the Dockerfile.

Those builds used Node 24 and effectively ran:

pnpm install ...

followed by:

pnpm run build

without running prisma generate.

They consequently failed during TypeScript checking with errors such as:

Module '"@prisma/client"' has no exported member 'PrismaClient'.

Why we believe this is builder-related

The same commit:

builds successfully locally;

passes our GitHub CI;

successfully completed the Railway application build when Railway actually used our Dockerfile;

has no changes to Dockerfile, Prisma configuration, package manager configuration or other build inputs compared with the previously working deployment.

Railway's automated Diagnose suggested migrating our imports for the Prisma 7 client API. However, our project intentionally uses Prisma's prisma-client-js generator, and the exact same source successfully type-checks after prisma generate. Therefore the Prisma errors appear to be a consequence of the Railpack build skipping client generation, rather than the underlying cause.

We also noticed another solved Community thread describing very similar behavior: Dockerfile configured in the UI but Railpack being selected instead.

The recent Railway deployment incident has now been marked resolved, but a fresh deployment attempt still exhibited the problem.

Questions

Could someone from Railway please help us understand:

Why can the same commit use the repository Dockerfile on one deployment and Railpack/mise on subsequent deployments, while the service UI continues to show Dockerfile as the selected builder?

Is there a way to explicitly pin this service to the repository Dockerfile so that redeploy/requeue operations cannot fall back to Railpack?

Could the earlier Failed to connect before the deadline after a successful Dockerfile build have been related to the recent Railway deployment incident?

We have intentionally not modified the application or added workarounds such as changing Prisma imports or duplicating prisma generate in package scripts, because the repository Dockerfile already builds the application correctly.

I can provide the relevant deployment IDs and additional sanitized build logs if needed.

Thanks.