TECHNICAL GEMS

What is Node.js? How to Enable and Use Node.js On A Server. Why it Is Confusing, Giving People Fits, and Extra Work.

What is Node.js?

Node.js is a runtime environment that allows developers to execute JavaScript code on the server side, outside of a web browser. It is built on Google Chrome’s V8 JavaScript engine and is designed around an event-driven, non-blocking I/O model. This architecture makes Node.js lightweight, efficient, and particularly well-suited for high-concurrency, real-time applications such as chat systems, live data feeds, and collaborative tools1456.

Key characteristics of Node.js:

  • Uses JavaScript for server-side programming
  • Single-threaded, non-blocking, and asynchronous
  • Excels at handling many simultaneous connections with minimal resource overhead
  • Ideal for real-time, I/O-heavy applications1456

Why Node.js Must Be Separated from Static Web Server Files

1. Different Roles and Strengths

  • Node.js acts as an application server: It is best used for dynamic content generation, API endpoints, real-time features, and custom server logic. It can serve static files, but that’s not its primary strength36.
  • Traditional web servers (like Apache or Nginx) are optimized for serving static content (HTML, CSS, images, etc.) and executing server-side scripts in languages like PHP156.

2. Performance and Efficiency

  • Static files: Traditional web servers are highly optimized for delivering static files quickly and efficiently, often using caching and minimal overhead.
  • Node.js: While Node.js can serve static files, it is generally slower at this task compared to dedicated static file servers like Nginx or Apache. Using Node.js for static files can introduce unnecessary complexity and performance bottlenecks36.

3. Security and Maintainability

  • Separation of concerns: Keeping static files and Node.js application logic separate helps reduce security risks. For example, PHP files placed in a Node.js directory will not be executed and may be exposed as plain text, potentially leaking sensitive code6.
  • Maintainability: Separating static content from application logic makes the project structure clearer and easier to manage, especially in larger projects with mixed technologies.

4. Hybrid Approaches Are Common

Many modern deployments use a hybrid approach:

  • A traditional web server (Nginx or Apache) serves static files and proxies dynamic requests to a Node.js application server.
  • This setup leverages the strengths of each technology: fast static file delivery and flexible, scalable application logic6.

Summary Table: Node.js vs. Traditional Web Servers

FeatureNode.jsTraditional Web Servers (Apache/Nginx)
Primary UseApplication server, APIs, real-time appsStatic files, PHP, general web hosting
Performance (static files)Good, but not optimalHighly optimized
Performance (dynamic apps)Excellent for I/O-heavy, real-timeGood for PHP, less for JS apps
LanguageJavaScriptPHP, Python, Ruby, etc.
ScalabilityEvent-driven, non-blockingMulti-threaded, blocking (Apache); event-driven (Nginx)
SecurityApplication-specific, customizableMature, robust defaults

Enabling Node.js on a Plesk Linux Server

To enable Node.js functions for all domains on your Plesk for Linux server—so that frameworks and tools like React, Tailwind, and Vite work on any website where needed—follow these steps:

1. Install the Node.js Toolkit Extension

  • Go to Extensions in the Plesk admin interface.
  • Find and install the Node.js Toolkit extension from the Extensions Catalog if you haven’t already123.

2. Enable Node.js Support on the Server

  • Navigate to Tools & Settings > Updates (or Updates and Upgrades).
  • Click on Add/Remove Components.
  • Expand Web hosting and check the box for NodeJS support.
  • Click Continue to install the component23.

3. Manage Node.js Versions

  • Go to Extensions > Node.js Manager (sometimes found under My Extensions).
  • Here you can see which Node.js versions are installed and enabled.
  • Enable the desired Node.js versions by clicking the “tick” icon next to each version you want available12.
  • You can have multiple Node.js versions enabled; domains can select which version to use as needed2.

4. Make Node.js Available to All Domains

  • By default, once Node.js support is enabled and at least one version is active, all domains on your server can use Node.js.
  • Each domain owner or administrator can then enable Node.js for their site via their Plesk panel.

5. Enable Node.js for a Domain (Per Website Setup)

For each website that needs Node.js (e.g., for React, Tailwind, Vite):

  • Go to Websites & Domains and select the domain.
  • Click the Node.js icon.
  • Click Enable Node.js.
  • Choose the desired Node.js version for this domain.
  • Set the Document Root to the folder containing your app (for React/Vite, usually the build or dist directory)4.
  • Use the Plesk interface to install dependencies (npm install), set environment variables, and manage the app lifecycle (start/stop/restart)23.

6. Deploying React, Tailwind, and Vite Projects

  • For React/Tailwind/Vite apps, you typically build the project locally (using npm run build or yarn build), then upload the build output to the appropriate directory on your domain.
  • Alternatively, you can use the Node.js environment in Plesk to install dependencies and build the project directly on the server.
  • Make sure your app’s static files (e.g., the build or dist folder) are correctly referenced as the document root, and configure any necessary rewrites for client-side routing (such as React Router)45.
  • If you need to run a Node.js backend (API server), you can set the entry point (e.g., server.js or app.js) in the Node.js settings for the domain4.

7. Additional Tips

  • You can use either npm or yarn as the package manager, depending on your project3.
  • Each domain can independently manage its Node.js version and environment.
  • For advanced setups (e.g., running both frontend and backend Node.js apps), configure separate subdomains or directories as needed4.

Summary Table: Key Steps

StepWhere in Plesk?Notes
Install Node.js ToolkitExtensionsOnly needed once per server
Enable Node.js supportTools & Settings > UpdatesOnly needed once per server
Enable Node.js version(s)Extensions > Node.js ManagerEnable all versions you want available
Enable Node.js per domainWebsites & Domains > [Domain]Each site must enable Node.js individually
Deploy React/Tailwind/ViteWebsites & Domains > [Domain]Upload/build files, set doc root, configure

Once these steps are complete, all domains on your Plesk server will have the option to enable and use Node.js, allowing you to deploy and run modern JavaScript stacks like React, Tailwind, and Vite as needed123.


Do not just enable Node.js on all Domains

There are a few reasons why you might not want to enable Node.js for a domain in Plesk “just in case” a future app needs it:

  • Security and Attack Surface: Enabling Node.js support adds another layer of software that could potentially be exploited if vulnerabilities are discovered, especially if you are not actively maintaining or updating Node.js or the related application files on that domain.
  • Resource Management: Even if no Node.js app is running, enabling Node.js may allow users to deploy and run Node.js processes, which could consume server resources (CPU, RAM) unnecessarily if not monitored.
  • Simplicity and Clarity: Keeping Node.js disabled on domains that do not need it reduces complexity and avoids confusion for users or administrators who may not be familiar with Node.js.
  • Operational Control: If Node.js is enabled by default, someone could inadvertently deploy an application or start a process that you are not aware of, which could impact server performance or security.
  • Bug/Management Issues: There have been reports of issues where disabling Node.js does not always work as expected, and applications may remain accessible even when Node.js is disabled in the Plesk interface, making it harder to manage the domain’s state cleanly1.

However, enabling Node.js is easily reversible. If you later need Node.js, you can enable it for the specific domain at that time without losing any settings or data3. Disabling Node.js for a domain is straightforward and does not affect existing files or configurations, so you can safely toggle it as needed3.


Enabling Node.js on a directory enables Node.js on all subdirectories as well. That can be a problem if enabling in httpdocs and you want to also add static traditional content to the domain later.

If you set the Document Root to /httpdocs (or httpsdocs) for your Node.js app in Plesk, Node.js will handle all requests to the domain and its subdirectories. This means every page and app within that directory tree will be processed by Node.js, not just specific subdirectories or pages269.

If you want Node.js to only handle a specific subdirectory (e.g., /httpdocs/app), you need to:

  • Set the Document Root for the Node.js app to that subdirectory.
  • This way, only requests to yourdomain.com/app will be handled by Node.js, and the rest of the site (such as the main root or other subdirectories) will continue to be served by your default web server (typically Apache or Nginx)269.

You do not need to enable Node.js separately for every individual page or subdirectory. You only need to enable it for the directory where your Node.js app lives. Everything under that directory will be handled by Node.js as a single application269.

In summary:

  • Setting the Document Root to /httpdocs enables Node.js for the whole site and all subdirectories.
  • To restrict Node.js to a subdirectory, set the Document Root to that subdirectory.
  • No need to enable Node.js for every page/app within subdirectories—just for the parent directory of the app269

When you enable Node.js for a domain or a specific subdirectory (by setting the Document Root in Plesk’s Node.js settings), all requests to that path and its subdirectories are routed through your Node.js application. The web server (Apache or Nginx) proxies those requests to Node.js, which then decides how to handle them based on your app’s code and routing logic179.

  • If the Document Root is set to /httpdocs, then every request to yourdomain.com and any subdirectory (e.g., /about/app/contact) is handled by your Node.js app.
  • If the Document Root is set to /httpdocs/app, then only requests to yourdomain.com/app and its subdirectories are handled by Node.js. Requests to the rest of the site (like / or /blog) are handled by the default web server (serving static HTML, PHP, etc.)17.

There’s no automatic detection:
The server does not inspect code to decide whether to use Node.js or not. Instead, it uses the Document Root setting to determine which requests go to Node.js and which go to the traditional web server. Node.js will handle all requests under the specified directory, and within your Node.js app, you can further control routing (e.g., using Express to define which URLs return what content)157.

Summary Table

Document Root SettingWhat Handles Requests?
/httpdocsNode.js handles all requests
/httpdocs/appNode.js handles /app/*; rest by server

So, you do not need to enable Node.js for every page or subdirectory. The routing is based on the Document Root you configure in Plesk’s Node.js settings, and all requests under that path go to your Node.js app

SO WHEN YOU SET UP NODE.JS ON A DOMAIN, A GOOD PRACTICE IT DO SET UP A DIRECTORY FOR YOUR NODE.JS APPS IF YOU PLAN TO HAVE MIXED CONTENT.

If you have static HTML or PHP files inside a directory managed by Node.js (i.e., the Node.js app’s document root), Node.js will handle all requests to files in that directory. What happens next depends on your Node.js application’s code:

  • Static HTML (and other static assets):
    If your Node.js app is configured to serve static files (using something like Express’s express.static middleware or a custom static file handler), requests for .html.css.js, images, etc., will be served as static files to the browser1345. If you don’t configure static file serving, those files won’t be accessible unless your app explicitly handles those routes.
  • PHP files:
    Node.js does not process PHP files. If you request a .php file and your Node.js app is handling the request, it will either:
    • Serve the file as plain text (if static file serving is enabled and not filtered by extension).
    • Return an error or “not found” if your app doesn’t explicitly handle .php files.
    • It will not execute PHP code, because Node.js does not have a PHP interpreter.

Key point:
Once Node.js is enabled for a directory, the traditional web server (Apache/Nginx) is bypassed for those requests, so PHP files will not be executed as PHP—they are just files to Node.js.


Summary Table

File TypeWhat Node.js Does (by default)
.html, .css, .js, imagesServes as static files if configured in app
.phpServed as plain text or not at all; not executed

To serve static HTML and assets, make sure your Node.js app is set up to serve static files345. If you need PHP execution, those files must be outside the Node.js-managed directory, or you need to configure your server to route PHP requests to the PHP interpreter, not Node.js.


setting up a dedicated subdirectory like /app (and then /app/x for various Node.js apps) is a common and practical approach for domains with mixed codebases (Node.js, PHP, static HTML, etc.). This method offers several advantages:

  • Separation of Concerns: By isolating Node.js apps in their own directory, you keep them logically and operationally separate from static HTML and PHP content, reducing complexity and potential conflicts56.
  • Easier Management: Each Node.js app can be managed, deployed, and updated independently within its own subdirectory, making maintenance simpler56.
  • Security: Isolating apps can help contain any issues or vulnerabilities within a specific subdirectory, rather than exposing the entire site4.
  • Clarity: This structure makes it clear which parts of your domain are powered by Node.js and which are served by the traditional web server, aiding both development and troubleshooting56.

This approach aligns with best practices for organizing code and project directories: grouping related files and modules together, and separating different technologies or application layers for maintainability and scalability156.

In summary:
Using /app for all Node.js-powered pages and further subdirectories like /app/x for individual apps is a widely adopted and recommended strategy for mixed-technology websites.


If you screwed up and enabled Node.js in /httpdocs, you can use the Express framework if you must serve static files inside a Node.js enabled directory. But if you have PHP files, THEY WILL NOT WORK IN A NODE.JS DIRECTORY OR SUBDIRECTORY

Express is a popular web application framework for Node.js. It lets you easily build web servers and APIs in JavaScript. One of its features is the ability to serve static files—like HTML, CSS, JavaScript, and images—directly from a specified directory using built-in middleware called express.static1267.

How to Enable Static File Serving in Express

To serve static files (such as .html.css.js, images, etc.) from a directory in your Node.js app using Express, follow these steps:

  1. Install Express (if you haven’t already):bashnpm install express
  2. Set up your project structure:textyour-project/ ├── index.js # Your main Node.js/Express app └── public/ # Folder for static files ├── index.html ├── style.css └── image.png
  3. Add static file middleware in your Express app:javascriptconst express = require('express'); const path = require('path'); const app = express(); // Serve static files from the 'public' directory app.use(express.static(path.join(__dirname, 'public'))); app.listen(3000, () => console.log('Server running on port 3000'));
    • Now, any file you put in the public directory (like index.html) will be accessible at http://yourdomain.com/index.html12567.
  4. Accessing files:
    • http://yourdomain.com/index.html will serve the HTML file.
    • http://yourdomain.com/style.css will serve the CSS file.

Note:

  • PHP files will not work: Node.js and Express cannot interpret or execute PHP files. If a request is made for a .php file, Express will either serve it as plain text (if static serving is enabled) or return a 404 error if the file doesn’t exist or isn’t allowed12567.

Summary Table

File TypeWhat Express Does with express.static
.html, .css, .js, imagesServes as static files to the browser
.phpServed as plain text or not at all; not executed

In short:

  • Express is a Node.js framework.
  • To serve static files, use express.static() middleware in your app.
  • Place your static files (HTML, CSS, images) in the specified directory.
  • PHP files will never execute via Node.js/Express—they require a PHP interpreter

CLI is back!

Working with Node.js applications—especially when deploying, building, or managing modern JavaScript frameworks (like React, Vite, Tailwind, etc.)—often requires using the command line interface (CLI) via SSH, outside of the Plesk web interface431.

Here’s why:

  • Installing Packages: Tools like npm or yarn (for installing dependencies) are typically run from the terminal.
  • Building Projects: Modern frontend frameworks (React, Vite, etc.) require build steps (e.g., npm run build), which are executed in the CLI.
  • Running Scripts: Node.js applications are started, stopped, or managed using CLI commands (e.g., node app.js or custom scripts defined in package.json)34.
  • Advanced Configuration: Some advanced settings, debugging, or troubleshooting require CLI access to run commands, inspect logs, or manage files directly14.
  • Custom CLI Tools: Many Node.js projects use or create custom CLI tools for automation, deployment, or development tasks25.

Plesk does provide some Node.js management features via its web interface (such as enabling/disabling Node.js, setting environment variables, and running npm install), but for full control—especially for complex workflows or custom scripts—SSH access and CLI usage are often necessary.

In summary:
While Plesk simplifies some Node.js tasks, serious Node.js development and deployment almost always involve the CLI via SSH for installing dependencies, building projects, running scripts, and troubleshooting


Using vercel to deploy your app makes the process easier for non technical users.

Vercel is popular because it automates and abstracts away much of the complexity involved with deploying JavaScript frameworks and Node.js apps, including running npm commands, building, and serving your application256.

Here’s how Vercel simplifies the process:

  • Zero Configuration Deployments: You push your code to a Git repository (like GitHub), and Vercel automatically detects the framework (React, Next.js, Vite, etc.), installs dependencies with npm, runs the build process, and deploys your site or app—no manual CLI steps required for most workflows25.
  • Serverless Functions: For backend/API routes, Vercel automatically creates and manages serverless functions, so you don’t have to set up or maintain a traditional Node.js server135.
  • Integrated CI/CD: Vercel provides built-in continuous integration and deployment, preview URLs for every branch, and instant rollbacks, all managed through a web dashboard or simple CLI commands if you prefer25.
  • Automatic Scaling: Your app scales automatically with demand, without you needing to configure or manage servers248.

Vercel may be easier to deploy on, but comes with many disadvantages

 Vercel, while excellent for deploying modern JavaScript frontends and serverless APIs, comes with several limitations compared to traditional hosting or a full-featured server environment. Here’s a detailed breakdown of the concerns you raised and other disadvantages:

1. Email Server Hosting

  • No Native Email Server: Vercel does not provide email server functionality. You cannot host your own mailboxes or SMTP/IMAP services on Vercel. You must use third-party email providers (like Google Workspace, Zoho, or external SMTP services), which adds complexity and may increase costs562.
  • Limited Email Integration: If you want to send transactional emails from your app, you’ll need to integrate with external APIs (e.g., SendGrid, Mailgun), and you cannot run your own mail server910.

2. Domain Management

  • No Domain Registrar Features: Vercel does not act as a domain registrar. It can manage DNS for domains you point to it, but you must purchase and manage domains elsewhere5.
  • SEO & Branding Concerns: While you can point your own domain to Vercel, some users end up using Vercel’s default URLs (e.g., yourproject.vercel.app), which is not ideal for SEO or branding. Best practice is always to use your own domain, but Vercel does not manage this for you53.

3. Static HTML Directory

  • No Traditional Static Directory: Vercel is designed for modern frameworks (Next.js, React, etc.) and serverless deployments. While it can serve static files as part of a build, you don’t get a traditional, always-accessible public_html or httpdocs directory like on Plesk or cPanel. Managing pure static sites is possible, but not as flexible as with traditional hosts53.

4. Database Hosting

  • No Built-in Database Hosting: Vercel does not host databases. You must use external database services (like Supabase, PlanetScale, MongoDB Atlas, etc.), which can introduce extra latency, complexity, and potential costs672.
  • No Localhost Database Connections: Your app cannot connect to a database on the same server for low-latency access; all database traffic is over the internet to a third-party provider.

5. Backend and Server Control

  • Limited Backend Support: Vercel supports only serverless functions, which are stateless, short-lived (10–60 seconds), and limited in language support. You cannot run persistent background jobs, custom daemons, or stateful processes2367.
  • No Custom Server Configuration: You cannot customize the runtime environment, install custom software, or tweak server settings as you would on a VPS or dedicated server5.
  • No Support for PHP or Other Languages: Vercel does not support running PHP, Ruby, or other traditional server-side languages—only Node.js (and a few others in serverless functions)23.

6. Vendor Lock-in and Portability

  • Vendor Lock-in: Vercel’s platform-specific features (like serverless functions, edge middleware, and proprietary deployment workflows) make it harder to migrate your project to another provider without significant changes5.
  • Abstracted Infrastructure: You have limited visibility and control over the underlying infrastructure, which can be a drawback for advanced users or those with specific compliance needs5.

7. Other Disadvantages

  • No Background Jobs: You cannot run cron jobs, scheduled tasks, or long-running processes natively—these must be offloaded to other services674.
  • Cold Starts and Function Timeouts: Serverless functions can experience cold starts (slower first response after inactivity) and are subject to strict execution timeouts, which can impact user experience for some workloads67.
  • Scaling Costs: While Vercel’s free tier is generous, costs can rise quickly as your project scales or requires advanced features3.
  • Complexity for Large Projects: Managing large, complex applications or monorepos can become challenging on Vercel compared to traditional hosting environments5.

Summary Table

FeatureVercel Limitation/Disadvantage
Email ServerNot supported; must use external provider
Domain ManagementNo registrar; must manage/purchase domains elsewhere
Static HTML DirectoryNo traditional static directory; less flexible for pure static sites
Database HostingNot included; must use external DBaaS
Backend SupportOnly serverless functions; no persistent/background processes
Server ControlNo root/server access; limited customization
Language SupportNo PHP, Ruby, etc.; limited to supported serverless languages
Vendor Lock-inPlatform-specific features make migration harder
Background JobsNot supported natively; must use external schedulers
Function TimeoutsServerless functions have strict time limits and potential cold starts
Scaling CostsFree tier limited; costs can rise quickly with usage
Large ProjectsCan be complex to manage at scale

In summary:
Vercel is good for modern JavaScript apps with simple deployment needs, but it lacks many features of traditional hosting: no email server, no built-in database, limited backend support, no PHP, and less control over domains and infrastructure. For projects needing these features, a traditional host or VPS with Plesk/cPanel remains a better fit

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *