a month ago
My service is consistently failing to build with zero logs and no image type across 10+ deployment attempts spanning multiple commits. The Docker build never initiates — Railway assigns a Metal builder, but no build steps execute and no output is produced. The deployment UI shows "Deployment failed during build process" with a ~1:26 duration but completely empty logs.
What makes this unusual:
The exact same Dockerfile configuration successfully deployed earlier the same day
The issue persists across multiple different Metal builder instances (builder-pyshnl, builder-wvfxjh, builder-bqitrq, and others)
Changing environment variables, adding a railway.json, busting the cache, and redeploying from different commits all produce the same result
Other services on the same GitHub repo deploy successfully
Setup:
pnpm monorepo with Turborepo
Builder: Dockerfile
Root directory: /
Node 20 Alpine base image
Error message:
"Deployment failed during build process" — no further output, zero build logs.
Logs:
None produced. The builder is assigned and then fails silently.
1 Replies
Status changed to Open Railway • 30 days ago
a month ago
Hi i2aswin,
Since you are running a pnpm monorepo with Turborepo, silent crashes right at the start of a Docker build usually point to context size issues or memory exhaustion before the build engine can even stream stdout.
Here are a few things to check and try:
1. Check Your Context Size (.dockerignore)
If your Turborepo context includes massive node_modules or local cache folders from your local machine, the builder might be crashing while trying to upload or process the build context.
- Ensure you have a .dockerignore file in your root.
-
- Make sure it explicitly excludes all node_modules, .turbo, and build artifacts (dist, .next, etc.).
2. Verify Your Dockerfile Line Endings
If you recently edited your Dockerfile on a Windows machine, it might have CRLF line endings. Linux-based builders (like Railway's Metal builder) will fail silently on the very first line (the FROM instruction) if they encounter CRLF instead of LF.
3. Check for Architecture Mismatches
Alpine images can sometimes fail silently on certain runner architectures if native dependencies (like sharp, prisma, or bcrypt) try to compile.
- Try temporarily switching your base image from node:20-alpine to a standard Debian-based image like node:20-slim to see if it bypasses the silent crash.
4. Explicitly Set the Dockerfile Path
Since it's a monorepo, Railway might be getting confused about which configuration to prioritize. Go to your Railway service settings:
- Look under Settings -> Build -> Dockerfile Path.
-
- Manually type out and save ./Dockerfile (or the exact path to it) to force the platform to strictly use that builder instead of trying to auto-detect a Nixpacks configuration.