a month ago
one of my services keeps hanging on build phase.
for some reason its getting automatically assigned to Metal build. my other services are working fine and linked to the same codebase/repo. (its a server and a worker duo).
here's what i see:
fetched snapshot sha256:c3e6369f52db00529ccb8673bfa798163bfb00c961dfbcc017ca14a8edf24c87 (241 MB bytes)
fetching snapshot229.7 MB1.2s
using build driver nixpacks-v1.41.0
╔══════════════════════════════ Nixpacks v1.41.0 ══════════════════════════════╗
║ setup │ nodejs_24, pnpm-9_x ║
║──────────────────────────────────────────────────────────────────────────────║
║ install │ npm install -g corepack@0.24.1 && corepack enable ║
║ │ pnpm i --frozen-lockfile ║
║──────────────────────────────────────────────────────────────────────────────║
║ build │ pnpm install --frozen-lockfile && pnpm --filter=backend clean ║
║ │ && pnpm exec turbo run build --filter=./apps/backend ║
║──────────────────────────────────────────────────────────────────────────────║
║ start │ pnpm --filter=backend start:prod ║
╚══════════════════════════════════════════════════════════════════════════════╝
Saved output to:
snapshot-target-unpack
internal
load build definition from Dockerfile
0ms
internal
load metadata for ghcr.io/railwayapp/nixpacks:ubuntu-1745885067
315ms
internal
load .dockerignore
0ms
SecretsUsedInArgOrEnv: Do not use ARG or ENV instructions for sensitive data
..
UndefinedVar: Usage of undefined variable '$NIXPACKS_PATH' (line 18)(https://docs.docker.com/go/dockerfile/rule/undefined-var/) details: Variables should be defined before their use
internal
load build context
0ms
stage-0
9ms
stage-0
WORKDIR /app/ cached
0ms
stage-0
COPY .nixpacks/nixpkgs-23f9169c4ccce521379e602cc82ed873a1f1b52b.nix .nixpacks/nixpkgs-23f9169c4ccce521379e602cc82ed873a1f1b52b.nix
982ms
stage-0
RUN nix-env -if .nixpacks/nixpkgs-23f9169c4ccce521379e602cc82ed873a1f1b52b.nix && nix-collect-garbage -d
48s
62 store paths deleted, 561.52 MiB freed
scheduling build on Metal builder "builder-zymacq"
stage-0
COPY . /app/.
1s
stage-0
RUN npm install -g corepack@0.24.1 && corepack enable
46s
npm notice
Pinned Solution
a month ago
Hello,
The problem here is that new Metal builders by default use nixpacks 1.41.0 version (which default to node 24), and old builders use 1.38.0 (node 22).
We are switching all users to new Metal builders, so the solution here:
1. Make it work with nixpacks 1.41.0 and node 24.
- Alternatively you can pin node version via
NIXPACKS_NODE_VERSION(although I am not 100% sure that node version is the root cause here). - But our recommendation is to migrate to Railpack, as Nixpacks is deprecated (your config is simple enough so this should be easy).
4 Replies
a month ago
This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.
Status changed to Open Railway • 29 days ago
a month ago
- Your app isn’t crashing—it’s getting stuck during build, likely while installing dependencies.
- Railway put this service on a Metal builder, which can behave differently (slower or less stable).
- Since your other service works, the problem is specific to this one service’s config or build steps.
Most likely reasons:
pnpm installis hanging (common in some environments)- Your lockfile (
pnpm-lock.yaml) might be out of sync - The Turbo build filter (
./apps/backend) might not resolve correctly - Corepack (used to install pnpm) can sometimes stall
Easy fixes to try:
- Skip strict lockfile:
pnpm install --no-frozen-lockfile - Install pnpm directly (avoid corepack):
npm install -g pnpm@9 - Simplify build (test if Turbo is the issue):
pnpm --filter backend build - Clear Railway build cache and redeploy
Bottom line:
It’s not your server or LXC. It’s the build step (pnpm/Turbo) getting stuck in Railway’s environment.
a month ago
i turn OFF metal build and it seems to have fixed it issue. not sure why
a month ago
Turning off Metal build fixed it because Railway’s Metal builders behave differently.
They often have no cache, slower installs, or network quirks
Tools like pnpm, corepack, or turbo can hang there
Your other service worked because it wasn’t using Metal
Nothing was wrong with your code hahahahh the Metal environment was causing the build to stall. Keeping it off is totally fine.
a month ago
Hello,
The problem here is that new Metal builders by default use nixpacks 1.41.0 version (which default to node 24), and old builders use 1.38.0 (node 22).
We are switching all users to new Metal builders, so the solution here:
1. Make it work with nixpacks 1.41.0 and node 24.
- Alternatively you can pin node version via
NIXPACKS_NODE_VERSION(although I am not 100% sure that node version is the root cause here). - But our recommendation is to migrate to Railpack, as Nixpacks is deprecated (your config is simple enough so this should be easy).
Status changed to Awaiting User Response Railway • 29 days ago
Status changed to Open brody • 29 days ago
Status changed to Solved brody • 29 days ago