Python app hosting: deploy Django, Flask and FastAPI

Python app hosting starts with the process your application needs to run. Django and Flask commonly use a WSGI server; FastAPI uses an ASGI server. A Celery worker or a scheduled script has another lifecycle. Choose a host that supports those processes, the database and the storage your app needs.

Lizard publishes this guide. We checked the linked framework and provider documentation on 9 September 2026. The examples use explicit module names that you must adapt to your project.

Choose the runtime before the host

The development server is for development. See the official Django deployment guide, Flask production guide and FastAPI worker guidance.

Python hosting options by need

Use the PaaS comparison for the wider hosting decision. A Python badge in a feature table is not enough to confirm worker or database support.

Free Python hosting needs a workload limit

A free plan may restrict outbound requests, sleep an inactive web process, limit task execution or include only a trial credit. Those terms can be fine for a demonstration and unsuitable for a webhook receiver or queue worker.

Check Render's free-service rules and PythonAnywhere's free-account features. For Cloud Run, the pricing page describes free usage alongside billable resources. A database, image registry or network usage may remain outside the allowance you are looking at.

Test the first request after a quiet period and confirm whether scheduled or background work still runs. Describe the free option in terms of those limits, not as unlimited hosting.

Build and start commands

For a project that uses requirements.txt, install its pinned dependencies with:

python -m pip install -r requirements.txt

Use the package manager and lockfile already in your repository if it uses uv, Poetry or another tool. Include the production server in the dependencies. Do not rely on a package installed only on your laptop.

For Django, where myproject/wsgi.py defines the application:

gunicorn myproject.wsgi:application --bind "0.0.0.0:${PORT:-3000}"

For Flask, where app.py exports app:

gunicorn app:app --bind "0.0.0.0:${PORT:-3000}"

For FastAPI, where main.py exports app:

uvicorn main:app --host 0.0.0.0 --port "${PORT:-3000}"

These commands expect a shell to expand the port variable. A JSON-array Docker CMD does not expand it automatically. Either use the runtime's documented variable support, a shell wrapper, or a small program that reads the environment.

Set worker counts from measurements and available memory. More processes can use more memory and database connections; adding workers is not a substitute for checking a slow query or blocking task.

A minimal FastAPI container

For an application with main.py and a locked requirements.txt containing FastAPI and Uvicorn, this Dockerfile starts one server process:

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
RUN useradd --create-home appuser
USER appuser
EXPOSE 3000
CMD ["sh", "-c", "exec uvicorn main:app --host 0.0.0.0 --port ${PORT:-3000}"]

Choose a Python version compatible with your project. Put .env, local virtual environments, caches and Git data in .dockerignore. This example does not install extra operating-system packages; add only those your dependencies need.

On Lizard, you can bring a Dockerfile or use the source-build path. The deployment guide explains the options. Your app should expose a small health endpoint, and you should also test an endpoint that exercises its real dependencies.

A FastAPI deployment checked on Lizard

Our public FastAPI example has a dated deployment record from 9 September 2026. The test used commit df522c1, built from GitHub in eu-west-lim-a, with port 8000 and a Uvicorn start command in the Procfile. It used Python 3.13 with FastAPI 0.141.1 and Uvicorn 0.52.4. No manual build or start override was set.

The published check record reports six passing checks through the public HTTPS URL:

Open the live health endpoint, try the API interface, or follow the FastAPI deployment guide.

These results cover deployment and HTTP behaviour for a small app without a database. They do not measure uptime, load capacity or end-to-end deployment time. The same record gives a CLI reading at 11:48 UTC of about 0.034 GB of memory and about $0.00051/hour in resource cost. That is a reading at one moment, not a monthly invoice; plan fees, credits and other charges still apply. The Dockerfile above is a separate example and does not reproduce that deployment's exact configuration.

Django, Postgres and Celery need separate checks

Connect Managed Postgres through the variable your Django settings read. Run migrations as a controlled release step, not independently in every web worker. Configure static-file handling and give uploaded files durable storage.

Run Celery as a separate service with the same relevant application code and its own start command. Configure the broker explicitly, for example with Managed Redis if your application uses Redis. Check retries, duplicate-task handling and shutdown before accepting production work.

For a server you operate yourself, use the Django VPS walkthrough. For a managed worker, see the worker deployment reference.

Estimate the whole Python application

Include web processes, workers, database, stored files, backups, transfer and the plan your team needs. Railway meters consumption and applies its paid plan toward usage. Render publishes instance plans. PythonAnywhere currently lists Developer at $10/month; check its included features against your app. Sources: Railway, Render, PythonAnywhere.

For Lizard, use current pricing and measured CPU and memory. An idle Python process can still hold memory. Do not assume that low traffic makes a continuously running service free.

FAQ

Can I host FastAPI on the same services as Django? Often, but FastAPI needs an ASGI server. Confirm the host supports your start command and any long-lived connections or workers the app uses.

Should I use runserver in production? No. Use a production WSGI or ASGI server and check the framework's deployment guidance.

Why does the host say my app is unhealthy? Check the build logs, process exit status, import path, bound interface and expected port. Then check missing variables and dependency connections.

Do I need a Dockerfile? Not on every host. A source builder can create the image, but you still need correct dependencies and a production start command.

What is the best host for a Python worker? One that supports the worker's lifecycle and dependencies. Test queue consumption, retries and restart behaviour; an HTTP-only deployment is not enough.