Python hosting Django, Flask, FastAPI.
Push to GitHub. We read your requirements, pick your Python version, install your packages in their own environment, and start your app with gunicorn or uvicorn when you list them. Your migrations can run before visitors see the new version.
- Python3.10 → 3.14
- FrameworksDjango, Flask, FastAPI
- Installs withpip, Poetry, uv, Pipenv
- Priced byWhat it uses
We read your code, so you don't write a build script.
Every build shows what we found and each command we ran, line by line. Anything we found, you can change in the app's settings.
| File | What we do with it |
|---|---|
requirements.txt | Your packages, installed with pip. pyproject.toml and Pipfile work too, and they tell us the framework. |
uv.lock | uv sync. A poetry.lock means Poetry, and a Pipfile means Pipenv. Only your main packages, never the dev ones. |
manage.py | Django, and the project its settings live in, for gunicorn's start command. |
.python-version | The Python version, also from runtime.txt or requires-python in pyproject.toml. |
tanzahost.json | Optional: the version, system packages, and the install, build and start commands. |
It starts the way production should.
Your app listens on the port in PORT, which is 8080. Output isn't buffered, so every print shows in your logs at once.
Django
With gunicorn in your requirements: gunicorn yourproject.wsgi:application. Without it, Django's own runserver, so add gunicorn.
FastAPI
uvicorn, with the app it finds in main.py, app.py, server.py or api.py.
Flask
gunicorn when you list it, or flask run when you don't.
Migrations run before visitors arrive.
Set python manage.py migrate as the “before going live” command. It runs once per deploy, in its own sandbox, after the build and before the switch.
If it fails, nothing changes
The deploy stops, and the version before it keeps serving your visitors.
Watched for five minutes
If the new version stops by itself within five minutes, visitors go back to the previous one, and we tell you.
Roll back in one click
The build before the live one, deployed again without downtime.
Workers and tasks beside your web app.
Run Celery, RQ or any long command as a worker, and cron-style jobs as scheduled tasks, with your app's code and variables.
- Up to 5 workers per app, each with its own command, and limits of its own if you like.
- Up to 10 scheduled tasks, as often as every minute, in UTC, each stopped after an hour.
- PostgreSQL with connection pooling, MySQL or Valkey in the same project, with their connection details added to your variables.
Every Python from 3.10 to 3.14.
We use the newest version that meets what your code asks for, or the one you pick in the app's settings. The next build uses it.
- Python 3.14Supported
- Python 3.13Recommended
- Python 3.12Supported
- Python 3.11Supported
- Python 3.10End of life
Python 3.10 no longer gets security fixes, so it shows a warning and the date it's removed: 31 October 2027.
A Python app, priced in the open.
Say a Django app holds 0.25 GB of memory and uses 3% of a processor, awake all month. You pay for that use, hour by hour, from your wallet. The limits you set cost nothing by themselves.
reading today's prices