YeHeng-Logistic: Silent startup crash - app crashes immediately after "Ready" with zero error logs
eugeneglen
HOBBYOP

a day ago

Problem Summary

My Next.js 16 application (YeHeng-Logistic) builds successfully but crashes silently on every startup, making it completely inaccessible. The container starts, logs "Ready in Xms", then immediately crashes with ZERO error messages. All HTTP requests get 502 "connection refused".

Project Details

  • Project: balanced-amazement (ID: 3c366386-af2a-49a6-a36d-548bec36edcf)
  • Environment: production (ID: 9e8da83e-fd0c-42a3-af0c-834a1ec27fcb)
  • Service: YeHeng-Logistic (ID: 73bc2ea5-1c40-4e7c-83d7-f657429ddf6f)
  • Repository: Eugeneglen/YeHeng-Logistic (main branch)
  • Runtime: Next.js 16.1.3 standalone server on Node.js
  • Port: 8080
  • Start Command: PORT=8080 node .next/standalone/server.js

Deploy Logs Pattern (Latest deployment c0a91dd9)

Starting Container → Stopping Container (crashes with no error output) → Mounting volume → Starting Container again → "Ready in 44ms" → Container exits silently

The app says it's ready, then immediately stops. There are ZERO error logs at any point - the container simply becomes unreachable.

What We've Tried

✅ Removed undefined variable references

✅ Fixed component exports and structure

✅ Added error boundaries and logging attempts

✅ Verified all imports are correct

✅ Confirmed build succeeds with no warnings

All fixes succeeded but problem persists.

Key Observations

  • Build process works perfectly
  • Next.js starts and initializes ("Ready in Xms")
  • Crash happens AFTER Next.js reports ready
  • ZERO stderr/stdout output during crash
  • Same pattern across 10+ deployments
  • This suggests either container OOM, volume mount issue, or platform-level logging problem

What I Need

Can your infrastructure team check:

  1. Full container runtime logs (including stderr)
  2. Container resource metrics (CPU, memory, disk) at time of crash
  3. Volume mount initialization logs for /app/data
  4. Any platform-level container exit codes/reasons
  5. Known issues with Next.js standalone mode on Railway

This is a critical blocker - the site is completely down.

Solved$10 Bounty

Pinned Solution

spjoes
HOBBY

19 hours ago

Hey! Are you sure its crashing? Your 502s sound like a bind-address issue, not a crash.

Next.js standalone server.js binds to process.env.HOSTNAME. Docker sets HOSTNAME to the container ID by default, so your server listens on the container's internal hostname instead of 0.0.0.0. It logs "Ready" and keeps running, but Railway's proxy hits 0.0.0.0:8080 and gets connection refused. I think this is your 502.

Railway's own docs say the app has to bind to 0.0.0.0 and the PORT it injects. Your start command sets PORT but not HOSTNAME, which is why it's every deploy.

The fix should just be updating your start command to: HOSTNAME=0.0.0.0 PORT=8080 node .next/standalone/server.js

OR you could add a service variable (HOSTNAME = 0.0.0.0) and keep your current command. Redeploy and the 502s should stop.

4 Replies

Railway
BOT

a day ago

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

Status changed to Open Railway 1 day ago


spjoes
HOBBY

19 hours ago

Hey! Are you sure its crashing? Your 502s sound like a bind-address issue, not a crash.

Next.js standalone server.js binds to process.env.HOSTNAME. Docker sets HOSTNAME to the container ID by default, so your server listens on the container's internal hostname instead of 0.0.0.0. It logs "Ready" and keeps running, but Railway's proxy hits 0.0.0.0:8080 and gets connection refused. I think this is your 502.

Railway's own docs say the app has to bind to 0.0.0.0 and the PORT it injects. Your start command sets PORT but not HOSTNAME, which is why it's every deploy.

The fix should just be updating your start command to: HOSTNAME=0.0.0.0 PORT=8080 node .next/standalone/server.js

OR you could add a service variable (HOSTNAME = 0.0.0.0) and keep your current command. Redeploy and the 502s should stop.


spjoes

Hey! Are you sure its crashing? Your 502s sound like a bind-address issue, not a crash. Next.js standalone `server.js` binds to `process.env.HOSTNAME`. Docker sets `HOSTNAME` to the container ID by default, so your server listens on the container's internal hostname instead of `0.0.0.0`. It logs "Ready" and keeps running, but Railway's proxy hits `0.0.0.0:8080` and gets connection refused. I think this is your 502. Railway's own docs say the app has to bind to `0.0.0.0` and the `PORT` it injects. Your start command sets `PORT` but not `HOSTNAME`, which is why it's every deploy. The fix should just be updating your start command to: `HOSTNAME=0.0.0.0 PORT=8080 node .next/standalone/server.js` OR you could add a service variable (`HOSTNAME` = `0.0.0.0`) and keep your current command. Redeploy and the 502s should stop.

eugeneglen
HOBBYOP

16 hours ago

Legend! Adding HOSTNAME=0.0.0.0 fixed it instantly. The 502s are gone and the app is live. Thanks for spotting the bind-address issue!


eugeneglen

Legend! Adding HOSTNAME=0.0.0.0 fixed it instantly. The 502s are gone and the app is live. Thanks for spotting the bind-address issue!

spjoes
HOBBY

16 hours ago

Heck yeah! No problem. Can you please mark my answer as the accepted solution when you get a chance so the thread is closed properly?


Status changed to Solved mykal about 2 hours ago


2 hours ago

I recommend adding HOSTNAME=0.0.0.0 and PORT=8080 as env vars instead of setting them in the start command.


Status changed to Awaiting Conductor Response Railway about 2 hours ago


Status changed to Solved medim about 2 hours ago


Welcome!

Sign in to your Railway account to join the conversation.

Loading...