How a Python web app runs here
Each app gets its own virtual environment on the Python version you pick — 3.10, 3.11, 3.12, 3.13 or 3.14 — with your requirements.txt installed into it. The app runs under gunicorn on the port the platform gives it, behind nginx and free SSL, inside your account's memory ceiling.
Django
The Django preset installs your requirements and gunicorn, runs collectstatic and migrate as the build step, and starts gunicorn with your project's WSGI application. Set ALLOWED_HOSTS, SECRET_KEY and the database settings as environment variables, and DEBUG to False in production.
Static files collected into a folder the web server serves directly are fastest; media uploads go in a folder that persists between releases.
Flask and FastAPI
Flask runs under gunicorn like any WSGI app. FastAPI and Starlette are ASGI apps, and the FastAPI preset runs them with gunicorn managing uvicorn workers, so async endpoints work as intended. Point the start command at your module and application object, for example main:app.
- Django: gunicorn + WSGI, collectstatic and migrate on deploy
- Flask: gunicorn + WSGI
- FastAPI / Starlette: gunicorn with uvicorn workers (ASGI)
Databases and settings
Plans include MariaDB/MySQL and PostgreSQL. Put connection details in environment variables — edited as key/value pairs in the dashboard — and read them with os.environ or django-environ. External databases connect by connection string.
Deploy from Git
Each push to your branch builds a fresh release with its own virtual environment, runs your build command (collectstatic, migrate), switches the app over and checks it answers. A failed release rolls back automatically, and earlier releases stay available to make live again.
Background work and limits
Scheduled tasks — management commands, cleanup scripts — run as cron jobs. Celery with an always-on worker and a broker, or anything that must run continuously beside the web app, belongs on a cloud server from ₹1,073 a month. GPU work such as model inference runs on GPUs by the hour from ₹36.
Moving an existing Python app
Apps from cPanel-style hosts usually come with a passenger_wsgi.py file; it works as the WSGI entry point here too. Packages installed by hand into the old virtualenv but missing from requirements.txt are the most common surprise — freeze the old environment and add them before you move. Our engineers help move existing apps.
Preparing a Django project
Before deploying, split settings so production reads secrets from the environment: SECRET_KEY, DEBUG, ALLOWED_HOSTS, CSRF_TRUSTED_ORIGINS and the database settings. Set STATIC_ROOT and run collectstatic in the build, and keep MEDIA_ROOT in a folder that persists between releases. Pin dependencies in requirements.txt — including gunicorn and the database driver — so every release installs the same versions.
If you use WhiteNoise or a similar package, make sure it is in requirements.txt; a package installed by hand on an old server and missing from the file is the most common cause of a failed first deploy.
Preparing a FastAPI app
Expose the application object in a module — main:app is the usual — and let the platform start it under gunicorn with uvicorn workers. Read configuration with pydantic settings or os.environ. Keep startup work light; heavy model loading at import time slows every restart and can make the health check fail. For anything long-running, return quickly and hand the work to a background task or a worker on a cloud server.
Performance and memory
Python apps share the plan's memory between gunicorn workers, so more workers is not always faster. Two or three workers suit most small plans; raise the number only if memory allows. Cache expensive queries, add database indexes for common filters, and serve static files directly rather than through the app.
Watch the logs after each release: tracebacks appear there immediately, with the line that failed.
A first deployment, step by step
Create the Python app from Launch an app and choose the version. In App settings pick the Django, Flask or FastAPI preset and add your environment variables. Connect the repository under Git deployments and deploy. The build installs requirements into a fresh virtual environment, runs collectstatic and migrate, and switches over once the app answers; a failure leaves the previous release running.
Databases for Python apps
Django and FastAPI work with MySQL or MariaDB and PostgreSQL created from the dashboard, through the usual drivers: mysqlclient or PyMySQL for MySQL, psycopg for PostgreSQL. Put the database settings in environment variables and run migrations as part of the deploy so the schema always matches the code. An external database such as MongoDB Atlas can be added by connection string and attached to the app as an environment variable.
Keep the connection count modest: each gunicorn worker opens its own connections, and a small plan does not need many.
Choosing a Python version
Several Python versions are installed side by side, and each app picks its own. Use a recent version for new projects and match it in your local development environment, so a package that installs on your laptop also installs on the server. Because every release gets a fresh virtual environment built from requirements.txt, upgrading Python is a matter of changing the version in App settings and deploying; the previous release stays available if you need to go back.
Scheduled tasks and background work
Django management commands and Python scripts can run from the Cron jobs page on any schedule, using the app's own virtual environment. That covers most periodic work: sending digest emails, cleaning old records, importing a daily feed. Workers that must run all the time, such as Celery with a busy queue, belong on a cloud server, where they will not share the plan's memory with web requests.
Data and machine learning workloads
Serving a small model or a data dashboard from a Python app on managed hosting works well when the model fits comfortably in the plan's memory. Training models, processing large datasets or serving big models needs GPUs or a large cloud server. Keep the web front end on hosting and move the heavy work to the right machine, so neither one has to be sized for the other.
Key takeaways
The short version, for anyone skimming:
- Each app gets its own virtualenv on Python 3.10 to 3.14.
- Django and Flask run under gunicorn; FastAPI under gunicorn with uvicorn workers.
- Settings and secrets live in environment variables, not settings.py.
- Git deploys run collectstatic and migrate per release, with rollback.
- Python plans start at ₹2,388 a year; Celery workers go on a cloud server.
Python Hosting from ₹2,388/year
Django, Flask and FastAPI on the Python version you choose, with their own isolated environment and a set RAM allowance. Python 3.10 to 3.14 · From 384 MB app RAM · Your code from Git or a ZIP.
Hosting from ₹99 a month on servers in India
WordPress, PHP, Node.js, Python and Java plans with free SSL and your choice of version. Create your account, pick a plan and pay by UPI, card or netbanking; your hosting is created automatically and you get your login by email, usually within minutes.