Skip to content
Django hosting

Django in production, with collectstatic and gunicorn done for you

When we see Django in your requirements or a manage.py, we find the folder holding wsgi.py, run collectstatic during the build and start gunicorn on port 8000. You only need a few settings that every production Django site needs anyway. Staging and live each get their own address and variables, so you can test migrations on staging before go-live.

Deploy your Django appSee pricing

Free staging (0.25 vCPU · 256 MB · 1 GB) · Live from ₹118.50/month, billed hourly · No servers to manage

What we detect

Sensible Django defaults, no config files.

When you connect the repository we read it and fill in the build settings below. Every value can be changed in the app’s settings — see build settings.

Runtime
Python 3.12
Port
8000
Build command
python manage.py collectstatic --noinput || true
Start command
gunicorn <project>.wsgi --bind 0.0.0.0:8000
Step by step

Deploy Django in minutes.

  1. 1

    Allow our hostnames

    Set ALLOWED_HOSTS = ['.apps.dployhub.com', 'www.yourdomain.com']. Without it Django answers every request with a 400.

  2. 2

    Trust your HTTPS origins

    Add CSRF_TRUSTED_ORIGINS = ['https://*.apps.dployhub.com', 'https://www.yourdomain.com'] so admin and form posts are accepted.

  3. 3

    Serve static files with whitenoise

    Set STATIC_ROOT = BASE_DIR / 'staticfiles', add whitenoise to requirements and put whitenoise.middleware.WhiteNoiseMiddleware right after SecurityMiddleware.

  4. 4

    Move settings into variables

    Read SECRET_KEY, DEBUG and DATABASE_URL from os.environ and set them per environment in the Environment variables tab. Keep DEBUG off on live.

  5. 5

    Run migrations on start

    Set Start command to python manage.py migrate --noinput && gunicorn mysite.wsgi --bind 0.0.0.0:8000 so each release migrates before serving.

  6. 6

    Deploy, test, go live

    Log in to /admin on staging, check pages and forms, then click Go live.

Tips

Running Django well in production.

Staging is free

Every app gets a staging copy in a free, lightweight Docker container (0.25 vCPU · 256 MB · 1 GB). It pauses after 7 days without a deploy — one click starts it again.

  • collectstatic runs with || true, so a missing STATIC_ROOT will not fail the build — but your CSS will be missing. If the admin looks unstyled, set STATIC_ROOT and add whitenoise.
  • Give staging and live different DATABASE_URL values. Otherwise a migration tested on staging is already applied to your production database.
  • For SQLite, put the file at /data/db.sqlite3 on live; anything outside /data is lost on redeploy. For important data, use a managed PostgreSQL database.
  • Uploaded media also belongs under /data: set MEDIA_ROOT = '/data/media'.
  • Add --workers 3 to the gunicorn command on 1 vCPU; the free staging container (0.25 vCPU, 256 MB) is happiest with --workers 2.
Why do I get 'Bad Request (400)'?

The hostname is not in `ALLOWED_HOSTS`. Add `.apps.dployhub.com` and every custom domain you attach, then redeploy.

Why does the admin say 'CSRF verification failed'?

Add the full `https://` origin of each address to `CSRF_TRUSTED_ORIGINS`. Django 4+ requires the scheme.

Can I run Django with ASGI and channels?

Yes. Override Start command with something like `uvicorn mysite.asgi:application --host 0.0.0.0 --port 8000`; uvicorn is installed automatically when the command uses it.

Where is my manage.py if it's in a subfolder?

Set Folder with your app to the folder containing `manage.py` and `requirements.txt`, for example `backend`.

Other deploy guides

Ship your Django app today.

Create an account, connect your repository and get a free staging copy plus a live HTTPS address in minutes.

Start deployingRead the quick start