How to Host a Python App with Flask or Django

Ultra Web Hosting runs Python web apps on shared hosting through Phusion Passenger, wired up by cPanel's Setup Python App tool. You pick a Python version, cPanel builds you a virtual environment, and Passenger serves your Flask or Django app the same way it serves everyone else's, no long-running process for you to babysit. This guide walks through creating the app, installing your packages, wiring the passenger_wsgi.py entry point, and getting both Flask and Django online, plus the restart, logging, and shared-hosting limits that catch people out.

01. How Python Apps Run on Shared Hosting

If you have deployed Python before, you are used to running your app under a WSGI server such as Gunicorn or uWSGI and keeping it alive with something like systemd or supervisor. On shared hosting you do not do any of that. Ultra Web Hosting uses Phusion Passenger, an application server built into our web stack, and cPanel's Setup Python App (also called Application Manager) is the front end that configures it for you.

The model is worth understanding before you touch anything:

Because Passenger loads your app on demand, there is no persistent process you control and no place to run a long-lived background worker. That constraint matters later, and Section 10 covers where the shared-hosting model runs out of room. For a Node equivalent of this same Passenger workflow, see article #487.

02. Create the App in cPanel

Everything starts in cPanel. This step creates the virtualenv and registers the app with Passenger.

1. Log in to cPanel and open Setup Python App (under the Software section). Some themes label it Application Manager.
2. Click Create Application.
3. Python version: pick the version your project targets. Newer is usually better, but match what your code and dependencies expect (for example 3.11).
4. Application root: the folder your app lives in, relative to your home directory, for example myapp. cPanel creates this folder and puts the virtualenv alongside it.
5. Application URL: the domain or subdomain path where the app is served, for example yourdomain.com or yourdomain.com/app.
6. Application startup file and Entry point: leave these at the defaults for now (passenger_wsgi.py and application). You will create that file shortly.
7. Click Create.

cPanel now builds a Python virtual environment for you and shows a command near the top of the app's page that looks like source /home/youruser/virtualenv/myapp/3.11/bin/activate && cd /home/youruser/myapp. Copy that line. You need it in the next section. For where these paths sit on the server and how Python is laid out, see article #127.

03. Activate the Virtualenv and Install Packages

You install your dependencies from the command line, inside the virtualenv cPanel built. This needs SSH access. If you have not enabled SSH yet, see article #60 for how to turn it on and connect.

1. Connect to your account over SSH.
2. Paste the activation command cPanel gave you on the app page. It both activates the virtualenv and changes into the app root:

   source /home/youruser/virtualenv/myapp/3.11/bin/activate && cd /home/youruser/myapp

3. Your shell prompt now shows the environment name in parentheses. Confirm you are using the right interpreter:

   which python
   python --version

4. Install your packages with pip. For a single package:

   pip install flask

5. For a real project, keep dependencies in a requirements.txt in the app root and install them all at once:

   pip install -r requirements.txt

A minimal requirements.txt for a Flask app looks like this:

Flask==3.0.3
gunicorn==22.0.0

04. The passenger_wsgi.py Entry Point

Passenger looks for a file named passenger_wsgi.py in your app root, and inside it, a WSGI callable named application. That callable is the single contract between your code and the server. Whatever framework you use, the job of passenger_wsgi.py is to produce an object called application.

For a Flask app whose Flask instance is named app in a file called app.py, the entire passenger_wsgi.py is one line:

from app import app as application

That imports your Flask object and re-exposes it under the name Passenger expects. There is nothing else to do. No port, no host, no app.run() for production.

05. A Minimal Flask App

Here is a complete, working Flask app. Two files in your app root: app.py holds the application, and passenger_wsgi.py hands it to Passenger.

app.py

from flask import Flask

app = Flask(__name__)

@app.route("/")
def home():
    return "Hello from Flask on Ultra Web Hosting"

@app.route("/health")
def health():
    return {"status": "ok"}

if __name__ == "__main__":
    # Only used for local development, never in production on Passenger.
    app.run(debug=True)

passenger_wsgi.py

from app import app as application

1. Put both files in your app root (for example /home/youruser/myapp).
2. Make sure Flask is installed in the virtualenv (Section 03).
3. Restart the app (Section 08) so Passenger loads the new code.
4. Visit your Application URL. You should see the greeting, and /health should return JSON.

The if __name__ == "__main__" block only runs when you execute python app.py yourself for local testing. Passenger imports the module and calls application directly, so that block is skipped in production.

06. A Django App End to End

Django ships with its own WSGI entry point, so wiring it into Passenger is a matter of pointing passenger_wsgi.py at it and doing the usual Django housekeeping. Assume your project is named myproject and lives in the app root.

Point passenger_wsgi.py at Django's WSGI app

import os
import sys

sys.path.insert(0, os.path.dirname(__file__))
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myproject.settings")

from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()

Set ALLOWED_HOSTS and turn off debug

In myproject/settings.py, list the domain the app is served from and disable debug mode for production:

DEBUG = False

ALLOWED_HOSTS = ["yourdomain.com", "www.yourdomain.com"]

Run migrations and collect static files

Over SSH, with the virtualenv active and inside the app root:

python manage.py migrate
python manage.py collectstatic --noinput

In production Django does not serve static or media files itself. Point STATIC_ROOT at a folder the web server can reach and let Apache serve it. A common layout:

import os

BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))

STATIC_URL = "/static/"
STATIC_ROOT = os.path.join(BASE_DIR, "public", "static")

MEDIA_URL = "/media/"
MEDIA_ROOT = os.path.join(BASE_DIR, "public", "media")

The public folder in the app root is the one Passenger treats as your document root, so anything under it is served as a plain static file. Run collectstatic again any time you change static assets, then restart the app.

07. Environment Variables and Secrets

Do not hard-code database passwords, API keys, or Django's SECRET_KEY into files you commit to a repository. cPanel's Setup Python App page has an environment variables section for exactly this: add a name and value there, save, and Passenger injects it into your app's environment.

1. Open your app in Setup Python App.
2. In the Environment variables area, click Add Variable.
3. Enter a Name (for example SECRET_KEY or DATABASE_URL) and its Value.
4. Save, then restart the app so the new value is loaded.

Read them in code the normal way:

import os

SECRET_KEY = os.environ["SECRET_KEY"]
DATABASE_URL = os.environ.get("DATABASE_URL", "sqlite:///db.sqlite3")

08. Restarting After Code Changes

Passenger loads your app into memory once and reuses it across requests. Editing a Python file, changing settings, or adding an environment variable has no effect until you tell Passenger to reload. There are two ways to do it.

Touch the restart file

Passenger watches for a file at tmp/restart.txt in your app root. Updating its timestamp triggers a graceful reload on the next request:

mkdir -p tmp
touch tmp/restart.txt

Click Restart in cPanel

On the Setup Python App page, each application has a Restart button. Click it and Passenger reloads the app. This is the same effect as touching the restart file, just from the browser.

09. Logs and Troubleshooting

When something breaks, Passenger writes the Python traceback to the app's stderr log. That log is where you find the real cause behind a generic error page. Its location is shown on the Setup Python App page for your app, and it is usually under the app root or in your home directory as stderr.log. Watch it live over SSH while you reproduce the error:

tail -f /home/youruser/myapp/stderr.log

Common problems and what they mean:

• 500 Internal Server Error with a generic page. Your app raised an exception on startup or during the request. Read the traceback in the stderr log; it names the file and line.
• ModuleNotFoundError or ImportError. The package is not installed in the virtualenv, or you installed it into a different environment. Re-activate the correct virtualenv (Section 03) and pip install it, then restart.
• Wrong Python version. If a dependency refuses to install or behaves oddly, confirm python --version inside the activated virtualenv matches what you selected in cPanel. Changing the version in cPanel rebuilds the environment, so reinstall your packages after.
• Static files return 404 (Django). You have not run collectstatic, or STATIC_ROOT does not point inside the public folder Passenger serves. Fix the path, run collectstatic --noinput, and restart.
• Changes not taking effect. You did not restart. See Section 08.

10. Shared Hosting Limits and When to Move to a VPS

Passenger on shared hosting is a great fit for websites, dashboards, APIs, and internal tools with normal request-and-response traffic. There are things the shared model is not built for, and pushing against them leads to frustration rather than a fix.

Consider a VPS or dedicated server when your app needs any of the following:

• Long-running background workers. Celery workers, queue consumers, or any daemon that must stay alive independent of web requests. Passenger only runs your app while it is serving traffic, so there is nowhere to keep a persistent worker.
• WebSockets or long-lived connections. Real-time features that hold a socket open per client do not sit well behind the shared Apache and Passenger setup.
• High or spiky memory use. Shared plans cap per-account memory and processes. A model-loading data app or a large in-memory cache will hit those ceilings.
• System-level access. Some Python packages shell out to system binaries. On shared hosting, functions like system() and exec() are restricted for security, which affects certain libraries. Article #235 covers those shared-hosting execution limits; they apply to Python subprocess calls too.

None of this means you have to leave. Plenty of production Flask and Django sites run happily on our shared plans. But if your roadmap includes real-time features, heavy background processing, or full root control, a VPS gives you your own Gunicorn, systemd, and the run of the box. We can help you size and migrate when you get there.

Quick Recap: Python on Passenger in Six Steps

If you only remember six things from this guide, remember these:

1. Create the app in cPanel with Setup Python App: choose the Python version, app root, and URL, and let it build the virtualenv.
2. Activate the virtualenv over SSH using the command cPanel gives you, then pip install -r requirements.txt.
3. Expose a callable named application in passenger_wsgi.py (one line for Flask, Django's get_wsgi_application() for Django).
4. For Django, set ALLOWED_HOSTS, DEBUG = False, run migrate and collectstatic, and point static and media into the public folder.
5. Put secrets in the cPanel app config as environment variables, never in the repository.
6. Restart after every change with touch tmp/restart.txt or the Restart button, and read errors from the stderr log.

Last updated July 2026 · Browse all Getting Started articles