Python Hosting

What is Python hosting and which projects is it for?

Python hosting is a service that publishes web applications written in Python on your domain through an application server. Unlike PHP, Python code is not interpreted directly by the web server; a server speaking the WSGI (Web Server Gateway Interface) or ASGI interface sits in between. On hosting that role is played by Phusion Passenger, and on a VPS usually by Gunicorn or Uvicorn.

Python hosting is the right start for:

• Business websites, blogs, booking or membership systems built with Django
• Content management with Wagtail or django CMS
• Small REST APIs, webhook receivers, internal tools and admin panels built with Flask
• Reporting, data transfer and email-sending scripts that run at night

For projects like these, the Python app tool, SSH access and Git deployment in a Linux hosting plan are enough, without setting up a server. If your project has an always-running process, ASGI-based real-time connections or model inference that needs a GPU, follow the criteria in the sections below and move to a VPS, a VDS or a GPU server.

Which Python version should you choose?

For a new project choose a current Python 3 release with at least two more years of support; Python 3.12 and later are the safe choice today. Python releases receive security patches for about five years: support for Python 3.9 ended in October 2025, and Python 3.10 goes out of support in October 2026. Plan to migrate projects still on these versions.

The range your framework supports decides the version:

• Django 6.0 requires Python 3.12 or later.
• Django 5.2 LTS also supports the older Python 3.10 and 3.11; it suits projects that need long-term support.
• Flask and FastAPI work with all current Python 3 releases; the real constraint is the extra libraries you use.

The version list in the panel shows the interpreters installed on the server; because each app gets its own virtual environment, one site can use Python 3.12 and another Python 3.13. Keeping a .python-version file or a requires-python field in pyproject.toml at the project root guarantees your local environment and the server use the same version and prevents “it worked on my machine” problems.

How does a Python app run on Linux hosting?

On Linux hosting a Python app runs in a virtual environment created with the panel’s Python app tool (Setup Python App in cPanel), and Phusion Passenger passes requests to the application object in the passenger_wsgi.py file. With the tool you set the Python version, application root, URL and startup file on one screen.

A typical passenger_wsgi.py for a Django project:

import os, sys
sys.path.insert(0, os.path.dirname(__file__))
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "project.settings")
from project.wsgi import application

For Flask the last line becomes from app import app as application. The panel shows the command to activate the virtual environment at the top of the screen; after running it over SSH you install dependencies with pip install -r requirements.txt.

After changing code you must restart the app from the panel or update the timestamp of tmp/restart.txt in the application root with touch, because Passenger keeps the old process in memory. An app that receives no requests for a long time may be unloaded and reloaded on the next request; that is why the first page load on low-traffic sites can take a few seconds.

Keeping the application root outside public_html is a good habit: your source code, settings.py and virtual environment cannot be downloaded from the web, and only requests routed by Passenger reach the app. LIONFIN Linux hosting plans come with this structure plus SSH, SFTP and Git access, and NVMe storage speeds up loading a virtual environment made of thousands of small files.

Do FastAPI and ASGI apps run on hosting?

ASGI apps such as FastAPI, Starlette and Django Channels run on shared hosting only in a limited way; for full functionality you need a VPS. Passenger’s Python support uses the WSGI interface; you can publish simple HTTP endpoints by converting the ASGI app to WSGI with an adapter such as a2wsgi, but features such as WebSocket, server-sent events (SSE) and BackgroundTasks do not work reliably that way.

The right way to run FastAPI in production is a VPS:

pip install "fastapi[standard]" gunicorn
gunicorn main:app -k uvicorn.workers.UvicornWorker \
  -w 3 -b 127.0.0.1:8000

Define this process as a systemd service, put Nginx in front as a reverse proxy and terminate HTTPS at Nginx. A common starting point for the number of workers is (2 × cores) + 1; asynchronous FastAPI apps achieve high concurrency with fewer workers.

If your project ships as a container image, you can build the same setup with Docker Compose; see Docker hosting.

Keep this distinction in mind: even if your app is written in FastAPI, if it consists only of short endpoints returning JSON, you can start on hosting with an adapter. But if you use asynchronous database drivers, streaming responses or endpoints that relay AI model output piece by piece, these features do not work as expected without an ASGI server, and starting directly on a VPS saves time.

Hosting, VPS or VDS for a Python project?

Hosting is the right choice for a Django or Flask site that responds to requests, a VPS for Python processes that run continuously in the background, and a VDS for CPU- and memory-intensive data processing. The deciding question is whether any part of your app runs outside the request–response cycle.

If your bot or automation project needs a Windows desktop, see bot server hosting. If you want to run AI models on a GPU, the LLM server hosting page explains VRAM requirements in detail. For dedicated resources, see our VDS servers.

A practical roadmap: launch the project on Linux hosting, then move it to a VPS without changing code once user numbers and background job needs become clear. Django and Flask apps follow the WSGI standard, so the same code runs under Passenger or Gunicorn; only process management and web server configuration change during the move. That way you leave room to grow without paying for extra resources from day one.

Which settings must change when taking Django to production?

When taking Django to production at least five settings must change: DEBUG turned off, ALLOWED_HOSTS filled in, SECRET_KEY read from an environment variable, static files gathered with collectstatic and HTTPS enforced. Django offers a command that checks this for you.

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

Key settings:

• DEBUG = False: if left on, the error page shows visitors your settings and environment details.
• ALLOWED_HOSTS = ["yourdomain.com", "www.yourdomain.com"]: if missing you get a “DisallowedHost” error.
• CSRF_TRUSTED_ORIGINS: for form submissions over HTTPS, add your domain as a full address including the https scheme.
• STATIC_ROOT: if it points to a folder under public_html, static files are served by the web server without running Python at all.
• SECURE_SSL_REDIRECT and SESSION_COOKIE_SECURE: make HTTPS mandatory.

Media files (MEDIA_ROOT) are user uploads and must be included in your backup plan. The same logic applies to Flask: debug mode off, the secret key in an environment variable and session cookies sent only over HTTPS.

How do you use MySQL or PostgreSQL in a Python app?

On Linux hosting your Python app uses the MySQL or MariaDB database in the same account; if you need PostgreSQL, you install it yourself on a VPS. Django officially supports MySQL/MariaDB, PostgreSQL, SQLite and Oracle.

Be careful when choosing a MySQL driver:

• mysqlclient: the driver Django recommends and fast, but installing it needs a C compiler and MySQL development headers. If you hit a build error on shared hosting, switch to the second option.
• PyMySQL: written entirely in Python, needs no compilation. Register it with Django by adding import pymysql; pymysql.install_as_MySQLdb() at the top of settings.py.

Adding "charset": "utf8mb4" under OPTIONS in the connection settings ensures non-Latin characters and emoji are stored correctly. SQLite is suitable only for single-user tools and tests; concurrent writes cause locking.

If you use PostgreSQL-specific features (JSONB queries, full-text search, PostGIS), set the project up on a VPS from the start. As database load grows, moving it to a separate server with dedicated resources is the next step.

How do you install Python dependencies on the server?

Python dependencies should be installed with pip into a virtual environment specific to each app, from a requirements.txt file with pinned versions. Typing pip install django without a version can bring a different major version on the next install and break the app unexpectedly.

1. Export the full list of your working local environment: pip freeze > requirements.txt, or generate a lock file with pip-tools or uv.
2. Over SSH, activate the virtual environment with the command the panel shows.
3. Update pip with pip install --upgrade pip; old pip versions may not find prebuilt packages (wheels).
4. Run pip install -r requirements.txt.
5. Restart the app after installation.

Packages that need compiling (for example mysqlclient and some cryptography and image-processing libraries) may fail to install on shared hosting for versions without a prebuilt wheel. In that case choose a version that publishes wheels or use a pure-Python alternative. Scientific libraries such as PyTorch and TensorFlow take up gigabytes and quickly fill the hosting quota; a VPS or GPU server suits such projects better.

How do you run scheduled tasks in a Python app?

On hosting, scheduled Python tasks run through a cron job that calls the Python interpreter in the virtual environment by its full path. Cron does not activate the virtual environment by itself; a task running with the system Python cannot find the packages you installed and fails with “ModuleNotFoundError”.

An example cron line for a Django management command:

*/15 * * * * cd /home/user/project && /home/user/virtualenv/project/3.12/bin/python manage.py send_report >> /home/user/logs/cron.log 2>&1

Folder names in the path depend on the virtual environment your panel created; you can find the correct path by activating the environment and running which python. Redirecting output to a log file lets you notice tasks that fail silently.

Cron tasks should be short and must not overlap. Jobs such as data transfers or bulk emails that take minutes can hit hosting resource limits; for those loads, running Celery Beat-scheduled workers on a VPS is healthier. To protect sending reputation for bulk email, you can configure your app to send through our SMTP relay.

How do you speed up and protect a Python application?

In Python apps, most speed comes down to the number of database queries and use of caching; security rests on protecting secrets, keeping dependencies up to date and HTTPS.

For performance:

• Fix N+1 queries: in Django, use select_related and prefetch_related to avoid hundreds of queries on one page; see query counts with django-debug-toolbar.
• Caching: use a file-based cache on hosting and a Redis cache on a VPS; put unchanging page fragments in the template cache.
• Static files: serve CSS, JavaScript and images from the web server or a CDN, not from Python.
• Defer heavy work: jobs such as sending email and generating PDFs should not hold up the request.

For security:

• Keep SECRET_KEY, the database password and API keys in environment variables, not in the repository.
• Scan regularly for known vulnerabilities with pip-audit and apply framework security releases promptly.
• Enable the free SSL certificate in the panel, change the admin URL (/admin) and use a strong password and two-factor authentication.

For backups, keep the database dump together with the MEDIA_ROOT folder; the code is already in Git.

What should you watch for when moving a Python project from another server?

When moving a Python project, handle code, virtual environment and data separately: code comes over with Git, dependencies are reinstalled from requirements.txt, and the database and media files are transferred as a dump and an archive. Do not copy the virtual environment folder (venv) as is; the paths and compiled files inside are specific to the old server and will not work in the new environment.

1. On the old server, capture pip freeze output and note the Python version.
2. Export the database with mysqldump --single-transaction, or with dumpdata for Django; for large databases a direct SQL dump is faster and more reliable.
3. Archive the MEDIA_ROOT folder with tar and transfer it to the new account via SFTP or rsync.
4. On the new hosting, create the app with the same Python major version, install dependencies and import the database.
5. Test the app on a temporary subdomain; once everything works, point the DNS records to the new server.

Lowering the TTL of your DNS records a few hours before the switch shortens the period during which visitors are split between the old and new server.

What are the most common Python hosting errors?

Most Python hosting errors come from the wrong virtual environment, missing packages, a faulty passenger_wsgi.py or Django settings. Error details are in the error log in the application root or the panel, not in the browser; look there first.

• “ModuleNotFoundError”: the package was installed into the system Python, not the app’s virtual environment. Activate the virtual environment and repeat pip install.
• “DisallowedHost”: your domain is not in the ALLOWED_HOSTS list.
• CSS and images do not load: collectstatic has not been run, or STATIC_ROOT does not point to a web-accessible folder.
• “mysqlclient” will not install: build headers are missing; switch to PyMySQL.
• CSRF verification failure: CSRF_TRUSTED_ORIGINS was not updated after switching to HTTPS.
• Changes do not show: restart the app from the panel or touch the tmp/restart.txt file.
• 500 error with an empty log: the import path in passenger_wsgi.py is wrong; test it over SSH from the virtual environment with python -c "import project.wsgi".

If the problem persists, include the Python version, application root and the last lines of the error log when you open a support ticket from the customer panel; it speeds up the fix.