Python Hosting

No. Django, Flask, and FastAPI need to run as persistent server processes - Gunicorn or Uvicorn - that stay alive between requests and listen on a port. Shared hosting is built around PHP's request-and-exit model; it does not support persistent Python application servers or arbitrary port binding. Some shared hosts offer a Python selector through cPanel, which allows CGI or limited WSGI module configurations, but this is not a proper application server environment and is not suitable for production Django, Flask, or FastAPI deployments. A VPS is the correct environment.

For Python version management, the two common approaches on Ubuntu are: install specific versions via the deadsnakes PPA (sudo add-apt-repository ppa:deadsnakes/python3.12, then sudo apt install python3.12), or use pyenv, which installs any Python version from source into your home directory. Once you have your Python version, create a virtual environment with python3.12 -m venv venv and activate it. Install all project dependencies - including Gunicorn or Uvicorn - inside the virtual environment. Each application on your server gets its own virtual environment, isolating its packages and Python version from everything else.

In development, Django serves its own static files. In production, it does not - and should not. Run python manage.py collectstatic to gather all static files into the directory specified by STATIC_ROOT in your settings. Then configure Nginx to serve that directory directly at your STATIC_URL path. Static file requests never reach Gunicorn - Nginx handles them before the proxy pass. The same pattern applies to user-uploaded media files via MEDIA_ROOT and MEDIA_URL. This is covered in Django's official deployment documentation.

Celery requires a message broker - Redis is the most common choice for Django applications. Install Redis on your VPS (sudo apt install redis-server), install Celery and the Redis driver in your virtual environment (pip install celery redis), configure the CELERY_BROKER_URL in your Django settings, and create a systemd service for your Celery worker process. Multiple Celery workers run in parallel as separate processes - size the number of workers based on your task volume and available RAM. For monitoring Celery workers, Celery Flower provides a web interface. If you're using Celery Beat for scheduled tasks, run it as a separate systemd service.

It depends on your framework. Gunicorn is the right choice for Django (without async views) and Flask - both are synchronous WSGI applications and Gunicorn's pre-fork worker model handles them well. Uvicorn is the right choice for FastAPI, Starlette, and Django applications using async views - these are ASGI applications and need an async-capable server. For production FastAPI deployments, the common approach is running Uvicorn workers managed by Gunicorn (gunicorn -k uvicorn.workers.UvicornWorker), which gives you Gunicorn's process management with Uvicorn's async handling. Django's ASGI deployment documentation covers the equivalent setup for async Django.

Yes. PostgreSQL installs cleanly on Ubuntu and Debian via apt. Django's ORM supports PostgreSQL natively - install psycopg2-binary (or psycopg for the newer driver) in your virtual environment and configure DATABASES in your settings to point to your local PostgreSQL instance. PostgreSQL is the recommended production database for Django; it supports Django's full feature set including ArrayField, JSONField, and full-text search. MySQL is also supported by Django and installs equally cleanly. For low-traffic applications, SQLite is available but not recommended for multi-process production deployments - Gunicorn's multiple workers would compete for the same SQLite file.

Start with your Gunicorn worker count and then add the memory footprint of any additional services. Gunicorn's recommended formula is 2 x vCPU + 1 workers. VPS-1 (3 workers) suits simple APIs or low-traffic Django sites where you're not running PostgreSQL and Redis on the same server. VPS-2 (5 workers) handles most production Django or FastAPI applications with Redis and a moderate Celery setup - it's the recommended starting point. VPS-4 (9 workers) suits higher-traffic applications or deployments running Django, PostgreSQL, Redis, and Celery workers together with comfortable headroom. VPS-6 (13 workers) suits large-scale deployments, resource-intensive workloads, or servers running multiple Python applications. When in doubt, start on VPS-2 - you can upgrade without migrating your data.