Best way to host a Python app

Python runs almost anything: a Discord bot, a FastAPI service, a Django site, a script that collects data every hour, an AI model. That is why "where should I host Python?" has no single answer. A bot needs to stay up 24 hours a day, a scheduled job runs for two minutes a day and a model using torch needs a lot of RAM.

Start with the type of app. It drives the criteria that change the choice, the recommendation per scenario and what to prepare before you deploy.

What kind of Python app are you hosting?#

Almost every project falls into one of four groups:

• Long-running process: Discord and Telegram bots, queue workers, continuous scrapers. They stay up all the time and keep connections open.
• Web app: APIs and sites. They can be WSGI (Flask, classic Django), served by Gunicorn or Waitress, or ASGI (FastAPI, Starlette, async Django), served by Uvicorn. They receive HTTP requests and must listen on a port.
• Scheduled job: a script that runs every so often, such as a daily report or a database cleanup. It sits idle most of the time.
• AI and data: apps that load models with torch, transformers or pandas. What matters here is RAM and the size of the dependencies.

The type sets the first decision: whether the process must always be running or can wake up on demand.

Which criteria matter when choosing?#

1. Always on or on demand. Bots and WebSocket connections need a continuous process. Short jobs can run on demand.
2. Time limit per run. Serverless functions have a ceiling: on AWS Lambda, an invocation lasts at most 15 minutes.
3. RAM. Each web worker is a separate Python process and adds memory. AI models can take several GB. See how to size RAM and CPU.
4. Native dependencies. Libraries such as numpy, psycopg and torch ship compiled code. If the environment has no prebuilt package (wheel) for your Python version and system, installation tries to compile and may fail.
5. Python version. Use a version that is still supported. The official schedule shows which versions are in that phase and when each one stops getting fixes.
6. How much you want to run yourself. Operating system, security updates, firewall, reverse proxy and automatic restarts: someone has to handle them. It is either you or the platform you host on.

What are the options, with pros and cons?#

Two points usually settle it. First, serverless does not fit bots: Lambda caps a run at 15 minutes and also caps the size of a .zip package, which rules out large libraries such as torch unless you use a container image (the current sizes are on Lambda's limits page). Second, a VPS gives you freedom, but every hour spent configuring a server is an hour away from your code. The articles VPS vs cloud platform and serverless vs containers go deeper into those two comparisons.

Which option is best for each scenario?#

• Discord, Telegram or WhatsApp bot: an always-on process, on a container platform or a VPS. The bot reconnects on its own when the process restarts, as long as something restarts it.
• FastAPI or Flask API with steady traffic: an always-on container with a production server. Without cold starts, the first request of the day is as fast as the rest. See how to host FastAPI, Flask and Django.
• Django site with a database: a container or VPS, plus a separately hosted database. See the best database for Python.
• Script that runs once a day: serverless with a schedule, or an always-on process with an internal scheduler if you already have an app running.
• App using torch or transformers: a container or VPS with plenty of RAM. Check that the environment has prebuilt packages so nothing compiles during deploy.
• Learning and testing: your own computer. When the project needs to stay online, move it.

How do you prepare a Python app for production?#

Whatever option you pick, four habits prevent most problems.

1. Pin your dependencies. List everything in requirements.txt with versions, or use a lockfile (uv, Poetry). That way the server installs exactly what you tested:

# example versions: pin the ones you tested (check with pip freeze)
fastapi==0.143.0
uvicorn==0.54.0

2. Use a production server. The Flask docs are direct: do not use the development server in production, because it is not designed to be secure, stable or efficient. Django says the same about runserver. For FastAPI, run Uvicorn listening on all interfaces (0.0.0.0), not only on 127.0.0.1. A minimal main.py:

import os

from fastapi import FastAPI

app = FastAPI()


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


if __name__ == "__main__":
    import uvicorn

    port = int(os.environ.get("PORT", "8000"))
    uvicorn.run(app, host="0.0.0.0", port=port)

For several processes, the FastAPI docs use the --workers option:

uvicorn main:app --host 0.0.0.0 --port 8000 --workers 2

For Flask or Django, the equivalent is Gunicorn. The Gunicorn docs suggest starting with (2 × CPU cores) + 1 workers and adjusting under load. Remember that each worker uses its own RAM.

3. Read configuration from the environment. Tokens, passwords and database URLs belong in environment variables, never in the code. So does the port: each host tells you which one to use.

4. Write logs to standard output. Use print or the logging module pointed at stdout. Almost every host shows that output in its dashboard, and that is where you will diagnose errors.

Which errors show up when hosting Python?#

• ModuleNotFoundError: a package missing from requirements.txt, or an install name that differs from the import name. See Cannot find module and ModuleNotFoundError.
• The app starts but nobody can reach it: the server listens on 127.0.0.1 or on a port other than the one the host expects.
• Process killed without a clear error: out of memory, common with many workers or large models. Reduce workers or add RAM.
• Data that disappears: SQLite or files saved to the disk of an environment that is recreated on every deploy. Use a database or external storage.
• Compilation failing during deploy: the server's Python version has no wheel for some dependency. Match your local version to the server's.

How to do this on Square Cloud#

Among Square Cloud's several runtimes, such as Node.js, Python and Go, the Python one comes with prebuilt wheels for torch and transformers, so those libraries are not compiled during deploy. You deploy by uploading a ZIP in the dashboard, with the CLI, from GitHub (a push deploys, through the official GitHub Action or a webhook) or with the VS Code extension. The squarecloud.app configuration file is optional: the dashboard generates it on deploy (runtime, memory, main file), or you write it at the project root.

Apps run in always-on containers, with no cold starts or sleep mode, which works for bots and APIs alike. Automatic restart is on by default for dashboard deploys: it brings the app back when the process exits with an error. On start, the platform runs pip install -r requirements.txt, with your environment variables already set, and the app's disk persists across restarts and deploys.

Your plan's RAM is a shared pool: at least 256 MB per background app, such as a bot, and 512 MB per web app. Hobby starts at R$12.49 per month with 1 GB. Environment variables are set per app in the dashboard, API, CLI or VS Code, and a change takes effect on the next restart, without a rebuild.

A web app listens on 0.0.0.0, on the port in the PORT variable. Manual snapshots are available on every plan. See the details of the Python environment on the runtimes page.