Node.js deployment is genuinely different from every stack covered so far, for the reason established in the choosing-hosting-for-your-stack lesson: a Node.js app typically runs as one continuous, always-on process, not a fresh process started per request the way PHP works — which is exactly what traditional shared hosting cannot accommodate.
Platforms built specifically for Node.js hosting handle the "keep the process running" problem for you entirely, using the same Git-based deployment workflow covered earlier in this category:
npm install), starts your app, and keeps the process running — restarting it automatically if it ever crashes.
Running Node.js on your own VPS means genuinely keeping the process alive yourself. A process manager — PM2 is the most common choice — handles this specifically: it restarts your app automatically if it crashes, keeps it running after you disconnect from SSH, and starts it again automatically if the whole server reboots.
# Install PM2 once
npm install -g pm2
# Start your app through PM2 instead of running it directly
pm2 start server.js
# It now survives you closing the SSH session
pm2 statusA VPS also typically needs a reverse proxy (commonly Nginx) sitting in front of the Node.js app — handling incoming traffic on the standard web ports and forwarding it to the port your Node app actually listens on internally. This is a genuinely more involved setup than Path A, appropriate once there's a specific reason for the extra control, per the VPS lesson earlier in this category.
Exactly the same principle as the PHP lesson's database credentials: a Node.js app's database connection string, API keys, and similar secrets are set as environment variables on the hosting platform, not hardcoded into the source — covered in full in its own lesson later in this category, directly building on this site's Node.js course material on environment variables.
The port a Node.js app listens on locally during development is often not the port the hosting platform expects in production. Most platforms provide this as an environment variable (commonly named PORT) rather than a fixed number — reading it from process.env.PORT, with a local fallback, is the standard pattern that works correctly in both places.
Beyond loading the site, specifically check that the process actually stays running after some time has passed — a common Node deployment failure is an app that starts successfully but crashes shortly after on real traffic, which a quick initial check right after deploying won't catch.