Django hosting manage.py, meet production.
Push to GitHub. We find manage.py and your settings, install your packages, and start Django with gunicorn. Your migrations run before visitors see the new version, and PostgreSQL is one click away.
- Python3.10 → 3.14
- Starts withgunicorn
- 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 |
|---|---|
manage.py | Django, and the project its settings live in, from DJANGO_SETTINGS_MODULE, for gunicorn's start command. |
requirements.txt | Your packages, installed with pip. pyproject.toml with uv or Poetry, and Pipfile, work too. |
.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.
With gunicorn in your requirements, we run gunicorn yourproject.wsgi:application on the port in PORT, which is 8080. Output isn't buffered, so every print shows in your logs at once.
Static files
Run python manage.py collectstatic --noinput as the build command and serve them with WhiteNoise. The front door keeps them in its cache.
Settings from variables
Read SECRET_KEY, DEBUG and DATABASE_URL from variables. They're encrypted, and never in a log.
Without gunicorn
We fall back to Django's own runserver and say so in the build: add gunicorn before you go live.
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 version before, deployed again without downtime.
Celery and tasks beside your web app.
Run Celery, RQ or Django-Q as a worker, and management commands on a schedule, with your app's code and variables.
- Up to 5 workers per app, each with its own command, like celery -A yourproject worker.
- Up to 10 scheduled tasks, as often as every minute, in UTC, each stopped after an hour.
- PostgreSQL with connection pooling, and Valkey as Celery's broker, in the same project: attaching them adds DATABASE_URL and REDIS_URL.
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 Django 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