Metal builder fails immediately after scheduling — no build output
riskycards1
PROOP

20 days ago

Could someone help identify why this deployment is failing immediately after being assigned to the Metal builder? The logs stop at scheduling build on Metal builder "builder-zdssbo" with no additional build output.

A redeploy produced the same result. I'm trying to determine whether this is a Railway builder issue or whether there is a hidden pre-build error I can fix on my side.

I'd prefer to troubleshoot the existing staging service rather than recreate or make major changes to the service, database, variables, domains, or production environment.

Solved$20 Bounty

Pinned Solution

19 days ago

The error says that your pnpm-lock.yaml is out of date

You can run pnpm --no-frozen-lockfile on your local machine and push the updated pnpm lock file to fix it

8 Replies

Railway
BOT

20 days ago

This thread has been opened as a bounty so the community can help solve it.

Status changed to Open Railway • 20 days ago


20 days ago

Try cancel all stuck builds and Deploy Latest Commit from the Command Palette


mayori

Try cancel all stuck builds and **Deploy Latest Commit** from the **Command Palette**

riskycards1
PROOP

20 days ago

Thanks. I confirmed there were no queued/stuck builds remaining and then triggered a completely fresh deployment from a new latest GitHub commit. It still failed immediately on builder-zdssbo with no build output after the scheduling line. New deployment ID: ec911f2c-fab8-4a43-8af9-e1eed5820c6f.


riskycards1
PROOP

20 days ago

Update: Moderator tip (cancel stuck builds + Deploy Latest) did not fix this.

Still failing on Metal builder builder-zdssbo with only one build log line, then BUILD_IMAGE fails. Example deployments:

  • ec911f2c-fab8-4a43-8af9-e1eed5820c6f (commit retry)
  • c317072e-cbe6-4e9d-92f5-31d79c485ff4 (docs-only AI handoff commit — no app code change)

Last SUCCESS: 9de85095-a4b6-4432-b85f-e482d987019e (~1h earlier on the same builder name). Service deal-api-test / env staging-deal-foundation / project diligent-adaptation.

I cannot find a “Use Metal Build Environment” toggle (and Railpack appears to auto-select Metal). Please quarantine/restart builder-zdssbo or force this service onto a healthy builder. Prefer not to recreate the service or touch production/DB/vars.


riskycards1
PROOP

20 days ago

@Railway team — could this please be escalated for platform-level review?

At this point we have reproduced the failure with Deploy Latest Commit and with a docs-only commit. The failure occurs immediately, before our application build starts.

The same service/environment previously deployed successfully on the same configuration, and we have intentionally avoided deleting/recreating the service, database, environment, variables, or domains because we do not want to destroy evidence of a possible builder/platform issue.

Could a Railway engineer please inspect the failed deployment and the builder infrastructure associated with this service?

If the current builder is unhealthy, we’re specifically asking whether Railway can restart/quarantine it or move this staging service to a healthy builder without recreating our infrastructure.

This is blocking all deployments to our staging environment.

Existing deployment IDs and successful/failed comparisons are documented above. We’re happy to provide any additional IDs or diagnostics Railway needs.


19 days ago

Can you share the Full Build Logs here? Team doesn't help with this issue because this is an application-level issue


mayori

Can you share the Full Build Logs here? Team doesn't help with this issue because this is an application-level issue

riskycards1
PROOP

19 days ago

Thanks — I found the full Build Logs. Posting the complete output below.

This exposes an error that wasn't apparent from the deployment summary. Railpack gets through initialization and reaches pnpm install --frozen-lockfile --prefer-offline, where it fails with ERR_PNPM_OUTDATED_LOCKFILE.

It appears artifacts/api-server/package.json now specifies exact versions 3.893.0 for the two AWS SDK packages while pnpm-lock.yaml contains ^3.893.0.

We'll correct the repository lockfile mismatch rather than disabling frozen-lockfile. Please let me know if you see anything else in these logs that indicates a Railway-side issue.

HISTORY

Hide Skipped

deal-api-test

/

c317072e

Failed

2026-09-18 02:23 PDT

deal-api-test-staging-deal-foundation.up.railway.app

Get Help

Details

Build Logs

Deploy Logs

Network Logs

Diagnosis › Try running a diagnosis to understand why this deployment failed.

Diagnose

Search build logs

You reached the start of the range

2026-09-18 02:18

unpacking archive

13.8 MB

101ms

using build driver railpack-v0.39.0

local://prepare-driver

0ms

local://prepare-context

0ms

prepare railpack-v0.39.0

2s

╭─────────────────╮

│ Railpack 0.39.0 │

╰─────────────────╯

↳ Detected Node

↳ Using pnpm package manager

↳ Found workspace with 10 packages

↳ Custom start command detected, skipping Caddy start

Packages

──────────

pnpm │ 9.15.9 │ pnpm-lock.yaml (9)

node │ 24.20.0 │ railpack default (lts)

Steps

──────────

▸ install

$ pnpm add -g node-gyp

$ pnpm install --frozen-lockfile --prefer-offline

▸ build

$ pnpm --filter @workspace/api-server build

Deploy

──────────

$ pnpm --filter @workspace/api-server start

uploading snapshot

6.9 MB

1s

load build definition from ./railpack-plan.json

0ms

install apt packages: libatomic1 cached

0ms

copy /mise/shims, /mise/installs, /usr/local/bin/mise, /etc/mise/config.toml, /root/.local/state/mise cached

48ms

install mise packages: node, pnpm cached

0ms

copy / /app

412ms

mkdir -p /app/node_modules/.cache

590ms

pnpm add -g node-gyp

1s

Done in 696ms using pnpm v9.15.9

pnpm install --frozen-lockfile --prefer-offline

904ms

Scope: all 11 workspace projects

 ERR_PNPM_OUTDATED_LOCKFILE  Cannot install with "frozen-lockfile" because pnpm-lock.yaml is not up to date with /artifacts/api-server/package.json

Note that in CI environments this setting is true by default. If you still need to run install in such cases, use "pnpm install --no-frozen-lockfile"

Failure reason:

specifiers in the lockfile ({"@aws-sdk/client-s3":"^3.893.0","@aws-sdk/s3-request-presigner":"^3.893.0","@google-cloud/storage":"^7.19.0","@workspace/api-zod":"workspace:*","@workspace/db":"workspace:*","@workspace/integrations-gemini-ai":"workspace:*","connect-pg-simple":"^10.0.0","cookie-parser":"^1.4.7","cors":"^2.8.6","drizzle-orm":"catalog:","express":"^5.2.1","express-session":"^1.19.0","google-auth-library":"^10.6.2","pino":"^9.14.0","pino-http":"^10.5.0","zod":"catalog:","@types/connect-pg-simple":"^7.0.3","@types/cookie-parser":"^1.4.10","@types/cors":"^2.8.19","@types/express":"^5.0.6","@types/express-session":"^1.19.0","@types/node":"catalog:","esbuild":"0.27.3","esbuild-plugin-pino":"^2.3.3","pino-pretty":"^13.1.3","thread-stream":"3.1.0","tsx":"catalog:"}) don't match specs in package.json ({"@types/connect-pg-simple":"^7.0.3","@types/cookie-parser":"^1.4.10","@types/cors":"^2.8.19","@types/express":"^5.0.6","@types/express-session":"^1.19.0","@types/node":"catalog:","esbuild":"0.27.3","esbuild-plugin-pino":"^2.3.3","pino-pretty":"^13.1.3","thread-stream":"3.1.0","tsx":"catalog:","@google-cloud/storage":"^7.19.0","@workspace/api-zod":"workspace:*","@workspace/db":"workspace:*","@workspace/integrations-gemini-ai":"workspace:*","connect-pg-simple":"^10.0.0","cookie-parser":"^1.4.7","cors":"^2.8.6","drizzle-orm":"catalog:","express":"^5.2.1","express-session":"^1.19.0","google-auth-library":"^10.6.2","pino":"^9.14.0","pino-http":"^10.5.0","zod":"catalog:","@aws-sdk/client-s3":"3.893.0","@aws-sdk/s3-request-presigner":"3.893.0"})

Build Failed: build daemon returned an error < failed to solve: process "pnpm install --frozen-lockfile --prefer-offline" did not complete successfully: exit code: 1 >

scheduling build on Metal builder "builder-zdssbo"

You reached the end of the range

2026-09-18 02:28


19 days ago

The error says that your pnpm-lock.yaml is out of date

You can run pnpm --no-frozen-lockfile on your local machine and push the updated pnpm lock file to fix it


riskycards1
PROOP

19 days ago

Fixed — thank you!

Updating the dependency ranges resolved the frozen lockfile error and allowed the build to proceed.

Once that was fixed, Railway exposed a separate syntax error in our application code. We corrected that as well, and the staging deployment is now successful and passing its health check.

Thanks for pointing us in the right direction.


Status changed to Solved dev • 19 days ago


Welcome!

Sign in to your Railway account to join the conversation.

Loading...