If you think shared hosting is only for PHP sites, Node.js changes that conversation. On the right server setup, you can deploy a Node.js application on DirectAdmin shared hosting and run anything from a small Express website to a lightweight API without jumping straight to a VPS. DirectAdmin’s own documentation includes Nginx Unit for application hosting, and DirectAdmin also lists Node.js among the languages supported through that stack.
That matters because Node.js is the runtime that lets developers run JavaScript on the server, while Express is one of the most widely used web frameworks built on top of Node.js. In simple terms, if your hosting account supports Node.js properly, it can also support an Express app.
The important detail is that not every DirectAdmin server is configured the same way. Some hosts provide Node.js deployment through DirectAdmin Nginx Unit, while others may offer CloudLinux Node.js Selector or a similar application manager. CloudLinux’s documentation specifically says Node.js Selector can deploy Node.js applications on cPanel or DirectAdmin servers running Apache, so the exact method depends on how your hosting provider built the platform.
In this guide, I’ll walk you through both possibilities in a simple, practical way. You’ll learn how to check whether your DirectAdmin account supports Node.js, how to prepare your app for shared hosting, how to upload it correctly, and how to get it running without the usual startup errors that frustrate most first-time deployments. For readers working with Python instead of JavaScript, we already covered how to deploy Django on DirectAdmin shared hosting and how to deploy Flask or FastAPI on DirectAdmin shared hosting. If you later outgrow shared hosting and need full server control, you can also read our guide on how to self-host n8n on a VPS with Docker Compose.
Yes, you can run Node.js or Express on DirectAdmin shared hosting, but only if your hosting provider has enabled the required application support. DirectAdmin documents Node.js deployment through Nginx Unit, and it places that functionality under the user-level interface when it is available on the server.
This is where many users get confused. The answer is not just “DirectAdmin supports Node.js” in every case. The real answer is that your host needs to provide the correct application layer. On some servers, that is Nginx Unit. On others, especially CloudLinux-based shared hosting setups, it may be Node.js Selector. CloudLinux says Node.js Selector allows deployment of Node.js applications on cPanel or DirectAdmin running Apache, which is why two different DirectAdmin hosts can offer very different Node.js experiences.
If your account supports Node.js, running Express is straightforward because Express is simply a Node.js framework, not a separate runtime. The official Express site describes it as a fast, minimalist web framework for Node.js, which means the main requirement is still proper Node.js application support on the hosting account.
So before you upload any files, the best first step is to check your DirectAdmin panel for an application feature such as Nginx Unit, Node.js setup, application manager, or a CloudLinux Selector-style option. If you do not see any of those tools, contact your hosting provider and ask whether your plan supports Node.js applications on DirectAdmin. That quick check can save you a lot of time and prevent you from trying to force a Node.js app onto a plan that was never configured for it.
What You Need Before You Start
Before you upload anything, make sure you have the right basics in place. The first requirement is a DirectAdmin hosting account that actually supports Node.js applications. On servers where this is enabled, DirectAdmin says you can create an application from User Level → Advanced Features → Nginx Unit → Create application, using the built-in NodeJS template. That is the clearest sign that your account is ready for a Node.js or Express deployment. DirectAdmin Nginx Unit
You should also have a domain or subdomain already added to your hosting account, access to DirectAdmin File Manager or FTP, and ideally SSH access for installing packages and checking errors. If your provider uses a CloudLinux-based shared hosting stack instead of Nginx Unit, they may expose a Node.js deployment tool such as Node.js Selector, which CloudLinux documents for cPanel or DirectAdmin environments running Apache.
Check Whether Your DirectAdmin Account Supports Node.js
Your application itself should be prepared like a normal production Node.js app, but before that, confirm that your hosting account can actually run one. In DirectAdmin, the most obvious sign is the presence of Nginx Unit under advanced features. If your host is using CloudLinux, you may instead see a Node.js setup tool, application manager, or selector-based interface.
If you are not sure, ask your hosting provider a direct question: Does my DirectAdmin plan support Node.js or Express apps through Nginx Unit or CloudLinux Node.js tools? That quick check can save you from wasting time uploading an app to a plan that only supports standard PHP hosting.
Your application should be prepared like a normal production Node.js app. At minimum, you need a valid package.json, your main startup file such as server.js, app.js, or index.js, and all runtime packages listed under dependencies. npm’s official documentation explains that packages your project needs should be listed in dependencies or devDependencies in package.json, and that npm install uses that file to download what the application needs. In practice, anything required to run the live app should be in dependencies, not only in devDependencies. npm package.json dependencies
It is also important to make sure your app is written to use environment-based settings instead of hardcoded values. The official Node.js environment variables documentation explains how environment variables are exposed to applications, and apps read them from process.env. That means your app should be ready to accept values such as PORT, NODE_ENV, database credentials, and API keys from the hosting environment rather than from hardcoded strings inside the code.
A simple Express application for shared hosting usually looks like this: one main startup file, one package.json, and a clear app root directory with only the files needed in production. That is one reason Express works well for lightweight apps on shared hosting. If you are comparing stacks before you deploy, you can also see our guides on deploying Django on DirectAdmin shared hosting and deploying Flask or FastAPI on DirectAdmin shared hosting to decide which framework fits your project best.
Before You Move to the Upload Stage
Take one minute inside your DirectAdmin panel and look for one of these options: Nginx Unit, Node.js Setup, Application Manager, or a CloudLinux Selector-style app tool. If you find one of them, you are in good shape. If you do not, ask your host before moving forward.
Once you confirm support, the next step is to prepare your Node.js or Express app properly for shared hosting. That includes choosing the correct startup file, making sure the app listens on the correct port, cleaning up unnecessary local files, and getting it ready for upload. If your project eventually needs background workers, containers, or full process control, that is usually the point where a VPS becomes the better fit, and our guide on how to self-host n8n on a VPS with Docker Compose shows what that next step looks like.
Before you upload your project, make sure the application is structured for production. At minimum, your app should have a valid package.json, a clear startup file such as server.js, app.js, or index.js, and all required runtime packages listed under dependencies. npm’s official documentation explains that npm install reads package.json, installs the project dependencies, and respects lockfiles such as package-lock.json when they are present.
Your app should also be ready to read values from the hosting environment instead of relying on hardcoded settings. Node.js documents process.env as the basic API for accessing environment variables, which is exactly how shared hosting panels usually pass values like PORT, NODE_ENV, database credentials, and API keys into your application. Express also recommends setting NODE_ENV to production for better production behavior.
If you are deploying an Express app, keep the startup file simple and make sure it listens on the port provided by the environment. Express remains a lightweight framework on top of Node.js, which is one reason it is a strong fit for smaller shared hosting deployments.
const express = require('express');
const app = express();const PORT = process.env.PORT || 3000;app.get('/', (req, res) => {
res.send('Node.js app is running on DirectAdmin shared hosting');
});app.listen(PORT, () => {
console.log(`Server running on port ${PORT}`);
});If your application uses secrets, keep them out of the repository and out of any public web directory. Node.js documents environment variables and .env-style configuration handling, and Express guidance also recommends storing sensitive values such as secrets in environment variables rather than hardcoding them.
If you are still deciding between JavaScript and Python for your project, you can also compare this process with our guides on how to deploy Django on DirectAdmin shared hosting and how to deploy Flask or FastAPI on DirectAdmin shared hosting.
Upload Your Node.js App to DirectAdmin
Once the app is ready, upload only the files you actually need in production. In most cases, the easiest approach is to compress the project into a zip file on your computer, upload it through DirectAdmin File Manager, and extract it inside the application directory. If your project is larger, or if you prefer working locally with a code editor, SFTP or FTP can also work well.
Try to keep the uploaded project clean. Do not send unnecessary local files such as test artifacts, cache directories, large local logs, or development-only backups. Shared hosting works best when the application root contains the essentials only: your startup file, package.json, application code, static assets, and any production configuration your host expects.
If your provider has enabled DirectAdmin’s application layer through Nginx Unit, you will typically upload the app first and then create the application from User Level → Advanced Features → Nginx Unit → Create application, selecting the NodeJS type. If your provider uses CloudLinux Node.js Selector, the interface may look different, but the idea is the same: upload the code, point the tool to the app root, and define the startup file.
A good practice is to deploy the app on a subdomain first, such as app.yourdomain.com, before replacing the main site. That gives you room to test routing, environment variables, and package installation without affecting your primary website.
Install Dependencies
After the files are in place, install the dependencies from inside the project directory. If your hosting plan includes SSH access, this is usually as simple as moving into the app folder and running:
npm installnpm’s documentation states that npm install installs the dependencies for the current project and uses the dependency information from package.json, with lockfile precedence when a lockfile is present.
If your project already includes a package-lock.json, you can also use:
npm ciAccording to npm, npm ci is designed for clean, repeatable installs and requires an existing lockfile. It is especially useful when you want deployment installs to match the locked dependency tree exactly.
Also make sure your package.json includes a proper startup script if your host expects one. npm documents the "scripts" section as the place where commands such as npm start are defined and run. A simple example looks like this:
{
"scripts": {
"start": "node server.js"
}
}That small detail can prevent a lot of startup issues on shared hosting panels that try to launch the app using the project’s start command.
If your hosting account does not provide SSH, check whether the panel includes a built-in install or restart button inside the Node.js application area. This is more common on CloudLinux-based app selectors and managed shared hosting environments. If there is no install option and no terminal access, ask your hosting provider how they expect Node.js dependencies to be installed on your plan. CloudLinux documents Node.js Selector specifically as a deployment feature for DirectAdmin and cPanel servers running Apache, so the exact workflow depends on how the host exposes that functionality to end users.
Once your dependencies are installed, the next step is the actual app setup inside DirectAdmin: choosing the app root, defining the startup file, creating the route, and starting or restarting the application. If your project eventually grows beyond shared hosting limits and you need full process control, reverse proxy tuning, or container-based deployment, that is usually when it makes sense to move to a VPS. For that stage, see our guide on how to self-host n8n on a VPS with Docker Compose.
Method 1: Deploy Node.js with Nginx Unit in DirectAdmin
If your hosting provider uses DirectAdmin Nginx Unit, this is usually the cleanest way to deploy a Node.js or Express app on shared hosting. DirectAdmin’s own documentation says you can log in as the user, go to User Level → Advanced Features → Nginx Unit → Create application, and then select the NodeJS type from the available templates. After saving, DirectAdmin shows a success message and prompts you to create the suggested route for the application.
When creating the app, set the application root to the folder where you uploaded your project, and choose the correct startup file such as server.js, app.js, or index.js. This step matters because the startup file is what DirectAdmin and Nginx Unit will use to launch the application. If the wrong file is selected, the app may fail to start even if the upload itself was correct.
After the application is created, accept or configure the route that maps the domain or subdomain to the app. DirectAdmin specifically notes that after saving the application, it can suggest a route based on the selected template. That route is what tells the control panel how incoming requests should reach your Node.js app.
At this point, test the site in your browser. If the homepage loads, the app is reachable. If it does not, the most common causes are a wrong startup file, missing dependencies, or an application path that does not match the real upload location. Because DirectAdmin’s Nginx Unit docs center the setup around the application root and route, those are the first places to check when something is not working.
Method 2: Deploy Node.js with CloudLinux Node.js Selector or Similar Tools
Some DirectAdmin shared hosting servers use CloudLinux Node.js Selector instead of Nginx Unit. CloudLinux documents Node.js Selector as a feature that allows users to deploy Node.js applications on cPanel or DirectAdmin running Apache web server, which is why some hosts show a selector or application manager instead of the Nginx Unit interface.
In a CloudLinux-based setup, you will usually be asked for the app root, app URL or URI, Node.js version, and startup file. CloudLinux’s command-line documentation for Node.js Selector shows these same core values when creating an application: app-root, app-uri, version, and startup-file. Even if your hosting provider gives you a graphical interface instead of command-line access, those are still the main settings behind the scenes.
Choose the app root carefully so it points to the folder where your project lives. Then set the startup file to the file that actually starts the application. After that, install dependencies if your panel offers an install option, or use SSH if your hosting plan includes terminal access. Once everything is configured, restart the app from the panel so the new configuration is loaded. CloudLinux’s documentation also notes that users can create and manage Node.js applications through its selector tooling, which is why you may see start, stop, and restart controls on supported hosting plans.
If your host uses a custom label such as Application Manager, Node.js Setup, or Setup Node App, do not worry too much about the name. The important thing is whether the tool lets you choose a Node.js version, define an app root, set a startup file, and restart the application after deployment. Those are the settings that matter most for a successful launch.
Point Your Domain or Subdomain to the App
A subdomain is usually the safest way to launch your Node.js app for the first time. Instead of replacing your main site immediately, deploy the app to something like app.yourdomain.com or api.yourdomain.com. This gives you room to test routing, dependencies, and environment variables before using the primary domain for production traffic. This approach fits well with both DirectAdmin route creation in Nginx Unit and CloudLinux-style app URI mapping.
If you are using Nginx Unit inside DirectAdmin, pay close attention to the suggested route after the application is created. If you are using CloudLinux Node.js tools, pay attention to the app URI or path mapping. In both cases, the goal is the same: incoming traffic from the chosen domain or subdomain must be directed to the correct Node.js application root.
Before you point your main domain to the app, open the test URL in your browser and confirm that the homepage loads correctly, static assets work, and your routes respond as expected. That small testing step prevents a broken deployment from affecting your live website. If you are also building apps in other frameworks, this is similar to the staging-first approach we discussed in our guides on deploying Django on DirectAdmin shared hosting and deploying Flask or FastAPI on DirectAdmin shared hosting.
Set Environment Variables for Production
Before going live, configure your application for production. The official Node.js environment variables documentation explains that process.env is the basic API for reading environment values inside your application. That means your app should read values like PORT, NODE_ENV, API keys, database credentials, and secret tokens from the environment instead of hardcoding them inside your code.
For Express apps, this matters even more because the Express production best practices documentation explicitly recommends setting NODE_ENV to production. Express also notes in its API reference that process.env.NODE_ENV controls the environment mode and should be set to production on a production server.
If your app uses sessions or other secrets, keep them out of the repository and store them in environment variables. Express’s own session middleware documentation says a best practice is to store the secret in environment variables so the secret does not exist in your repository. That is especially important on shared hosting, where clean separation between code and secrets makes deployments safer and easier to maintain.
After you add or update environment variables, restart the application from the control panel so the new values are loaded. Whether your host uses DirectAdmin Nginx Unit or a CloudLinux-based tool, a restart is usually required before changes to runtime configuration take effect. Once the app restarts successfully, test the key pages again and make sure your forms, database connection, and API routes all work in production mode.
If you eventually reach the point where you need deeper process control, custom reverse proxy behavior, multiple background workers, or container-based deployment, shared hosting may start to feel limiting. That is usually when moving to a VPS becomes the better option, and our guide on how to self-host n8n on a VPS with Docker Compose shows what a more flexible deployment path looks like.
Test Your Node.js or Express App
Once your app is deployed, open the full domain or subdomain in your browser and test the homepage first. If you are using Express, the framework’s own examples show the app listening on a port and responding to routes normally, which is exactly what you want to confirm after deployment. Also check a few real URLs, not just /, so you know routing is working properly. (expressjs.com)
After that, test static assets such as images, CSS, JavaScript bundles, and any uploads your app needs to serve. Express documents express.static() as the built-in middleware for serving static files, so if your assets are missing, the issue is often the static path or directory structure rather than the hosting panel itself. (expressjs.com)
It is also worth testing your app in production mode. Express recommends setting NODE_ENV=production for production environments, and its production best practices highlight this as an important environment-level setting. If your app behaves differently after deployment than it did locally, environment configuration is one of the first things to verify. (expressjs.com)
Common Errors and How to Fix Them
A very common problem is that the app does not start at all. In that case, check the startup file first. In DirectAdmin Nginx Unit, the application is created around the selected template, app details, and generated route, so using the wrong startup file or wrong app root can prevent the application from launching. If your host uses a panel button that relies on npm scripts, it is also helpful to verify that your project has a valid start script. npm documents that npm start runs the command in the "start" script, and if no start script exists, npm falls back to node server.js. (docs.npmjs.com)
Another common error is Cannot find module. That usually means dependencies were not installed correctly, were installed in the wrong location, or a required package was placed in devDependencies instead of dependencies. npm states that npm install installs packages from package.json, so this is one of the first fixes to try if the app fails right after startup. (docs.npmjs.com)
If your app loads but environment-based settings do not work, check how you are reading configuration values. Node.js documents process.env as the basic API for working with environment variables, so the app should read values such as PORT, NODE_ENV, API keys, and database credentials from there. After changing environment variables, restart the app so the new values are loaded into the running process. (nodejs.org)
If your CSS, images, or client-side JavaScript files are broken, verify your static file configuration. Express documents express.static(root) for serving static assets and notes that files are looked up relative to the configured static directory. In other words, a wrong public folder path can break the frontend even when the server itself is running correctly. (expressjs.com)
If your host uses CloudLinux Node.js Selector and you see an ERR_REQUIRE_ESM-style startup failure, check whether your app is using ECMAScript modules in a way the platform does not support. CloudLinux documents that Node.js Selector uses mod_passenger and notes a limitation: Passenger cannot load ECMAScript modules directly and can only load CommonJS modules unless you use a wrapper approach. That is a very specific but very real issue on some shared hosting setups. (docs.cloudlinux.com)
For many small websites, dashboards, internal tools, and lightweight APIs, shared hosting can be a reasonable starting point for Node.js. DirectAdmin’s current platform documentation says Nginx Unit can run frameworks such as Express, Django, Flask, and Laravel, which shows that modern DirectAdmin environments are designed to handle more than just classic PHP hosting.
That said, this is where practical planning matters. Express’s production best practices recommend operational features such as automatic restarts, clustering, caching, reverse proxies, and load balancing for stronger production reliability. Those are all possible ideas, but shared hosting usually gives you less control over them than a VPS does. So shared hosting is often best for simpler projects, while larger apps, background workers, websocket-heavy systems, and more advanced deployment patterns are usually a better fit for a VPS or container-based setup. This is an inference based on the operational features Express recommends for production and the more limited control typical of shared environments. (expressjs.com)
If you reach the point where you need that extra flexibility, it makes sense to move up to infrastructure you control directly. That is exactly where a guide like how to self-host n8n on a VPS with Docker Compose becomes useful, because VPS hosting gives you much more control over services, restarts, reverse proxies, and scaling patterns.
DirectAdmin shared hosting is easier to start with because the control panel handles much of the setup for you. If your host has enabled Nginx Unit or CloudLinux Node.js Selector, you can often deploy an app without building your own full server stack. That lower complexity is one of the biggest advantages for beginners and smaller projects.
A VPS becomes more attractive when you need deeper control. Express’s production guidance specifically discusses restarts, clustering, reverse proxies, caching, and load balancing as part of running apps reliably in production. Those needs are usually easier to meet on a VPS, where you can choose your own process manager, reverse proxy configuration, deployment flow, and system-level tuning. (expressjs.com)
The easiest rule is this: start on shared hosting if your app is simple and your provider already supports Node.js well, but move to a VPS once your app needs more control than the panel can comfortably provide. If you are also evaluating framework choices, compare this workflow with our guides on deploying Django on DirectAdmin shared hosting and deploying Flask or FastAPI on DirectAdmin shared hosting.
Final Thoughts
You can absolutely deploy Node.js or Express on DirectAdmin shared hosting, but the real requirement is not DirectAdmin alone. The important part is whether your provider has enabled the right application layer, typically DirectAdmin Nginx Unit or a CloudLinux Node.js Selector-based setup. Once that support exists, the process becomes much more straightforward: upload the app, install dependencies, choose the correct startup file, set the route, add environment variables, and test carefully.
For best results, start with a small app, deploy it on a subdomain first, and confirm everything works before moving production traffic onto it. That gives you the safest path to launch and makes troubleshooting much easier if something goes wrong.
Frequently Asked Questions
Yes, if your hosting provider has enabled Node.js application support. DirectAdmin documents Node.js deployment through Nginx Unit, and CloudLinux documents Node.js Selector for DirectAdmin or cPanel environments running Apache.
Yes. Express is a Node.js framework, so if your DirectAdmin hosting account supports Node.js applications, it can also run Express apps. (expressjs.com)
Do I need SSH to deploy Node.js on DirectAdmin?
Not always. Some hosts expose app creation, dependency installation, and restart controls through Nginx Unit or CloudLinux Selector-style tools. SSH still helps a lot with package installation and debugging, but it is not always required.
What startup file should I use for Node.js on DirectAdmin?
Use the file that actually starts your app, usually server.js, app.js, or index.js. If your host relies on npm scripts, npm documents that npm start runs the "start" script and otherwise falls back to node server.js.
Why are my static files not loading in Express?
The most common reason is a bad static path. Express documents express.static() as the built-in middleware for serving files from a specific directory, so a wrong folder path or missing middleware can prevent assets from loading. (expressjs.com)
It can be good for smaller apps and lighter workloads. For larger projects that need more restart control, clustering, reverse proxy tuning, caching, or broader scaling control, a VPS is usually the better choice. This is a practical inference supported by Express’s production guidance.
What if my DirectAdmin host does not support Node.js?
If there is no Nginx Unit, Node.js setup tool, or CloudLinux-style Node.js selector in your account, ask your host directly whether your plan includes Node.js support. If not, you will likely need a different hosting plan or a VPS.