Node.js Hosting on Windows: Setup, Versions, and Compatibility (Node 18 to 24) Print

  • 0

Overview

Node.js is available on all Adaptive Web Hosting ASP.NET hosting plans (Developer, Business, and Professional). Your Node.js application runs on Windows Server behind IIS, managed through the Node.js feature in your Plesk control panel — alongside any ASP.NET / .NET or Blazor sites on the same plan. You enable and configure it yourself; no support ticket is required to get started.

Which Node.js version is installed

We run the current Long-Term Support (LTS) release: Node.js 24 ("Krypton"), supported upstream until approximately April 2028. We keep a single current LTS line installed and patched so every site runs on a secure, maintained runtime.

Node.js maintains strong backward compatibility between major versions, so the large majority of applications written for Node.js 18, 20, or 22 run on 24 with no code changes. See Running applications built for earlier Node.js versions below for the handful of things to check.

Why a single current LTS line?

Older Node.js lines (18 and 20) have reached end-of-life upstream and no longer receive security patches. Standardizing on the active LTS (24) means your runtime keeps getting security and stability fixes, which protects every application on the platform. If your app currently targets an older version, you do not need to change your code in most cases — it simply runs on the newer, supported runtime.

Enabling Node.js for your website

Node.js is enabled per domain. From your Plesk control panel:

  1. Go to Websites & Domains and select the domain (or subdomain) that will run your Node.js app.
  2. Click the Node.js icon, then click Enable Node.js. The installed 24 LTS runtime is selected automatically.
  3. Set the Document Root (where static files are served from) and the Application Root (the folder containing your app and its package.json).
  4. Set the Application Startup File — the file that boots your server, for example app.js, server.js, or index.js.
  5. Click NPM install to install the dependencies listed in your package.json.
  6. Set Application Mode to production for live sites.
  7. Click Restart App to apply your changes.

Important: Plesk runs Node.js behind IIS and generates the required web.config for you — you do not need to create one by hand. Any time you change the startup file, environment variables, or run a new NPM install, click Restart App so the changes take effect.

Listening on the correct port

Because your app runs behind IIS, it must listen on the port that the platform assigns through the PORT environment variable — not a hard-coded port. Use:

const port = process.env.PORT || 3000;
app.listen(port, () => console.log('App listening on ' + port));

The || 3000 fallback only applies when you run the app locally; in hosting, process.env.PORT is always set for you.

Configuring package.json

Make sure your package.json declares your entry point and a start script:

{
  "name": "my-node-app",
  "version": "1.0.0",
  "main": "server.js",
  "scripts": {
    "start": "node server.js"
  },
  "engines": {
    "node": ">=18"
  }
}

The engines field documents the minimum version your app expects; the platform runs Node.js 24 regardless, so keep this permissive (for example >=18) rather than pinning to an exact old version.

Environment variables

Set application environment variables (such as NODE_ENV, database connection strings, or API keys) in the Custom environment variables section of the Node.js panel, then restart the app. Avoid committing secrets to your source files.

Running applications built for earlier Node.js versions

You can deploy applications originally written for Node.js 18, 20, or 22 — they run on the installed 24 LTS runtime. Node.js is highly backward compatible, so most apps work unchanged. The table below summarizes each line:

Node.js lineCodenameUpstream status (2026)On our hosting
24 LTSKryptonActive LTS — supported to ~April 2028Installed & recommended
22 LTSJodMaintenance — supported to ~April 2027Apps run on the 24 LTS runtime
20 LTSIronEnd-of-life (April 2026)Apps run on the 24 LTS runtime
18 LTSHydrogenEnd-of-life (April 2025)Apps run on the 24 LTS runtime

Recommendation: Node.js 18 and 20 have passed upstream end-of-life and no longer receive security updates. If your application still targets one of these, plan to update your dependencies and test against Node.js 24 (or at least the supported 22 LTS) so you stay on a maintained codebase. Your app will run today either way — this is about keeping your dependencies current and secure.

Compatibility checklist: moving an app to Node.js 24

Before deploying an app that previously ran on an older Node.js version, work through this list:

  • Rebuild native modules. Packages with compiled C/C++ add-ons (for example bcrypt, sqlite3, sharp, canvas) are built against a specific Node.js ABI and must be recompiled for the new major version. Re-run NPM install from the Plesk Node.js panel, or run npm rebuild, so binaries are rebuilt against Node.js 24.
  • Review legacy OpenSSL usage. Node.js 18 and later use OpenSSL 3. Code relying on older or non-default algorithms can throw ERR_OSSL_EVP_UNSUPPORTED. Update the affected crypto code rather than relying on legacy-provider workarounds long term.
  • Check for removed or deprecated APIs. Long-deprecated patterns (legacy url.parse() usage, the built-in punycode module, old Buffer() constructors) may warn or fail on newer majors. Update to current equivalents.
  • Update dependencies. Bring packages to versions that officially support Node.js 24, and refresh your package-lock.json. Node.js 24 ships with npm 11, which is stricter about peer dependencies.
  • Test locally first. Install Node.js 24 on your machine (for example via nvm install 24) and run your test suite before deploying.

Version-by-version notes (Node.js 18 to 24)

Node.js 18 (Hydrogen)

Reached end-of-life on 30 April 2025. Introduced the global fetch() API and the move to OpenSSL 3. Apps run on the 24 runtime; update dependencies and re-test, as this line no longer receives security fixes.

Node.js 20 (Iron)

Reached end-of-life in April 2026. Stabilized the built-in test runner and the permission model. Apps run on the 24 runtime; treat it as legacy and plan to modernize.

Node.js 22 (Jod)

In maintenance support until approximately April 2027 — still supported upstream. A good minimum target if you cannot move to 24 immediately. Apps run on the 24 runtime here.

Node.js 24 (Krypton)

The current active LTS, supported to approximately April 2028 — this is what we install and recommend. Ships with an updated V8 engine and npm 11, plus ongoing performance and security improvements. Target this line for new applications.

Connecting to a database

Every plan includes Microsoft SQL Server 2022 and MariaDB, and your Node.js app can connect to either:

  • SQL Server 2022 — use the mssql package (built on the Tedious driver). Connect with the database host, name, username, and password shown in Plesk.
  • MariaDB / MySQL — use the mysql2 package.

Store connection credentials in environment variables (see above) rather than in your source code.

Troubleshooting

  • App will not start / 503 error: Confirm the Application Startup File is correct and that your app listens on process.env.PORT. Click Restart App after any change.
  • Port binding error: Do not hard-code a port number. You must use process.env.PORT so IIS can route to your app.
  • Native module errors after deploy: Re-run NPM install (or npm rebuild) so compiled modules are rebuilt for Node.js 24.
  • Dependencies missing: Ensure package.json is in your Application Root, then run NPM install from the Node.js panel.
  • Environment variable not applied: Add it under Custom environment variables and click Restart App.

Recommendations

  • Target the current LTS (Node.js 24) for new applications.
  • Keep dependencies up to date and commit your package-lock.json for reproducible installs.
  • Always listen on process.env.PORT and set NODE_ENV=production for live sites.
  • Do not rely on end-of-life Node.js lines (18, 20) for long-term security — modernize when you can.

Need help?

If your application will not start after following this guide, open a support ticket from the client area and include: your domain name, the Application Startup File you set, and the error shown in your application logs. Our team monitors tickets Monday–Friday 9–6 EST, with 24/7 coverage for production-impacting issues.


Was this answer helpful?

« Back