Django hosting for Django, FastAPI and Flask on your own servers

Python web apps need more moving parts than most stacks: a virtual environment, an app server, static files, migrations, a task queue and a scheduler. Deployment sets all of them up on your own Ubuntu or Debian server, for Django, FastAPI and Flask alike, and ships every push into a new release that goes live only after it passes its health check.

Data engineer at a cluttered desk with a laptop and printed charts working on a Python web app

What Deployment detects in a Python repository

Deployment reads requirements.txt, pyproject.toml (Poetry, uv, PDM or plain setuptools) and Pipfile to pick the dependency tool and the Python version. manage.py and django mark a Django project and reveal the settings module. fastapi with an ASGI app object marks FastAPI, flask marks Flask. celery in the dependencies adds a worker and, when beat schedules exist, a beat process. psycopg or psycopg2 points to PostgreSQL, mysqlclient to MySQL.

Python 3.x version from pyproject, .python-version or runtime.txt
Dependency install with pip, Poetry or uv into a per-release virtual environment
WSGI with gunicorn for Django and Flask, ASGI with uvicorn workers for FastAPI and async Django
Celery worker and beat when the project uses them

What Deployment installs for Django hosting

Provisioning hardens the server (firewall, key-only SSH, unattended security updates, swap) and installs the Python versions your sites need side by side, build tools for packages with C extensions, nginx or Caddy, PostgreSQL or MySQL, and Redis as the Celery broker and cache. Static files are served by the proxy from STATIC_ROOT, and user uploads in MEDIA_ROOT live in a shared folder that every release links to.

Backend engineer at a workbench beside an open server running a compiled service on a laptop

A Django deploy script with collectstatic and migrations

Each release has its own virtual environment, so a dependency upgrade never touches the code that is still serving traffic. For FastAPI the script swaps the Django steps for your Alembic command (alembic upgrade head). You edit the script in the panel like any shell file.

bash

cd "$RELEASE_PATH"
python3 -m venv .venv
.venv/bin/pip install --no-cache-dir -r requirements.txt
.venv/bin/python manage.py collectstatic --noinput
.venv/bin/python manage.py migrate --noinput
.venv/bin/python manage.py check --deploy

gunicorn, uvicorn and Celery under one roof

The web process runs as gunicorn project.wsgi with a worker count sized to the server's CPUs, or as gunicorn with uvicorn.workers.UvicornWorker for ASGI apps. Celery workers and Celery beat run as separate supervisor or systemd daemons. On deploy Deployment sends the workers a warm shutdown, so tasks in progress finish before the worker restarts on the new release, and beat restarts after the workers so schedules never run twice. Management commands you want on a timer (clearsessions, report jobs) become cron jobs with logs in the panel.

Zero downtime Django releases and rollback

A release is ready only when dependencies are installed, collectstatic and migrations have run, and the new gunicorn answers the health route (for example a small /healthz view that touches the database). Then the current symlink moves and gunicorn is reloaded gracefully with HUP, so open requests finish on the old workers. If any step fails, your users never notice. Earlier releases, each with its own virtual environment and static files, stay on disk for one-click rollback. Read more on zero downtime deployment and on deploy from git.

Split destructive migrations into two releases so rollback stays safe
Use ManifestStaticFilesStorage so cached CSS and JS always match the release that serves them

PostgreSQL first, MySQL when you need it

Django and PostgreSQL are a natural pair, and Deployment creates the database, a dedicated role with the grants your app needs, and remote access rules if the database lives on its own server. MySQL and MariaDB are available too. Redis covers the Celery broker, the cache and sessions. Scheduled backups go to your own S3-compatible bucket with retention and one-click restore. A longer walkthrough of a production setup is on deploy django.

Which plan fits your Django hosting

Plan	Monthly	Yearly, per month	Servers	Backups
Starter	49 USD	24 USD	3	daily
Team	199 USD	99 USD	15	hourly
Agency	499 USD	249 USD	60	hourly
Enterprise	1 499 USD	749 USD	250	custom schedule

A single Django app with Celery and a staging copy fits Starter. Teams that split web, workers and database across servers, or that need hourly backups and roles, fit Team.

Django hosting questions

Does Deployment support FastAPI and Flask as well?

Yes. FastAPI runs on uvicorn workers under gunicorn, Flask runs on gunicorn, and both get the same release folders, health checks and rollback as Django.

Can I use Poetry or uv instead of pip?

Yes. Deployment detects the tool from pyproject and the lockfile, and you can change the install line in the deploy script.

Where do media uploads go?

Into a shared folder that every release links to, so uploads survive deploys. You can also store them in S3-compatible storage with django-storages.

Can I try Deployment before I pay?

Yes. The home page has a free one-time demo: paste a public repository URL and see the detected stack, the server plan and the first lines of the deploy script. Plans start at 49 USD a month, or 24 USD a month billed yearly.

Run your Python apps on your own terms

Connect a server, point it at your repository and push.

Try the demo

production

$ git push origin main

✓ build release 20261019-142210

✓ health check 200

✓ switch current 0.4 s