Articles on: ⚠️ Troubleshooting
This article is also available in:

What should I do if a Node.js application won't start?

A Node.js application that answers 503, or an error page instead of your site, almost always comes down to one of three things. Passenger runs one file and then waits for it to open a port: what goes wrong is the file, or the port.


The startup file is not the right one


Passenger does not run npm start. It runs the file the project names as its startup file, and if that file does not exist, nothing starts.


For a project deployed with Hodifly, set it in cPanel > Hodifly > your project > Startup file, or, better, in the repository itself with "startup": "dist/main.js" in a hodifly.json file, which is applied on every deploy. A compiled application is the usual case: NestJS builds to dist/main.js, and a path is perfectly valid there. Your application still starts from the project root, so the folders beside it stay reachable.


One trap worth knowing: Passenger loads that file with require(), so an entry point that is an ES module (a .mjs file, or a project with "type": "module") fails on its own. Point the startup file at a small CommonJS bridge instead, server.cjs at the root of the project:


process.env.NODE_ENV = process.env.NODE_ENV || 'production';
import('./dist/server/server.mjs').catch(e => { console.error(e); process.exit(1); });


Your application never calls listen()


Passenger starts your application by hooking into listen(). An application that never calls it is not a web server, and nothing will answer. Listen on the port Passenger gives you:


app.listen(process.env.PORT || 3000);


An Angular SSR build is the classic surprise here: the generated server.mjs only listens when it is the main module, which it is not under Passenger. Remove that condition so it always listens.


Your application calls listen() several times


With several HTTP servers, Passenger cannot tell which one to hook into and gives up. The Phusion Passenger documentation explains the adjustment.


Read the error rather than guessing


Your application's own output, including the stack trace that killed it, is written to a log file on your account. For a Hodifly project:


~/logs/hodifly-<project>-<branch>.log


Open it in cPanel > File Manager, or over FTP. Nine times out of ten the reason is in the last few lines: a missing module, a missing environment variable, a port already taken. The build itself is a different log: cPanel > Hodifly > your project > the deployment.

Updated on: 31/08/2026

Was this article helpful?

Share your feedback

Cancel

Thank you!