Guide PHP & Development

How to run a Node.js application on your hosting

Node needs a long-running process that shared hosting cannot give it — here is what that means and where a Node app actually belongs.

Updated 6 min read Intermediate

PHP and Node.js solve the same broad problem — running server-side code — in structurally different ways, and that difference is the whole story here. PHP is designed to start fresh for each request and exit; a web server or PHP-FPM starts a PHP process, it runs, it finishes, and the next request gets a new one. Node.js is designed to start once and keep running indefinitely, holding its own event loop open and serving every request from that same long-lived process.

Shared hosting is built around the first model. It gives every account PHP handled through a shared web server layer, but it does not give an individual account the ability to launch and keep alive its own background process — that would mean one customer's account holding a process open on a server shared with many others, which is precisely the kind of resource control shared hosting does not hand out.

What shared hosting can do with Node.js

A small number of shared hosting platforms offer a specific, managed way to run Node.js applications — a dedicated feature in the control panel that starts and supervises the process for you within defined limits, rather than giving you free rein to run arbitrary long-lived processes yourself. If your control panel lists a Node.js application feature, that is the supported route on shared hosting, and it exists specifically because ordinary shared hosting cannot otherwise support what Node needs.

Where no such feature exists, shared hosting genuinely cannot run a persistent Node.js server, regardless of how the code is written — this is not a settings problem to work around.

Where Node.js does run

A VPS gives you full control over the server, including the ability to install Node.js, keep a process running under a process manager, and open the port it listens on. That is the environment Node.js was designed for, and it is the straightforward answer if your control panel has no dedicated Node feature and the application genuinely needs a persistent process — a real-time app using WebSockets, a background worker, or an API server that needs to hold state in memory between requests.

What "process manager" means in practice

Tools such as pm2 or a systemd service keep a Node application running, restart it automatically if it crashes, and start it again after a server reboot. Running node app.js directly in a terminal works until you close that terminal session — a process manager is what keeps it alive after that.

Shared hosting versus a VPS for Node.js

Shared hostingVPS
Runs PHPYes, as standardYes, once installed
Runs a persistent Node.js processOnly if the platform offers a dedicated Node application featureYes, under a process manager you control
Root accessNoYes
Who manages the server itselfYour hostYou, unless it is a managed VPS

The honest answer to "can I run Node.js on shared hosting" is therefore "check whether your specific platform offers a Node.js application feature" rather than a flat yes or no — the constraint is about what the platform explicitly supports, not about Node itself being unusually demanding.

A common middle ground: PHP calling a Node-based service

You do not have to choose one runtime for an entire project. A common and entirely reasonable pattern is a PHP application, hosted on ordinary shared or business hosting, that calls out to a separate Node.js service running elsewhere — on a VPS, or a third-party API — for the one specific job Node handles well, such as server-side rendering of a JavaScript front end or a WebSocket-based feature. The PHP side of that setup is a straightforward outbound API call, covered in calling an external API from PHP.

Moving a Node.js project to a VPS

The broad steps, once you have a VPS:

  • Connect over SSH — see setting up SSH keys for passwordless access.
  • Install Node.js on the server, matching the version your application was built against.
  • Copy the application across and install its dependencies with npm install or yarn install.
  • Run the app under a process manager rather than directly, so it survives a crash or a reboot.
  • Put a web server such as Nginx in front of it as a reverse proxy, handling TLS and forwarding requests to the Node process on its internal port.

Each of those is its own small project the first time through, but none of them is exotic — running Node behind a reverse proxy on a Linux server is the standard way it is deployed almost everywhere outside a specialised managed platform, and it applies equally whether the Node application is a full website, a background worker, or an API that a PHP front end elsewhere calls into.

Related reading