How to Run Node.js and Python Apps on cPanel With CloudLinux Selector

cPanel is known for PHP hosting, but on servers running CloudLinux you can also run Node.js and Python applications from the control panel, with no root access and no process manager of your own. The tools are called Node.js Selector and Python Selector, and in cPanel they appear as Setup Node.js App and Setup Python App under the Software section. You pick an interpreter version, point the tool at an application folder and a URL, and it runs the app for you behind Apache using Phusion Passenger. This guide shows how to deploy a Node.js app and a Python app step by step, how to manage them afterward, and how to fix the errors people hit most often. The steps follow CloudLinux’s own documentation.

What the Selectors are and what must be enabled#

Each Selector has two sides. The server administrator turns the feature on and installs the interpreter versions. The account owner then creates and manages apps. If one side is missing, the other does nothing.

If you do not see the icon in your cPanel, the Selector is switched off on your server. CloudLinux hides the icon when the feature is disabled, so the fix is a request to your host, not a setting in your account. cPanel also has a separate tool called Application Manager that runs Passenger apps directly. It is a different route, and this guide does not cover it.

Deploy a Node.js app#

1. Plan the folder. Keep the application in its own folder in your home directory, for example nodeapp, not inside public_html. Anything inside the document root can be requested by URL, including source files and configuration. The application root you give the Selector is a path relative to your home directory, and the Selector connects it to the URL you choose.

2. Open the tool. In cPanel go to Software, then Setup Node.js App, and click Create Application.

3. Fill in the form.

• Node.js version: pick from the versions your host has installed.
• Application mode: Production or Development. Use Production for a live site.
• Application root: the folder from step 1, such as nodeapp.
• Application URL: the domain, and a path if the app should live below the root of the site.
• Application startup file: the entry file, written as a .js file name such as app.js.
• Passenger log file: an optional path for the app’s log, which makes troubleshooting much easier.

Click Create. The Selector sets up an isolated environment for the chosen Node.js version and lists the app in the Web Applications table, with its URL, root, mode and status.

4. Upload the code. Put your files in the application root, using File Manager, FTP or Git. A minimal app.js for a first test:

const http = require('http');

const server = http.createServer((req, res) => {
  res.writeHead(200, { 'Content-Type': 'text/plain' });
  res.end('Hello from Node.js on cPaneln');
});

server.listen();

Passenger chooses the port the app listens on, so do not build anything around a fixed port number. The same applies to Express and other frameworks. Call listen as you normally would and let Passenger handle the connection.

5. Install dependencies from the interface. Open the app’s edit page and click Run npm install. It installs the packages listed in your package.json into the app’s environment. Dependencies are kept in that environment and linked into the app folder, so do not upload your own node_modules folder. If your project needs a build step, the Run JS Script button runs any script from the scripts section of package.json, which you can use for a command such as build before starting the app.

6. Restart and test. Click Restart on the app, then open the URL. You should see the test message.

Deploy a Python app#

1. Open the tool. In cPanel go to Software, then Setup Python App, and click Create Application. Do not name an app after a Python version, for example “python37” or “python311”. CloudLinux warns that such names cause unexpected errors.

2. Fill in the form.

• Python version: required, chosen from the list your host installed.
• Application root: required, the folder that holds the app, relative to your home directory.
• Application URL: the domain and optional path where the app will answer.
• Application startup file: the file with the WSGI callable. The default is passenger_wsgi.py.
• Application entry point: the name of the WSGI callable. The default is application.
• Passenger log file: an optional log path.

3. Add the code. With the defaults, create passenger_wsgi.py in the application root:

def application(environ, start_response):
    start_response('200 OK', [('Content-Type', 'text/plain')])
    return [b'Hello from Python on cPaneln']

For a Flask or Django project, import your framework’s app object under the entry-point name instead. For example, in passenger_wsgi.py, write from myproject import app as application. You do not need the code that re-launches Python with a virtual environment path that some older guides use. The Selector already runs the app with the version you picked.

4. Install packages. On the edit page, add a configuration file such as requirements.txt to the list, then click Run pip install. It installs the packages that file describes. Package versions must match the Python version you selected, because a package that needs an older Python will not install into a newer one.

5. Restart and test. Click Restart, then open the app URL.

Environment variables, secrets and logs#

Both tools let you add environment variables on the app’s page. Click Add Variable, enter a name and a value, and save. Put database passwords, API keys and similar secrets here, or in a file inside the application folder, and never under public_html. Each account also lives in its own file system view under CageFS, which stops other customers’ accounts from seeing your files.

Set the Passenger log file when you create the app. Passenger writes messages to a shared log by default, and a per-app file keeps your errors in one place. On the server side this uses the PassengerAppLogFile directive, which can be set in a virtual host or an .htaccess file.

Restart, stop and change versions#

The Web Applications table has icons for start, stop, restart, edit and remove, and the edit page repeats them as buttons. Restart after any change to code, variables or the startup file. Remember that changing the Node.js or Python version of an existing app reinstalls all of its packages, so expect a short delay and rerun your build if you have one. Removing an app does not delete your files, but check your folder before relying on that.

Why a running app can still be slow or stopped#

CloudLinux gives every account limits on CPU speed, memory, processes, entry processes (concurrent connections) and disk input and output. Processes started for your app count against those limits. When the app reaches one, it is slowed down or refused, and this is recorded as a fault. Open cPanel, Metrics, CPU and Concurrent Connection Usage to see the Current Usage table and charts. The Snapshot tab shows the processes, database queries and HTTP requests that were running when you hit a limit. If your app faults often under normal traffic, it needs optimizing or a plan with higher limits.

Troubleshooting the usual failures#

For server administrators#

In WHM, open CloudLinux Manager and go to Options. The Node.js and Python Selector sections let you switch the feature on or off, install and remove interpreter versions, and set the default. A few rules to know: you cannot remove the default version or any version that apps still use, and you cannot start an install or removal while another one is running. If you disable a Selector, existing apps keep their versions, but users cannot add new ones. The cloudlinux-selector command-line utility does the same work for scripting, for both the hoster and the end user.

When the Selector is not enough#

The Selectors suit small and medium apps, APIs and tools that sit beside a PHP site on the same account. They are the wrong tool if you need custom ports, background workers, long-running queues or several services that talk to each other. For those, a VPS or dedicated server with your own process manager and reverse proxy gives you full control. To host a website with a small app beside it, see our cPanel hosting plans.

Related guides: choosing the PHP version and handler in cPanel, deploying Laravel on cPanel shared hosting and hosting several PHP apps on one cPanel account safely. If you move to your own server, see hosting multiple websites on one VPS with Nginx and auditing a new Ubuntu VPS for security.

Apps on the CloudLinux Selector share the account’s resource limits with your PHP sites. If an app or site hits the limit, read how to fix the 508 Resource Limit Is Reached error on cPanel. Before you open an app to the internet, check the account with how to keep your cPanel account and sites secure.

Frequently asked questions#

Do I need SSH access to use the Selectors?#

No. Creating the app, installing packages with Run npm install or Run pip install, setting variables and restarting can all be done from the cPanel interface.

Can I choose different Node.js or Python versions for different apps?#

Yes. Each app has its own version setting, limited to the versions your administrator installed and enabled.

Why does the app work in my local terminal but fail in cPanel?#

Passenger starts the app with its own environment, port handling and working directory. Check that you rely on paths relative to the application root, that the variables are set in the app’s page and that the selected version matches the one you tested.

Can I run Express, Flask or Django this way?#

Yes. Express needs its entry file set as the startup file. Flask and Django need their app object exposed under the entry-point name, application by default.

The short version: enable the Selector, create the app with the right version, root, URL and startup file, install packages from the interface, keep secrets in variables and restart after every change.