Guide
How to host a Python web app
Django and Flask need a process that stays running. Shared PHP hosting has none. What to do instead, and when static output is enough.
- Python web apps that need a running server (Flask, Django, FastAPI) cannot work on free shared hosting.
- You need a small VPS to run a persistent Python process with Gunicorn behind Nginx.
- Static sites built with Python tools like Pelican or MkDocs work fine on free shared hosting.
- The only Python projects that belong on shared hosting are ones that produce HTML files, not ones that serve requests.
You cannot host a Python web app on standard shared hosting, including the free CWP offering. Shared hosting expects PHP. Python applications use WSGI or ASGI, which need a process that stays running and responds to requests continuously. That is not something a shared server provides.
If you have a Flask or Django app and this is your first deployment, the honest answer is a small VPS. The rest of this page explains why, and then covers the one situation where Python projects do work on shared hosting.
What WSGI and ASGI actually mean
Your Python app is not a web server. When you run flask run or gunicorn app:app, you start a long-lived process that speaks the WSGI protocol (or ASGI for async frameworks like FastAPI). The web server (Nginx, Apache) proxies requests to that process.
Shared hosting does not let you start or supervise a long-running process. The server runs PHP workers that get spawned per request and die when the request ends. That model breaks for Python.
The result of trying to run Python on shared hosting is usually a 500 Internal Server Error. That is what a crashed Python process looks like from the outside.
The real answer: a small VPS
The standard solution for a Python web app is a VPS with 512 MB to 1 GB of RAM. You install Python, your framework, a production WSGI server (Gunicorn, uWSGI), and Nginx as a reverse proxy. You set up a systemd service to keep the app running and restart it if it crashes.
A VPS gives you:
- root access to install any Python version
- systemd or supervisord to keep the process alive
- a firewall and SSH access
- your own disk space and memory
For a first deployment, this is a one-afternoon task. Many VPS providers have one-click Django or Flask images.
If you are unsure about sizing, the hosting calculator can give you a rough idea of what your app needs, but the short version for Python is: 1 CPU core and 1 GB RAM is enough for a low-traffic app with a database.
When shared hosting works for Python
Some Python projects never run as a web process. They generate a folder of HTML, CSS and JavaScript files, and then stop. Those files are a static website and can be hosted anywhere, including free shared hosting.
Examples:
- Pelican, Lektor, or Nikola — static site generators that build HTML from Markdown or reStructuredText
- MkDocs — documentation from Markdown files
- Jupyter Book — a book or course site built from notebooks
- Jupyter notebooks exported to HTML — just the output, not the live kernel
- Dash apps (Plotly) compiled to static output — only if you use the serverless export feature
If your project falls into one of these categories, you can copy the output folder to the public HTML directory of your free CWP account. That is exactly the same as hosting a static website, and it works without any special configuration.
For anything that needs a running Python process, this does not apply.
Why shared hosting is built around PHP
Shared hosting companies choose PHP for a reason. PHP processes start, handle a request, and die. They do not stay in memory waiting for the next request. That keeps the server simple and lets one machine handle many accounts.
Python, Node, Ruby and Go all expect the opposite: a persistent process that holds memory and connection state. You can see more detail in the article on what web hosting is, which explains the PHP model in plain terms.
There is no trick to make a persistent Python process work inside a shared environment. The server will kill any long-running Python process because it looks like a runaway job.
The Python app hosting path
If your app is a Flask or Django project that needs to run live, get a VPS. Copy your project there, set up Gunicorn behind Nginx, and point your domain at it. That is the normal way to run Python in production.
If your project outputs flat HTML files, put those on free shared hosting. Upload them through FTP or the web file manager, and you are done. The guide on hosting a static site covers the exact steps.