Node.js on shared hosting — what works, what doesn't, and when to go VPS

For most of shared hosting's history, running Node.js on a shared host meant either hacking around SSH to run a persistent process (which the host would kill eventually) or paying for a VPS for even simple Node applications. The assumption was that shared hosting equals PHP, and everything else needs dedicated resources.

Enhance, the control panel we use for shared and reseller hosting, has changed this with native Node.js application support. Applications are served through Passenger, which manages the Node process lifecycle, automatic restart on crash, and integration with Nginx. It's not perfect for every use case, but for the right workloads it's genuinely useful.

This article explains what works on shared hosting with Enhance, what doesn't, and when the workload genuinely needs a VPS.

What actually works on shared hosting Node.js

Static file serving with a Node backend. A Next.js application in static export mode, or any framework that builds to static HTML, works well. The Node process handles server-side rendering or API routes during the build, and the static output is served directly by Nginx. For applications that can be statically exported, shared hosting is often entirely adequate.

Low-traffic API applications. A small REST API, a webhook handler, a serverless-style function that receives occasional requests and returns fast responses — these work fine on shared hosting. Passenger starts the Node process on the first request, keeps it running while there's traffic, and restarts it if it crashes.

Build processes and tooling. Running npm run build for front-end assets, executing static site generators, running one-off scripts. Enhance's SSH access means you can run Node tooling without needing a dedicated server.

Express or Fastify applications with modest traffic. If your application handles a few dozen requests per minute with response times under a second, a shared hosting Node environment is sufficient. The per-account resource limits on Enhance control the CPU and memory ceiling, but for light-traffic applications you'll rarely approach them.

What doesn't work well on shared hosting

WebSocket servers. Passenger's integration with Nginx works by proxying to the Node process. Long-lived WebSocket connections work technically, but shared hosting's per-account connection limits and resource controls make high-concurrency WebSocket applications unreliable. An application with hundreds of simultaneous WebSocket connections needs dedicated resources and careful Nginx configuration.

High-memory processes. Node's garbage collector is lazy — it'll use memory up to a limit before collecting. Applications with large datasets in memory, or frameworks that have significant baseline memory usage (some full-stack frameworks start at 300–500MB), will hit shared hosting resource limits.

Long-running background jobs. Passenger expects to manage HTTP request handlers, not background workers. A process that spends most of its time doing background work rather than responding to HTTP requests isn't a good fit for the Passenger model. Background job processing belongs on a VPS where you can run the worker process separately from the HTTP server.

High CPU workloads. Image processing, PDF generation, data transformation at scale — Node is single-threaded for CPU-bound work (worker threads help but add complexity). If your application spends significant time on CPU-intensive tasks, shared hosting's resource limits will constrain throughput.

Applications that need PM2 or complex process management. PM2's clustering mode (which uses Node's cluster module to fork multiple processes across CPU cores) works differently from Passenger's process management. The two don't compose cleanly. If your application is tuned for PM2 clustering, it belongs on a VPS.

The configuration in Enhance

Setting up a Node application in Enhance requires:

1. Uploading your application to the hosting account via SFTP or Git deployment
2. Running npm install via SSH to install dependencies
3. Creating a Passenger configuration — Enhance provides a UI for this that sets the Node version, the startup file, and the application root
4. Pointing the domain at the application in Enhance's web server configuration

Enhance supports multiple Node versions via NVM. You can specify which version your application requires. This is more flexible than many shared hosting environments, which lock you to a single Node version.

Environment variables are set in Enhance's control panel per application. They're passed to the Node process as standard environment variables.

When to go VPS

A VPS is the right answer when:

• You need persistent background worker processes separate from your HTTP server
• You need WebSocket connections at any meaningful concurrency
• Your application requires more than ~1GB RAM under normal operation
• You need to run multiple Node processes in a cluster
• You need to install system dependencies (FFmpeg, ImageMagick, specific native modules)
• You need control over Nginx configuration beyond what Enhance exposes
• You need to run Docker containers alongside your application

The practical test is simpler: does your application work on shared hosting without hitting resource limits or needing process management features that Passenger doesn't provide? If yes, start there. If no, go VPS.

The economics usually make this straightforward. Shared hosting is appropriate for applications with modest and predictable resource requirements. VPS is appropriate when you need the resources and control that dedicated virtualisation provides.

FXRM offers both Enhance-based shared hosting with native Node.js support and KVM VPS hosting for when you need dedicated resources. See hosting plans → or VPS hosting →.