Node.js apps are just part of the furniture on Plesk boxes these days \u2014 sitting right next to the PHP sites and static pages we’ve always run. The good part is Plesk actually treats Node.js like a first-class citizen rather than bolting it on: the Node.js extension, which has shipped since Onyx and gotten steadily better through the Obsidian line, gives you a real interpreter version manager, Passenger integration, and a UI that covers most of what used to mean hand-writing systemd units and reverse proxy blocks.<\/p>\n\n\n\n
None of that means it runs itself, though. There’s a strict order you need to follow \u2014 domain setup, then document root, then package.json checks, then dependencies, then picking the right startup file \u2014 and skipping a step is exactly how you end up staring at a 503 with zero clues in the browser. What follows is the process I actually use on production servers, plus the mistakes that generate the most support tickets in my experience.<\/p>\n\n\n\n
You want Plesk Obsidian for this (Onyx still limps along, but it’s EOL \u2014 don’t put new work on it). You’ll also need the Node.js extension installed, which you can check under Tools & Settings > Updates and Upgrades > Add\/Remove Components<\/strong>, or just open a domain and see if “Node.js” shows up in the sidebar. Most license tiers include it, but a few of the stripped-down hosting-only SKUs leave it out, so verify this before you tell a client it’ll just work.<\/p>\n\n\n\n If it’s missing, head to Extensions<\/strong>, search “Node.js,” and install it. That extension is doing all the heavy lifting here \u2014 version manager, Passenger hooks, per-app config panel. Resist the urge to compile Node from source or run your own nvm setup on the shell; Plesk expects to own the interpreter binary paths, and going around it just creates conflicts you’ll be debugging later.<\/p>\n\n\n\n Before you even open the Plesk UI, get your app itself into a deployable state:<\/p>\n\n\n\n Plesk’s version manager keeps multiple Node runtimes installed side by side \u2014 16.x, 18.x, 20.x, whatever your apps need \u2014 without touching the system’s own Node binary or disturbing anything else on the box. Each app picks its version independently, which is exactly what you want on a shared server where one client’s legacy app sits next to something built against a current LTS.<\/p>\n\n\n\n This is where most confusion comes from. Plesk doesn’t launch your app as a bare process bound to some random port managed by PM2 or forever \u2014 it hands the whole thing to Phusion Passenger. Passenger owns the process lifecycle: starting it, killing it, restarting it after a crash, recycling idle workers. It talks to your app over a local socket and does the supervision work you’d otherwise be configuring by hand with systemd or PM2.<\/p>\n\n\n\n The web server layer \u2014 Nginx, sometimes with Apache sitting in front depending on how the server’s configured \u2014 takes the incoming connection and proxies it into Passenger, which then hands it to your app. That’s why things like WebSocket support or upload size limits get configured through Plesk’s Nginx directive panel rather than inside your app’s own routing \u2014 there’s more happening at the web server layer here than you’d get from a plain Node dev server.<\/p>\n\n\n\n More deployments go sideways here than anywhere else. The document root<\/strong> is where the web server pulls static assets from \u2014 usually a A standalone domain or subdomain is the cleanest setup for a Node app \u2014 you get a dedicated document root, its own SSL cert, and its own Node.js config panel. You can run Node under a subdirectory of an existing PHP domain, but it adds real friction since you’re now managing two stacks under one vhost. Unless you’re spinning up a quick proof of concept, just give the app its own subdomain and save yourself the headache.<\/p>\n\n\n\n You’ve got three realistic options: File Manager for a quick drag-and-drop, FTP for bulk transfers, or \u2014 what I’d recommend for anything that’s going to keep getting updated \u2014 the Git extension. With Git, you push to a remote, Plesk pulls the changes, runs Open the Node.js tab on the domain and confirm Plesk actually picked up Same panel \u2014 pick your interpreter version from the dropdown. This setting is per-app, not server-wide, so a new app can run Node 20 while a legacy one sits on Node 16, both on the same box, with zero interference between them.<\/p>\n\n\n\n Use the “NPM Install” button in the panel instead of SSHing in and doing it yourself. Plesk logs the full output right there in the UI, and it runs the install in the same environment Passenger will actually use to serve the app \u2014 which matters more than it sounds like. When an install fails, that log is usually the quickest way to spot a missing native build dependency or a bad private registry credential.<\/p>\n\n\n\n Double-check the “Application Startup File” field points at the right entry point \u2014 Once everything’s set, hit “Restart App.” Plesk restarts just the Passenger process without taking down the rest of the domain’s web service. Going forward, any code change needs a restart triggered one of three ways \u2014 this button, a Git deployment hook, or the API \u2014 because Passenger deliberately won’t pick up file changes on its own in production mode.<\/p>\n\n\n\n Almost every Node.js problem I’ve seen on Plesk boils down to one of these:<\/p>\n\n\n\nEnabling the Node.js Extension in Plesk<\/h3>\n\n\n\n
Preparing Your Application Files<\/h3>\n\n\n\n
\n
package.json<\/code> with a proper start<\/code> script, or at minimum a clearly named entry file like app.js<\/code> or server.js<\/code>.<\/li>\n\n\n\n.gitignore<\/code> or upload package that leaves out node_modules<\/code> \u2014 Plesk runs its own npm install<\/code> anyway, and shipping a local node_modules<\/code> folder just bloats the upload and can conflict with platform-specific native builds.<\/li>\n\n\n\nprocess.env<\/code> instead of hardcoded \u2014 you’ll wire these in through Plesk in a minute.<\/li>\n<\/ul>\n\n\n\nUnderstanding Plesk’s Node.js Architecture<\/h2>\n\n\n\n
The Node.js Extension and Version Manager<\/h3>\n\n\n\n
How Passenger Integrates with Node.js Apps<\/h3>\n\n\n\n
Nginx and Apache’s Role in Request Handling<\/h3>\n\n\n\n
Step 1: Creating a Domain or Subdomain for Your App<\/h2>\n\n\n\n
Setting Document Root vs. Application Root<\/h3>\n\n\n\n
public<\/code>, dist<\/code>, or build<\/code> folder if you’ve got a compiled React front end sitting in front of an Express backend, for example. The application root<\/strong> is a different thing entirely \u2014 it’s the base folder holding package.json<\/code>, and it’s where Passenger actually starts your app. Mix these two up and you’ll either be serving raw source code to the world or watching every static asset 404.<\/p>\n\n\n\nChoosing Between a Domain, Subdomain, or Subdirectory<\/h3>\n\n\n\n
Step 2: Uploading and Configuring the Application<\/h2>\n\n\n\n
Uploading Files via File Manager, Git, or FTP<\/h3>\n\n\n\n
npm install<\/code>, and restarts the app through deployment actions. It’s essentially free CI\/CD without bringing in a separate pipeline tool.<\/p>\n\n\n\nVerifying package.json and Start Script<\/h3>\n\n\n\n
package.json<\/code> correctly. If your start script does something out of the ordinary \u2014 a build step before launch, say, rather than a plain node server.js<\/code> \u2014 make sure that’s properly defined in scripts.start<\/code>. Plesk’s “Run Script” dropdown reads straight from that field, so if it’s wrong there, it’s wrong everywhere.<\/p>\n\n\n\nSelecting the Node.js Version per Application<\/h3>\n\n\n\n
Step 3: Installing Dependencies and Starting the App<\/h2>\n\n\n\n
Running npm install Through Plesk<\/h3>\n\n\n\n
Setting the Application Startup File<\/h3>\n\n\n\n
app.js<\/code>, index.js<\/code>, server.js<\/code>, whatever it is for your app. Set Application Mode<\/strong> to production<\/code> \u2014 this isn’t just a label, it changes real behavior in Express and most other frameworks: error verbosity, caching, how performance-sensitive middleware behaves. Put your environment variables \u2014 NODE_ENV, DB connection strings, API keys \u2014 into Plesk’s “Custom Environment Variables” section, not into a .env<\/code> file that’s sitting in your Git repo.<\/p>\n\n\n\nSwitching Application<\/h3>\n\n\n\n
Best Practices<\/h2>\n\n\n\n
\n
production<\/code> on anything live \u2014 never development<\/code>. The gap in performance and security isn’t subtle.<\/li>\n\n\n\nnpm install && restart<\/code>) rather than manual FTP uploads for anything actively being developed.<\/li>\n\n\n\nTroubleshooting<\/h2>\n\n\n\n