.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
Running a Python web app on cPanel is entirely doable and weirdly under-documented, mostly because there are two different official mechanisms and your server has either one, the other or neither. This guide sorts out which one you're looking at, then walks a Flask app from empty folder to live URL. Django users: everything applies, only the entry point differs, and I'll flag it where it does.
Which Python setup your cPanel server has
Open cPanel and look in the Software section. A tool called Setup Python App means the server runs CloudLinux and you've got the Python Selector, the friendlier of the two paths. A tool called Application Manager is cPanel's own Passenger-based route, available on standard servers when the admin enables it. Neither tool visible? The feature's off; on shared hosting that's a support ticket ("can you enable Python application support?"), on your own VPS it's ten minutes in WHM, covered at the end.
Both routes end the same way: your app runs persistently behind Apache through Phusion Passenger, speaking WSGI. No manual gunicorn, no systemd services, no ports to expose. That's the trade of cPanel Python hosting in general: you give up some control and get a deployment a form can manage.
Route 1: Setup Python App (CloudLinux servers)
Create the application
Open Setup Python App, click Create Application and fill the form:
- Python version: pick the newest offered, 3.11 or later ideally. Old apps pinned to 3.8? Time to test them on something current anyway.
- Application root: the folder for your code, like
myapp(it lands in your home directory, outside public_html, which is where app code belongs). - Application URL: the domain or subpath the app answers on.
- Application startup file:
passenger_wsgi.py. - Application Entry point:
application.
Click Create. The tool builds a virtualenv for the chosen Python version and drops a placeholder passenger_wsgi.py that renders a test page. Load your URL now; seeing the placeholder text confirms the plumbing works before your own code enters the picture. Debugging in that order (platform first, app second) saves real time.
Add your Flask app
Upload your code into the application root, say an app.py like:
from flask import Flask
app = Flask(__name__)
@app.route("/")
def index():
return "Live from cPanel."Replace passenger_wsgi.py's contents with the two lines that hand Passenger your app object:
from app import app as applicationPassenger looks for a WSGI callable named application, hence the rename-on-import. Django's equivalent: point the startup file at your project's wsgi.py, or import application from it the same way.
Install dependencies
Back on the app's card in Setup Python App there's a field to add requirements.txt and a button to run pip install against it. Command-line people: the card shows a source command like
source /home/USERNAME/virtualenv/myapp/3.11/bin/activate && cd /home/USERNAME/myappPaste it into cPanel's Terminal and you're inside the app's virtualenv where pip install -r requirements.txt behaves normally. That activate line is the detail worth memorizing; every "module not found on cPanel" question I've ever answered came down to installing packages outside the app's virtualenv.
Restart and it's live
Click Restart on the application card after every code change (or touch tmp/restart.txt in the app root, which Passenger watches). Load the URL: your app answers on the domain with AutoSSL handling HTTPS like any other cPanel site.
Route 2: Application Manager (standard cPanel)
cPanel's own Application Manager does the same Passenger registration with fewer amenities: no virtualenv builder, no pip UI, no version selector. You create the environment yourself, which is a couple of terminal commands:
cd ~/myapp
python3 -m venv venv
source venv/bin/activate
pip install flaskWrite the same app.py and passenger_wsgi.py as above. Then in cPanel » Software » Application Manager, register the application: name it, pick the domain and base path, point Deployment Directory at myapp and add an environment variable if your app expects any. Click Deploy and Passenger picks it up. The manager also has an Enabled/Disabled toggle per app, useful for maintenance without unregistering anything.
Honest comparison: Application Manager works and I've shipped things with it, but the Python Selector's virtualenv-per-app-version handling is worth having when you run several apps. If you're choosing a host for Python specifically, ask which of the two you're getting.
On your own VPS: Enabling all of this
Root on a plain cPanel VPS unlocks the Application Manager path in two moves (starting from a bare server instead? Installing cPanel on a VPS comes first and takes about an hour). WHM » EasyApache 4, edit the current profile and install the Passenger package (it appears as ea-ruby27-mod_passenger; yes, the Ruby module carries Passenger for Python too). Then WHM » Feature Manager, enable Application Manager in the feature list your accounts use. From there each cPanel account gets the Software » Application Manager tool from route 2. The Python Selector specifically requires a CloudLinux license on top, which is the main reason you'd add CloudLinux to a cPanel VPS beyond its resource-isolation features.
Worth saying out loud: with root you're also free to ignore cPanel's mechanisms and run gunicorn behind a reverse proxy like on any Linux box. That's a different article's territory (our application hosting pages cover the framework-native routes), but know the ceiling isn't cPanel's tooling when you own the server.
Troubleshooting the classics
503 or "Web application could not be started". Passenger failed importing your code. The passenger error log (or stderr.log in the app directory on CloudLinux setups) shows the actual Python traceback, and it's usually an ImportError: dependency missing from the virtualenv, or the entry point name not matching application.
Changes don't appear. You didn't restart. Passenger caches the loaded app; Restart button or touch tmp/restart.txt after every deploy.
Static files 404. Passenger serves your app, not your assets. Point Apache at them by keeping static files under a public folder mapped into the docroot, or let WhiteNoise (Django) or Flask's static handling do it app-side. App-side is slower but zero-config; I start there and optimize only when traffic justifies it.
It works on the URL but dies after idle time. Passenger spins down idle processes and cold-starts them on the next request. Normal on shared setups. Persistent workers and background jobs are the sign you've outgrown WSGI-under-Passenger and want a VPS process you control.
