Node.js Hosting

What is Node.js hosting and which projects is it for?

Node.js hosting is hosting JavaScript or TypeScript server applications running on the V8 engine so they are publicly and continuously reachable. Unlike classic PHP hosting, where a script runs from scratch on each request, the application serves requests as a process living in memory. Two questions therefore decide Node.js hosting: who starts the process and keeps it alive, and how much memory does it get?

Node.js hosting is a good start for:

• REST or GraphQL APIs for a mobile app or single-page application (React, Vue)
• Form, payment notification (webhook) and email-sending back ends written with Express
• Business websites rendered server-side (SSR) with Next.js, Nuxt or Astro
• Small and medium business applications built in layers with NestJS

For these scenarios, Linux hosting plans offer Node.js version selection in the panel, SSH access and Git deployment; no server administration knowledge is needed. If your app is a bot, real-time chat or queue worker that must stay on all the time, you need a virtual server instead; the sections below draw that line concretely.

Which Node.js version should you choose?

In production always choose an LTS (Long Term Support) release; as of October 2026 that is Node.js 24, and Node.js 26 enters LTS on 28 October 2026. Node.js 22 is in maintenance and reaches end of life in April 2027. Node.js 20 went out of support on 30 April 2026; apps running on it no longer receive security patches.

From version 27 onward, the Node.js project is moving to a single major release per year. In practice: start new projects on the current LTS and move existing projects from one LTS to the next once a year, as planned work.

To pin the version in your project, add "engines": { "node": ">=24" } to package.json and commit an .nvmrc file. Your local machine, CI and hosting then run the same major version, and most “it worked on my machine” problems disappear.

How does a Node.js app run on Linux hosting?

On Linux hosting, a Node.js app is defined with the panel’s Node.js application tool and runs as a process managed by the web server. In cPanel-based environments the tool appears as Setup Node.js App, in Plesk Obsidian as the Node.js section; both use Phusion Passenger behind the scenes to pass requests to your app.

The fields you need to set are:

• Node.js version: one of the LTS versions listed in the panel
• Application root: the folder containing package.json; keeping it outside the public web folder (public_html) is better for security
• Application URL: the domain or a subfolder
• Startup file: app.js, server.js or a compiled dist/main.js
• Environment variables: NODE_ENV=production, database details, API keys

Your app should not choose its own port; it must listen on process.env.PORT, which Passenger assigns. Dependencies are installed with the panel’s “npm install” button, or over SSH by activating the virtual environment and running npm ci --omit=dev.

In this model the process may go idle if no requests arrive for a while and restart on the next request. That is fine for websites and APIs, but not for work that must run continuously in the background (timers, bot connections). You can split such work into short scripts triggered by cron jobs, or move it to a VPS.

Which Node.js projects need a VPS instead of hosting?

Any Node.js project that needs always-open connections, long-lived background processes, lots of memory or operating-system-level packages needs a VPS rather than shared hosting. Hosting resource limits (concurrent processes, memory, CPU time) exist so a multi-tenant environment stays fair, and they clash with these workloads.

Choose a VPS server straight away if any of these apply:

• WebSocket and Socket.IO: thousands of open connections require a process that never sleeps.
• Queue workers: libraries such as BullMQ and Agenda need Redis and an always-running worker.
• Headless browsers: Puppeteer and Playwright need Chromium and system libraries, which cannot be installed on shared hosting.
• Bots: Discord, Telegram and WhatsApp bots hold a connection open 24/7; see Discord bot hosting for details.
• Container-based deployment: if your project ships with a Dockerfile, Docker hosting fits better.

On a VPS you attach the app to the PM2 process manager and put Nginx in front as a reverse proxy. When traffic grows and you want to escape noisy-neighbour effects entirely, a VDS server with cores dedicated to you is the next step.

Linux hosting, VPS or VDS for Node.js?

Short answer: Linux hosting for web apps and APIs that run on request, a VPS for work that needs always-on processes or system packages, and a VDS for heavy production loads that need steady, predictable performance. All three run the same code; the difference lies in management responsibility and resource guarantees.

The price of the flexibility that comes with full root is that operating system updates, the firewall and the backup plan are yours. If you have no server administration experience, starting the project on hosting and moving when a bottleneck appears is the most efficient path for most teams. Package contents and current values are shown in the package table on this page.

How do you automate Node.js deployment with Git?

The simplest automated deployment is a four-step script: pull the code from Git, install production dependencies, run database migrations if needed and restart the app. You can trigger the script manually over SSH or from a CI pipeline.

cd ~/apps/api
git pull --ff-only origin main
npm ci --omit=dev
npx prisma migrate deploy
mkdir -p tmp && touch tmp/restart.txt

The last line tells Passenger to restart the app on the next request; it has the same effect as pressing “Restart” in the panel. On a VPS, pm2 reload api performs a zero-downtime reload instead.

Good deployment habits:

• Do not edit files directly on the server; every change should come from the repository.
• Keep only tested code on the main branch; run experiments as a second Node.js app on a separate subdomain (for example test.yourdomain.com).
• Take a snapshot dump of the database before every release; never change the schema without a rollback plan.

Passwordless login with an SSH key both improves security and makes it easier for CI to connect to the server; start by adding your SSH key in the panel.

What should you watch for with Express, Next.js, NestJS and Nuxt?

The framework decides how the app is built and which file is the entry point. Lean frameworks such as Express and Fastify run directly; Next.js, Nuxt and NestJS are built first and then started from the build output.

The point most often missed: build and runtime need different resources. A Next.js build can use a lot of memory for several minutes; rather than hitting resource limits on hosting, build on your own computer or in a CI pipeline (GitHub Actions, GitLab CI) and send only the output via Git or SFTP. If your site actually uses no server-side rendering, you can publish a static export on web hosting without Node.js at all.

How do you manage the database and environment variables?

On Linux hosting your Node.js app uses the MySQL or MariaDB database in the same account via localhost; if you need PostgreSQL, MongoDB or Redis, you install them yourself on a VPS. After creating the database in the panel and granting the user access, put the connection details in an environment variable rather than in code.

On the Node.js side, MariaDB works smoothly with the mysql2 driver, Prisma, Drizzle, TypeORM or Sequelize. If you use Prisma, run prisma generate during the build and prisma migrate deploy over SSH after deployment.

Two rules are enough for environment variables:

1. Keep secrets out of the repository. Add .env to .gitignore; put the values in the panel’s environment variable field or in an .env file in the application root that cannot be reached from the web.
2. State the environment explicitly. Without NODE_ENV=production, Express shows detailed error pages, many libraries disable caching and the app slows down noticeably.

Node.js 24 and later can read an .env file without extra packages using node --env-file=.env app.js; using this flag with PM2 or systemd on a VPS makes the dotenv dependency unnecessary.

How do you speed up a Node.js application?

The most effective ways to speed up a Node.js app are running in production mode, serving static files from the web server rather than the app, and caching repeated queries. Node.js runs on a single-threaded event loop, so every synchronous operation that blocks the loop makes all users wait.

• Separate static files: serve images, CSS and JavaScript bundles directly from the web server or a CDN rather than through Express’s express.static middleware.
• Compression and cache headers: compress at the server layer, not in the app; give unchanging assets a long Cache-Control lifetime.
• Avoid synchronous calls: handle work such as fs.readFileSync, parsing large JSON and password hashing (bcrypt) with asynchronous versions or move it to worker threads (worker_threads).
• Connection pooling: do not open a new database connection on every request; use the mysql2 or ORM pool.
• Clustering: on a VPS, PM2’s -i max cluster mode runs the app with as many processes as there are cores.

NVMe storage on LIONFIN Linux hosting plans speeds up reading folders made of tens of thousands of small files such as node_modules; even so, slowness usually comes from an unmeasured query, not the disk. To find it, first identify the slowest endpoint with console.time or an APM tool.

How do you secure and back up a Node.js application?

The foundation of Node.js security is keeping the dependency chain under control, protecting secrets and serving the app only over HTTPS. In the npm ecosystem a project has hundreds of indirect dependencies, and a significant share of attacks come through that chain.

1. Lock file: commit package-lock.json and use npm ci instead of npm install on the server, so exactly the versions you tested get installed.
2. Regular audits: check npm audit output before every deployment and do not leave critical vulnerabilities waiting.
3. Security headers: use the helmet middleware in Express and rate limiting on login and sign-up endpoints.
4. HTTPS: enable the free Let’s Encrypt certificate in the panel and redirect HTTP requests to HTTPS.
5. Application root: source code, .env and node_modules must not sit in a folder that can be downloaded from the web.

For backups, your Git repository already protects the code; what really needs protecting is the database and user uploads. In addition to the hosting account’s automatic backup, export critical databases regularly with mysqldump and store them in another location. If you deploy with version tags (git tag), rolling back from a faulty release to the previous tag takes minutes.

Why does infrastructure matter for Node.js hosting?

However well a Node.js app is written, its response time is shaped by disk speed, network capacity and continuous monitoring. If your API is called on every screen of a mobile app, even a few seconds of downtime reaches users as an error screen.

The main elements of LIONFIN infrastructure that affect your Node.js apps:

• NVMe storage: reading dependency folders and database files involves noticeably less waiting than on SATA SSDs.
• 600 Gbit/s total upstream capacity: reduces the risk of network congestion at peak times and during large downloads.
• RouteFence firewall: network-level DDoS filtering removes attack traffic before it reaches your app.
• 24/7 NOC and SOC monitoring: network and security events are watched at night too; the availability target is 99.99% (a target, not a guarantee).
• Data center in Türkiye: our data center in İzmir suits users in Türkiye and the surrounding region; for projects processing personal data, data location also matters.

On the application side, adding a health check endpoint, running minute-by-minute checks with an external monitoring tool and reading error logs regularly let you see problems before your users do.

What are the most common Node.js hosting errors?

Most Node.js hosting errors come from a wrong startup file, missing dependencies, module system mismatches or resource limits. To find the problem, first check the app log in the panel or the error log in the application folder over SSH.

• 503 or “application failed to start”: the startup file path is wrong or the app throws an exception at startup. Run it manually over SSH with node app.js to see the error.
• “Cannot find module”: dependencies are not installed or the build output (dist) was not uploaded. Run npm ci; in TypeScript projects, start the compiled file.
• “require is not defined in ES module scope”: if package.json contains "type": "module", use import instead of require, or name the file with a .cjs extension.
• EADDRINUSE / port error: a fixed port (for example 3000) is hard-coded; use process.env.PORT.
• Out of memory during build: if you see “JavaScript heap out of memory”, build in CI rather than on the server.
• Changes do not show: restart the app from the panel after updating files; Passenger keeps the old process in memory.

If you cannot solve it, include the application root, Node.js version and the last lines of the error log when you open a support ticket from the customer panel; it speeds up the fix.