Check What’s Actually Being Run at Runtime

Railway runs your app with your service's "Start Command" (or npm start if not overridden).

If your start script is running node migrate.js && ... && node server.js, and node migrate.js fails or hangs, nothing else runs, and the container can exit (especially if migrate.js completes instantly or fails).

If migrate.js is very quick and doesn't error, server.js starts. If migrate.js throws, the whole chain is aborted.

If your script does not keep the process running (i.e., server.js does not start or instantly exits), the container exits, logs nothing, and you get a 502.

!!! You are missing logs—likely because your migrate scripts don't output anything, or the process exits before Railway's logger can capture stdout/stderr.

Try to:

Add Logging to Migration Scripts at the top of each migration script, add:

console.log('Starting migrate.js');

And at the end:

console.log('migrate.js completed');

Do the same for migrateUsers.js, migrateProjects.js.

Try to: Fix Start Command (and Use Postinstall for Migrations, If Appropriate)

Build Command: npm install

Start Command: Only start your web server. Run migrations before the server starts.

1: Run Migrations Before Start

You can use an npm script such as:

"scripts": {  "migrate": "node migrate.js && node migrateUsers.js && node migrateProjects.js",

  "start": "npm run migrate && node server.js"

}

This ensures migrations run before the server, and the process continues if migrations succeed.

2: Use Railway's "Startup Command" Properly

Set your Railway service’s Start Command to:

>npm start

And in your package.json:

"start": "npm run migrate && node server.js"

3: Separate Migration and Server Start

Sometimes, migrations can be done in the build phase (not always safe for all DBs):

"scripts": {  "postinstall": "node migrate.js && node migrateUsers.js && node migrateProjects.js",

Then use:

Build : npm install

Start : npm start (default).

Note: If your Railway deploys a new container without running npm install, migrations might not run. Option 1 is generally safest.

Hey — sounds like you’re really close, but something’s getting swallowed silently during the deploy process.

From what you’ve described, it seems like migrate.js (and the others) might be failing silently, and because it’s part of your start script (node migrate.js && ... && node server.js), any failure there could prevent the app from fully starting — hence the 502 and no logs.

Also, since you're not seeing any output after “Starting Container,” that usually means the app crashed right away, before any logging could happen.

A few things worth trying:

• Add explicit console.log() statements at the top of each script (migrate.js, migrateUsers.js, etc.) to make sure they’re even being hit.

• Wrap each migration in a try/catch with logging to stderr. If something throws, at least you’ll see it in the Railway logs.

• If migrate.js depends on any env vars (like DB credentials), make sure they’re set correctly in the Railway project settings.

• Temporarily simplify the start script to just node server.js and try running the migrations manually as a test (e.g., through Railway shell or a temp route) — just to isolate whether the issue is with the migrations or the startup chain.

Also, quick note: putting chmod +x in the Build Command only works if the file is actually a shell-executable script (like with a #!/usr/bin/env node at the top). Otherwise, Node will ignore the executable bit and just need the file to be accessible by node. So unless you're running it directly from the shell, the chmod might not matter.

Let us know if adding some logging to the scripts shows anything useful — I’ve seen cases where one script fails silently and the app just exits with nothing.