Skip to main content
Updated: August 9, 2026
Matic Bončina
By Matic BončinaFounder
✓Proofread & verified
A Virtual Container is a Node.js, Python, or Ruby app running inside your own cPanel account. CloudLinux keeps it within your account’s LVE limits and its own CageFS view of the filesystem. Phusion Passenger starts the process and hands it each request. Node and Python share one interface in cPanel. Ruby has its own, older one.

​
Pick your runtime

Node.js

Choose the version per app. Application mode sets NODE_ENV, and a startup file names your entry script.

Python

Same form, one extra field: Application Entry point tells Passenger which WSGI callable to import.

Ruby

A separate, older Setup Ruby App page. Ruby version, app directory, and domain, then Setup.

​
How the container is built

Two CloudLinux pieces do the isolation. LVE caps CPU, memory, I/O, entry processes, and process count for your cPanel user. CageFS gives every user their own view of /usr, /etc, and /proc, so the other accounts on the server are invisible to you. None of this is a separate VM or a Docker image. Your app is a process tree inside the account you already have, started and supervised by Passenger, which forwards each request to it.
Passenger owns the port. In Node, Passenger hooks the first http.Server that calls listen() and moves it onto a Unix socket, so the port number you pass is ignored. Leaving app.listen(3000) in your code is fine and is what most Node apps already do.Python works differently. Passenger imports the WSGI callable named in Application Entry point rather than running your file as a server, so a Flask or Django app is wired up through that callable.

​
What the setup form gives you

  • A runtime version per application. You choose it on the app itself, not once for the whole server. All three tools work this way.
  • Application root, the directory on the server holding your code. All three require it.
  • Application URL, a domain from your account plus an optional path.
  • Environment variables, added one at a time, for config and secrets.
  • Node only: Application mode. cPanel describes it as “Adds value for NODE_ENV variable” and it starts on Development.
  • Python only: Application startup file and Application Entry point, the file and the WSGI callable inside it.
You can enter the same sandbox from SSH. For Node, CloudLinux documents it as source <home>/nodevenv/<app root>/<version>/bin/activate, after which node and npm resolve to that version. Passenger restarts an app when the timestamp on tmp/restart.txt inside the application root changes. It notices on the next request rather than instantly.

​
Limits to plan around

These come from the plan your hosting sits on, not from the container. Entry processes cap how many requests you can serve at once, so a busy app usually hits that before it runs out of memory. Worker-heavy stacks such as Sidekiq or Celery push against the process count instead. One limit belongs to Passenger rather than your plan: it gives an app 90 seconds to start, then kills the process and logs an error. A cold Django or Rails boot with slow initialization can run into that.

​
Common deployment recipes

Step-by-step guides in the Knowledge Base:

Deploy Next.js

Server-rendered Next.js on the Node.js Selector.

Deploy Express

REST API on Express with Passenger.

Deploy Django

Django app, virtualenv, static files.

Deploy Flask

Lean Flask service via passenger_wsgi.py.

Deploy Rails

Rails app, Bundler, asset precompilation.

​
Need a hand?

Open a ticket

Best for anything that needs an account check or a config change on our end.

Live chat

Faster for quick questions during business hours.